EDN Admin
Well-known member
Im working on a large project, made with C#. I cant really post any code because its all interleaved, in a way I dont think it has to do anything with any specific piece of code, but hopefully this description will help:
The program is actually a server that processes some requests. It consumes about 3.5GB of memory, the machine its running on has 6GB physical memory (its the only demanding program on the machine, well theres a few small programs like httpd and mysqld
which dont have any heavy load and dont consume much CPU).
There are unusual CPU utilization spikes, they occur every 3-5 minutes and each takes about 2 seconds (usually 1900-2200 ms). Ive added lots of code to track what exact piece of code could be doing this, although certain methods come up more frequently,
its as if it occurs randomly. But with the diagnostics that Ive added, I have just found a line that caused a 2-second 100% cpu utilization (at one time), and surprisingly its "Thread.Sleep(1);". So it seems as if there isnt any particular poorly-written
code in there, but that theres just something that causes it all to pause at random points of execution.
What could it be? Perhaps a hardware issue? I was thinking that some of it is in virtual memory (on the hard drive) and it takes 2 seconds for OS to load the data from the HDD back into RAM, but that surely cant be possible with the Thread.Sleep right?
Its running on an Asus board, X58 chipset, Intel i7-980x cpu. It does the same on a different computer which is a similar board (different model but same chipset) but an i7-920 CPU. I have the Process Explorer (procexp.exe) with which i can see that it
actually is this process that is causing the CPU spikes. Both computers are running Win7 ultimate (genuine license). Though it has been happening even before, on Windows XP x64 - same machine, just that the OS has been upgraded recently (not as an upgrade,
but a completely fresh install on a fresh HDD).
Been hoping to resolve this myself but after a lot of time trying and searching, Im turning to these forums for help.
Looking forward to a reply and hopefully a solution
<br/>
<br/>
View the full article
The program is actually a server that processes some requests. It consumes about 3.5GB of memory, the machine its running on has 6GB physical memory (its the only demanding program on the machine, well theres a few small programs like httpd and mysqld
which dont have any heavy load and dont consume much CPU).
There are unusual CPU utilization spikes, they occur every 3-5 minutes and each takes about 2 seconds (usually 1900-2200 ms). Ive added lots of code to track what exact piece of code could be doing this, although certain methods come up more frequently,
its as if it occurs randomly. But with the diagnostics that Ive added, I have just found a line that caused a 2-second 100% cpu utilization (at one time), and surprisingly its "Thread.Sleep(1);". So it seems as if there isnt any particular poorly-written
code in there, but that theres just something that causes it all to pause at random points of execution.
What could it be? Perhaps a hardware issue? I was thinking that some of it is in virtual memory (on the hard drive) and it takes 2 seconds for OS to load the data from the HDD back into RAM, but that surely cant be possible with the Thread.Sleep right?
Its running on an Asus board, X58 chipset, Intel i7-980x cpu. It does the same on a different computer which is a similar board (different model but same chipset) but an i7-920 CPU. I have the Process Explorer (procexp.exe) with which i can see that it
actually is this process that is causing the CPU spikes. Both computers are running Win7 ultimate (genuine license). Though it has been happening even before, on Windows XP x64 - same machine, just that the OS has been upgraded recently (not as an upgrade,
but a completely fresh install on a fresh HDD).
Been hoping to resolve this myself but after a lot of time trying and searching, Im turning to these forums for help.
Looking forward to a reply and hopefully a solution
<br/>
<br/>
View the full article
