public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Robert Miles <robertmiles@bellsouth.net>
To: cygwin@cygwin.com
Subject: Re: Machine very sluggish while compiling
Date: Thu, 08 Dec 2011 11:18:00 -0000	[thread overview]
Message-ID: <4EE09CF8.7040804@bellsouth.net> (raw)
In-Reply-To: <20111204100639.GA9849@calimero.vinschen.de>

On 12/4/2011 4:06 AM, Corinna Vinschen wrote:
> On Dec  4 02:55, Ryan Johnson wrote:
>> On 25/11/2011 10:47 AM, Spiro Trikaliotis wrote:
>>> Hello,
>>>
>>> * On Thu, Nov 24, 2011 at 07:59:58PM -0500 Ryan Johnson wrote:
>>>
>>>> Lately I've noticed that running make -j4 on my quad-core win7-x64
>>>> machine causes it to become sluggish or even unresponsive.
>>> I have seen very similar effects on my Win7-64 box. I can force the
>>> problem here just be running "ccrypt", though, I do not need to use "make
>>> -j4".
>>>
>>> I assume it has to do with the Windows 64 bit problems of Cygwin (search
>>> the ML archives for that).
>>>
>>> For me, this is the first machine since years where I do not use Cygwin
>>> because of this issue.
>> Update: I hit the problem again, this time running python, and the
>> problem is repeatable with the native 64-bit windows python
>> interpreter. It looks like cygwin doesn't cause the problem, but
>> rather my high-cpu tasks tend to run under cygwin. Honestly, I
>> wouldn't expect cygwin to be the cause, given that it's a user space
>> only piece of software!
>>
>> Now what other entity could be the cause, I haven't a clue...
>> process explorer doesn't show anything. Maybe that's because it's
>> frozen along with the rest of the world during these episodes; right
>> as it comes back I see context switch deltas above 100k for the
>> interrupt/DPC module, which suggests I've got a wonky driver
>> somewhere.
> Here's another observation:
>
> Since Friday I'm testing a script which runs in a `while true; do done'
> loop.  Nothing serious, just a bit of environment variable setting,
> calling find in an empty directory tree, grep, sed, the usual.
>
> It's running in mintty on a W7 64 bit machine.  When starting to run the
> script, the CPU load on the dual core machine is about 70%.  After a
> while, let's say an hour, the CPU load is 100%.  Task Manager shows that
> one of the svchost.exe processes is grabing a lot of memory and a lot of
> CPU.  Stop the script and the svchost still takes mem and about 50% CPU
> time, which means, one of the cores is solely busy to server this
> svchost process.  Exit mintty and this svchost drops to 0% CPU and the
> memory usage goes down a lot.
>
> The svchost in question is the one running the following services:
>
>    Windows Audio Endpoint Builder
>    Offline Files
>    Network Conections
>    Program Compatibility Assistent Service
>    Superfetch
>    Distributed Link Tracking Client
>    Remote Desktop Service UserMode Port Redirector
>    Desktop Windows Manager Session Manager
>    WLAN AutoConfig
>    Windows Driver Foundation - User-mode Driver Framework
>
> After some testing it turned out that the culprit is the "Program
> Compatibility Assistent Service" service.  If I stop this service, the
> svchost in question behaves harmless.  Superfetch is no saint either in
> terms of memory usage, but it has by far not the influence and sticks to
> about 3% CPU usage after the PCA service has been stopped.
>
> Another way to fix this problem is to run the script in a Windows console
> window, so it's something to do with mintty.
> I have not the faintest idea why the PCA service thinks it has to "help"
> mintty along.  I'm starting it from a desktop shortcut which has no
> compatibility mode set.
>
> Anyway, stoppping the PCA service and setting its start mode to "Manual"
> does the trick for me.  While I was at it I also disabled Superfetch,
> which drops the memory usage of this svchost to a fraction of what it
> used before, and the CPU usage to 0%, and I don't see any performance
> difference.
>
>
> Corinna
>
Are you aware that the Superfetch service deliberately tries to use most 
of the
memory not otherwise in use as a cache for the most frequently accessed disk
files, in order to speed up accesses to those files?  I've found it 
rather slow to
release this cache memory when some other program needs it, though.

Robert Miles

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  parent reply	other threads:[~2011-12-08 11:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-25  4:07 Ryan Johnson
2011-11-25  4:17 ` Mike
2011-11-25  7:22   ` Ryan Johnson
2011-11-25 15:48 ` Spiro Trikaliotis
2011-12-04  7:55   ` Ryan Johnson
2011-12-04 10:07     ` Corinna Vinschen
2011-12-05 22:25       ` Ken Brown
2011-12-06 10:39         ` Corinna Vinschen
2011-12-08 11:18       ` Robert Miles [this message]
2011-12-08 13:15         ` Ryan Johnson
2011-12-04 19:29     ` Christopher Faylor
     [not found]       ` <4EDBD5A5.2000707@cs.utoronto.ca>
2011-12-04 20:23         ` Ryan Johnson
2011-12-06 17:39 ` Andrew Schulman
2011-12-07  5:23   ` Mike

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EE09CF8.7040804@bellsouth.net \
    --to=robertmiles@bellsouth.net \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).