Nikita, just interesting if it is the same issue. Have you tried applying this patch https://github.com/mono/mono/pull/703/ ?
Make sure you DO NOT set MONO_DISABLE_AIO as only epoll/kqueue backend is patched there. Not sure if it is related, though. thank you -yuriy On Tue, Aug 6, 2013 at 7:42 PM, Nikita Tsukanov <kek...@gmail.com> wrote: > Hello. I've written a simple SCGI server, configured nginx to work with > it, hammered it with jmeter and... got the same issue. It works for a while > and then stops accepting new connections (some existing ones still waiting > with CLOSE_WAIT). I get it with new > NetworkStream(TcpListener.AcceptSocket()) and BeginWrite/BeginRead. > MONO_DISABLE_AIO actually helps it to survive for 20-30 more seconds but > result is the same. > > Now I'll try to use some alternative way of working with sockets, may be > libuv or something like that. > > Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00 > UTC 2013) > > > 2013/8/5 Alfred Hall <ah...@ahall.org> > >> ** >> Getting similar issues when using FastCGI/XSP proxied via Nginx using tcp >> and unix sockets (tried both). After hammering it with jmeter it ends up >> locking up. I'm wondering if other mono webapps have this issue. Would be >> useful if someone else here could do a similar loadtest using jmeter and >> let me know if it happens to them. >> >> -----Original message----- >> *From:* Alfred Hall <ah...@ahall.org> >> *Sent:* Sunday 4th August 2013 17:41 >> *To:* Nikita Tsukanov <kek...@gmail.com>; >> mono-devel-list@lists.ximian.com >> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up >> on linux >> >> Hi Nikita. >> >> Full thread dump: >> >> "<threadpool thread>" tid=0x0x7fc4ad29d700 this=0x0x7fc4ad584c70 thread >> handle 0x80f state : not waiting owns () >> >> >> "IO Threadpool worker" tid=0x0x7fc4ad25c700 this=0x0x7fc4ad584dd0 thread >> handle 0x810 state : interrupted state owns () >> >> >> "IO Threadpool worker" tid=0x0x7fc4a7567700 this=0x0x7fc4a741d350 thread >> handle 0x845 state : interrupted state owns () >> >> >> "Threadpool worker" tid=0x0x7fc4ac39a700 this=0x0x7fc4a6192270 thread >> handle 0x837 state : interrupted state owns () >> at <unknown> <0xffffffff> >> at (wrapper managed-to-native) >> object.__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr) >> <0xffffffff> >> at (wrapper alloc) object.AllocVector (intptr,intptr) <0xffffffff> >> at System.Net.HttpConnection.BeginReadRequest () <0x0003a> >> at System.Net.EndPointListener.OnAccept (object,System.EventArgs) >> <0x00357> >> at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted >> (System.Net.Sockets.SocketAsyncEventArgs) <0x0002e> >> at System.Net.Sockets.SocketAsyncEventArgs.AcceptCallback >> (System.IAsyncResult) <0x00336> >> at System.Net.Sockets.SocketAsyncEventArgs.DispatcherCB >> (System.IAsyncResult) <0x0010f> >> at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object >> (object,intptr,intptr,intptr) <0xffffffff> >> >> >> I then tried the same again and only got this in my trace: >> >> Full thread dump: >> >> "<threadpool thread>" tid=0x0x7f31b8ac5700 this=0x0x7f31b8da4c70 thread >> handle 0x80e state : not waiting owns () >> >> >> "IO Threadpool worker" tid=0x0x7f31b8a84700 this=0x0x7f31b8da4dd0 thread >> handle 0x80f state : interrupted state owns () >> >> Not sure why I'm not getting any dump here. Any more debugging I can do >> on there? >> >> What seems to happen is its coping well initially with the requests and >> then in all of a sudden it stops accepting connections and existing >> connections dont die off. >> >> Cheers, >> Alf >> >> -----Original message----- >> *From:* Nikita Tsukanov <kek...@gmail.com> >> *Sent:* Sunday 4th August 2013 16:13 >> *To:* mono-devel-list@lists.ximian.com >> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up >> on linux >> >> Alfred, please, try to send SIGQUIT to mono (i. e. kill -SIGQUIT {PID}) >> when it stops processing requests. It will force mono to write thread stack >> traces to stdout. Grab them and post here, I suspect that the issue is >> simular to one experienced by me. >> >> >> 2013/8/4 Nikita Tsukanov <kek...@gmail.com> >> >>> Alfred, please, try to send SIGQUIT to mono (i. e. kill -SIGQUIT >>> {PID}) when it stops processing requests. It will force mono to write >>> thread stack traces to stdout. Grab them and post here, I suspect that >>> the issue is simular to one experienced by me. >>> >> >> _______________________________________________ >> >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> _______________________________________________ >> >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Yuriy Solodkyy (y.solod...@gmail.com)
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list