We currently see the following behaviour in our main process (under
high load)

- All threads are suspended
- Performance counters don't publish any data
- 0% CPU usage (all CPU goes to other processes)

This sometimes goes on for 10-20 seconds. We do a lot of I/O (network
and disk), P/Invoke, and the process itself uses approx. 75% of the
system's CPU. I can reproduce the above mentioned condition easily when
I start another CPU-intensive task like a benchmark, although it
happens sporadically anyway.

Can this be caused by the garbage collector? I know that it suspends
all threads for a collection, but for so long? And why don't I see
anything in the performance counters? I don't even see a hint and then
suddenly the process hangs and no performance data is available.

Any help would be appreciated!

Christian

if you suspect it is the garbage counter, you can set a counter to monitor
collections. But i don't understand your intent. Why is this a problem? are
you having performance issues?

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc, Amazon, B&H etc


Forth-coming VSTO.NET
-------------------------------------------------------------------------------
<christian.benien (AT) gmail (DOT) com> wrote

The problem is that the application is (almost) realtime. We can handle
delays of 3-4 seconds, but nothing more than that. The problem with
counting collections is that from the point where the process is
suspended, I don't get any performance data at all! I'm monitoring
every ".NET CLR Memory" counter that's available.

Is there any specific counter that could indicate what's going on after
the process resumes?

It's good that you can reproduce it. Check the logs to see if there are any
exceptions written out. Then you can try running it in debug mode and set it
to break on all exceptions see if that turns up anything. It probably isn't
the GC. GC should take less than 1/10 of a second in normal circumstances
(all things considered). Repost here if you still can't figure it out.

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc, Amazon, B&H etc


Forth-coming VSTO.NET
-------------------------------------------------------------------------------
<christian.benien (AT) gmail (DOT) com> wrote

Alvin,

thanks for your help. But I think I finally figured it out. The reason
was that we allocated a lot of byte[] objects for async network I/O. If
you pass them to Socket.BeginReceive, they are promoted to gen 2 in the
GC. The network throughput in my test case was about 30-40 Mbit, so in
effect we allocated more than 10 MB per second.

Now I try to reuse the buffer whenever possible, and since then I no
more problems. So it was clearly the GC, but I was very surprised to
see that it can take so long.

Regards,
Christian

good. thanks for reporting back

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc, Amazon, B&H etc


Forth-coming VSTO.NET
-------------------------------------------------------------------------------
<christian.benien (AT) gmail (DOT) com> wrote