* Machine very sluggish while compiling
@ 2011-11-25 4:07 Ryan Johnson
2011-11-25 4:17 ` Mike
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Ryan Johnson @ 2011-11-25 4:07 UTC (permalink / raw)
To: cygwin
Hi all,
Lately I've noticed that running make -j4 on my quad-core win7-x64
machine causes it to become sluggish or even unresponsive. For example,
compiling a large package makes the mouse jumpy, delays keystrokes, adds
stutter to my music, and makes task switching painfully slow (though,
oddly, if I manage to switch to the mintty that runs make the machine
"comes back"). The sluggishness always hits when I'm using a native
windows app with the compile running in the background. This starts to
sound oddly like the recently-reported issue where X was causing native
windows apps to freeze [1].
I'm not seeing any fork failures, and am running BLODA-free (Windows
Defender hasn't reappeared since I last uninstalled it). There's no
unusual disk activity and memory utilization remains stable. I've tried
running with nice, reducing the priority of 'make' from the task
manager, and running make -j3 to no avail, though empirically if
utilization stays at or below 2 cpu then there's no problem. I've
compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for
several years now and never seen this behavior before.
Any ideas of how I might diagnose the issue further? It's easy enough to
work around, but compiles take a lot longer with only 1-2 cores instead
of 4.
Thanks,
Ryan
[1] http://cygwin.com/ml/cygwin-xfree/2011-11/msg00027.html
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-11-25 4:07 Machine very sluggish while compiling Ryan Johnson
@ 2011-11-25 4:17 ` Mike
2011-11-25 7:22 ` Ryan Johnson
2011-11-25 15:48 ` Spiro Trikaliotis
2011-12-06 17:39 ` Andrew Schulman
2 siblings, 1 reply; 14+ messages in thread
From: Mike @ 2011-11-25 4:17 UTC (permalink / raw)
To: cygwin
Hi Ryan,
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. For example,
> compiling a large package makes the mouse jumpy, delays keystrokes, adds
> stutter to my music, and makes task switching painfully slow (though,
> oddly, if I manage to switch to the mintty that runs make the machine
> "comes back"). The sluggishness always hits when I'm using a native
> windows app with the compile running in the background. This starts to
> sound oddly like the recently-reported issue where X was causing native
> windows apps to freeze [1].
>
> I'm not seeing any fork failures, and am running BLODA-free (Windows
> Defender hasn't reappeared since I last uninstalled it). There's no
> unusual disk activity and memory utilization remains stable. I've tried
> running with nice, reducing the priority of 'make' from the task
> manager, and running make -j3 to no avail, though empirically if
> utilization stays at or below 2 cpu then there's no problem. I've
> compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for
> several years now and never seen this behavior before.
>
> Any ideas of how I might diagnose the issue further? It's easy enough to
> work around, but compiles take a lot longer with only 1-2 cores instead
> of 4.
I've seen problems like this caused by viruses. Process Explorer might
give you more detailed info:
http://technet.microsoft.com/en-au/sysinternals/bb896653
Perhaps you are using a different version of bash or other shell? Some
versions have been known to bog down the system as you describe.
Search for bash slow might yield some clues:
http://cygwin.com/ml/cygwin/
--
Regards,
Mike
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-11-25 4:17 ` Mike
@ 2011-11-25 7:22 ` Ryan Johnson
0 siblings, 0 replies; 14+ messages in thread
From: Ryan Johnson @ 2011-11-25 7:22 UTC (permalink / raw)
To: cygwin
On 24/11/2011 11:06 PM, Mike wrote:
> Hi Ryan,
>
> 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. For
>> example, compiling a large package makes the mouse jumpy, delays
>> keystrokes, adds stutter to my music, and makes task switching
>> painfully slow (though, oddly, if I manage to switch to the mintty
>> that runs make the machine "comes back"). The sluggishness always
>> hits when I'm using a native windows app with the compile running in
>> the background. This starts to sound oddly like the recently-reported
>> issue where X was causing native windows apps to freeze [1].
>>
>> I'm not seeing any fork failures, and am running BLODA-free (Windows
>> Defender hasn't reappeared since I last uninstalled it). There's no
>> unusual disk activity and memory utilization remains stable. I've
>> tried running with nice, reducing the priority of 'make' from the
>> task manager, and running make -j3 to no avail, though empirically if
>> utilization stays at or below 2 cpu then there's no problem. I've
>> compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for
>> several years now and never seen this behavior before.
>>
>> Any ideas of how I might diagnose the issue further? It's easy enough
>> to work around, but compiles take a lot longer with only 1-2 cores
>> instead of 4.
>
> I've seen problems like this caused by viruses. Process Explorer might
> give you more detailed info:
> http://technet.microsoft.com/en-au/sysinternals/bb896653
I've used Process Explorer several times in the past, but it's not
immediately obvious to me what I should be using it to look for.
Suspicious dlls? I keep my machine patched, regularly check my process
list for suspicious/unfamiliar entries, and have not had a virus in
roughly 8 years (and that one was thanks to my sister in-law borrowing
the machine). I can't rule out a rootkit infection, but PE wouldn't be
any help there anyway.
> Perhaps you are using a different version of bash or other shell? Some
> versions have been known to bog down the system as you describe.
> Search for bash slow might yield some clues:
> http://cygwin.com/ml/cygwin/
Latest version of cygwin's bash, bash-completions package is not
installed. Also, make+compilation seems to proceed at normal speed the
whole time... it's everybody else that suffers.
BTW, thanks for the ideas, they're definitely solid sanity checks.
Regards,
Ryan
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-11-25 4:07 Machine very sluggish while compiling Ryan Johnson
2011-11-25 4:17 ` Mike
@ 2011-11-25 15:48 ` Spiro Trikaliotis
2011-12-04 7:55 ` Ryan Johnson
2011-12-06 17:39 ` Andrew Schulman
2 siblings, 1 reply; 14+ messages in thread
From: Spiro Trikaliotis @ 2011-11-25 15:48 UTC (permalink / raw)
To: cygwin
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.
Best regards,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-11-25 15:48 ` Spiro Trikaliotis
@ 2011-12-04 7:55 ` Ryan Johnson
2011-12-04 10:07 ` Corinna Vinschen
2011-12-04 19:29 ` Christopher Faylor
0 siblings, 2 replies; 14+ messages in thread
From: Ryan Johnson @ 2011-12-04 7:55 UTC (permalink / raw)
To: cygwin
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.
Ryan
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-12-04 7:55 ` Ryan Johnson
@ 2011-12-04 10:07 ` Corinna Vinschen
2011-12-05 22:25 ` Ken Brown
2011-12-08 11:18 ` Robert Miles
2011-12-04 19:29 ` Christopher Faylor
1 sibling, 2 replies; 14+ messages in thread
From: Corinna Vinschen @ 2011-12-04 10:07 UTC (permalink / raw)
To: cygwin
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-12-04 7:55 ` Ryan Johnson
2011-12-04 10:07 ` Corinna Vinschen
@ 2011-12-04 19:29 ` Christopher Faylor
[not found] ` <4EDBD5A5.2000707@cs.utoronto.ca>
1 sibling, 1 reply; 14+ messages in thread
From: Christopher Faylor @ 2011-12-04 19:29 UTC (permalink / raw)
To: cygwin
On Sun, Dec 04, 2011 at 02:55:13AM -0500, 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.
Out of curiousity, is the current snapshot any better? I just found a
case where Cygwin could essentially enter a tight loop while waiting for
I/O. It would seem to be working correctly but it would use a lot of
CPU time.
cgf
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
[not found] ` <4EDBD5A5.2000707@cs.utoronto.ca>
@ 2011-12-04 20:23 ` Ryan Johnson
0 siblings, 0 replies; 14+ messages in thread
From: Ryan Johnson @ 2011-12-04 20:23 UTC (permalink / raw)
To: cygwin
Trying again without the verboten 80kB PNG attachment...
On 04/12/2011 3:18 PM, Ryan Johnson wrote:
> On 04/12/2011 2:29 PM, Christopher Faylor wrote:
>> On Sun, Dec 04, 2011 at 02:55:13AM -0500, 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.
>> Out of curiousity, is the current snapshot any better? I just found a
>> case where Cygwin could essentially enter a tight loop while waiting for
>> I/O. It would seem to be working correctly but it would use a lot of
>> CPU time.
> Again, I'm no longer convinced that this is Cygwin's fault -- it just
> so happened that all my CPU-intensive tasks were cygwin apps. I'm
> starting to notice a pattern, though: with three cpu-bound apps
> running, my laptop's fan comes on every two minutes (precisely). About
> five seconds later, the frequency drops by 50% and cpu util promptly
> saturates as a result. After one minute of this, the frequency hikes
> back up and we're good... until the cycle repeats a minute later (see
> the attached snippet of screen shot).
>
> So, the questions are how come:
> - power/heat management isn't giving the fan a chance to work before
> clamping the clock frequency?
> - scheduler can't cope better with 100% cpu util?
>
> While I'm glad to take any expert advice people might have, I think we
> can close this thread as far as Cygwin is concerned.
>
> BTW, Corinna's advice to disable PCA did help somewhat (and
> Firefox/Thunderbird util dropped as well as a bonus). However, it's
> probably only a treatment of symptoms in my case; I already had
> superfetch disabled.
>
> Thanks,
> Ryan
>
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
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
1 sibling, 1 reply; 14+ messages in thread
From: Ken Brown @ 2011-12-05 22:25 UTC (permalink / raw)
To: cygwin
On 12/4/2011 5:06 AM, Corinna Vinschen wrote:
> Anyway, stoppping the PCA service and setting its start mode to "Manual"
> does the trick for me.
It does the trick for me too. For a long time I've been unable to build
emacs using cygport's default for parallel make (-j5 because I have 4
cores). When I did this, I would either have the computer freeze (and I
would have to shut it down with the power button) or else I would get a
BSOD.
Since stopping PCA, the problem seems to be gone.
Ken
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-12-05 22:25 ` Ken Brown
@ 2011-12-06 10:39 ` Corinna Vinschen
0 siblings, 0 replies; 14+ messages in thread
From: Corinna Vinschen @ 2011-12-06 10:39 UTC (permalink / raw)
To: cygwin
On Dec 5 17:25, Ken Brown wrote:
> On 12/4/2011 5:06 AM, Corinna Vinschen wrote:
> >Anyway, stoppping the PCA service and setting its start mode to "Manual"
> >does the trick for me.
>
> It does the trick for me too. For a long time I've been unable to
> build emacs using cygport's default for parallel make (-j5 because I
> have 4 cores). When I did this, I would either have the computer
> freeze (and I would have to shut it down with the power button) or
> else I would get a BSOD.
>
> Since stopping PCA, the problem seems to be gone.
In the meantime I found another way how to avoid this problem.
Here's an excerpt from the MSDN man page of AssignProcessToJobObject:
If the process is being monitored by the Program Compatibility
Assistant (PCA), it is placed into a compatibility job. Therefore, the
process must be created using CREATE_BREAKAWAY_FROM_JOB before it can
be placed in another job. Alternatively, you can embed an application
manifest that specifies a User Account Control (UAC) level in your
application and PCA will not add the process to the compatibility job.
So, what I did was to change Cygwin locally to add the
CREATE_BREAKAWAY_FROM_JOB flag to the CreateProcess call when execing a
process. With this change, I had no problems with PCA anymore.
I also tried to use an "asInvoker" side-by-side manifest for mintty, but
I had no luck with it. PCA still wasted memory and CPU.
So I'm wondering if we should simply add the CREATE_BREAKAWAY_FROM_JOB
flag to our CreateProcess calls and be done with it. As far as I can
see, and from what MSDN claims, there should be no problem doing that.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-11-25 4:07 Machine very sluggish while compiling Ryan Johnson
2011-11-25 4:17 ` Mike
2011-11-25 15:48 ` Spiro Trikaliotis
@ 2011-12-06 17:39 ` Andrew Schulman
2011-12-07 5:23 ` Mike
2 siblings, 1 reply; 14+ messages in thread
From: Andrew Schulman @ 2011-12-06 17:39 UTC (permalink / raw)
To: cygwin
> Lately I've noticed that running make -j4 on my quad-core win7-x64
> machine causes it to become sluggish or even unresponsive. For example,
> compiling a large package makes the mouse jumpy, delays keystrokes, adds
> stutter to my music, and makes task switching painfully slow (though,
> oddly, if I manage to switch to the mintty that runs make the machine
> "comes back"). The sluggishness always hits when I'm using a native
> windows app with the compile running in the background. This starts to
> sound oddly like the recently-reported issue where X was causing native
> windows apps to freeze [1].
I'm glad to hear it's not just me. I've been struggling with this for a few
months, on my WinXP SP3 (32-bit, dual-core) host. I avoid compiling on it,
because after a few minutes CPU goes to 100% even after I exit all Cygwin
processes, and once that happens the only solution is to reboot... which I
usually do with the reset button, because by that point everything is so slow
that even rebooting takes 15 minutes.
There's no PCA or Superfetch service on my host. I'll try shutting down other
services to see if that helps.
Andrew.
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-12-06 17:39 ` Andrew Schulman
@ 2011-12-07 5:23 ` Mike
0 siblings, 0 replies; 14+ messages in thread
From: Mike @ 2011-12-07 5:23 UTC (permalink / raw)
To: cygwin
Hi Andrew,
Andrew Schulman wrote:
>> Lately I've noticed that running make -j4 on my quad-core win7-x64
>> machine causes it to become sluggish or even unresponsive. For example,
>> compiling a large package makes the mouse jumpy, delays keystrokes, adds
>> stutter to my music, and makes task switching painfully slow (though,
>> oddly, if I manage to switch to the mintty that runs make the machine
>> "comes back"). The sluggishness always hits when I'm using a native
>> windows app with the compile running in the background. This starts to
>> sound oddly like the recently-reported issue where X was causing native
>> windows apps to freeze [1].
>
> I'm glad to hear it's not just me. I've been struggling with this for a few
> months, on my WinXP SP3 (32-bit, dual-core) host. I avoid compiling on it,
> because after a few minutes CPU goes to 100% even after I exit all Cygwin
> processes, and once that happens the only solution is to reboot... which I
> usually do with the reset button, because by that point everything is so slow
> that even rebooting takes 15 minutes.
>
> There's no PCA or Superfetch service on my host. I'll try shutting down other
> services to see if that helps.
Look for the Application Compatibility Toolkit (ACT) as described at:
http://support.microsoft.com/kb/294895
removing it helps some computers a lot.
Another program that causes problems on some computers is the MS Office
2010 Click-to-Run system. It's usually associated with the trial
version. With this system, software is downloaded and installed
dynamically as it is used. Hangs and slowdowns when logging off or
rebooting were noted. Removing this will help. If MSO is needed, the DVD
version can be installed.
Also removing .NET and re-installing it can help some computers.
--
Regards,
Mike
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-12-04 10:07 ` Corinna Vinschen
2011-12-05 22:25 ` Ken Brown
@ 2011-12-08 11:18 ` Robert Miles
2011-12-08 13:15 ` Ryan Johnson
1 sibling, 1 reply; 14+ messages in thread
From: Robert Miles @ 2011-12-08 11:18 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling
2011-12-08 11:18 ` Robert Miles
@ 2011-12-08 13:15 ` Ryan Johnson
0 siblings, 0 replies; 14+ messages in thread
From: Ryan Johnson @ 2011-12-08 13:15 UTC (permalink / raw)
To: cygwin
On 08/12/2011 6:18 AM, Robert Miles wrote:
> On 12/4/2011 4:06 AM, Corinna Vinschen wrote:
>> 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.
> 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.
In my experience Superfetch does a phenomenally bad job of predicting
which files I (or my wife) actually plan to use. The machine is sluggish
not (just) because the memory is uselessly tied up, but because the disk
is constantly busy fetching data that will never be used and penalizes
access to the data I actually do need. The memory wastage just compounds
the problem by contributing additional swapping on top of all this other
extra disk activity.
Both computers at my house saw *significant increases* in performance
and responsiveness when I disabled Superfetch a few months ago.
Ryan
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-12-08 13:15 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-25 4:07 Machine very sluggish while compiling 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
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
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).