From: <me...@ho...> - 2005-04-04 15:59:47
Attachments:
x.lisp
|
I've found a message describing the exact same problem: http://article.gmane.org/gmane.lisp.steel-bank.devel/1879 SBCL allocates two buffers on the wrong thread (accept), and never calls deallocate-system-memory when the thread exits, so not even restarting the server can discard the accumulated buffers. Some measurements were conducted on sbcl 0.8.21 with the attached program against apache bench. GC was turned off. /usr/sbin/ab -n 10000 -c 64 http://localhost:2002/ concurrency | 1 8 64 ------------------------------------------------ without patches | 6.988660 6.779214 6.736636 B Downing's patch | 6.530214 6.319840 6.491603 Performance degradation is still not a problem at 64 threads as there is not much lock contention. The 'connection reset by peer' problem is still there, though, but it's hard to trigger (seems to happen more after startup). Gabor |
From: <me...@ho...> - 2005-04-05 11:23:05
Attachments:
final.patch
x.lisp
|
On Monday 04 April 2005 18:00, G=C3=A1bor Melis wrote: > I've found a message describing the exact same problem: > http://article.gmane.org/gmane.lisp.steel-bank.devel/1879 > > SBCL allocates two buffers on the wrong thread (accept), and never calls > > deallocate-system-memory when the thread exits, so not even restarting > the > server can discard the accumulated buffers. > > Some measurements were conducted on sbcl 0.8.21 with the attached > program > against apache bench. GC was turned off. > > /usr/sbin/ab -n 10000 -c 64 http://localhost:2002/ > > concurrency | 1 8 64 > ------------------------------------------------ > without patches | 6.988660 6.779214 6.736636 > B Downing's patch | 6.530214 6.319840 6.491603 > > Performance degradation is still not a problem at 64 threads as there is > not > much lock contention. > > The 'connection reset by peer' problem is still there, though, but it's > hard to trigger (seems to happen more after startup). I'd hate to monopolize this thread, but I've found the cause of the connect= ion=20 reset by peer problem: the test program has not read the request. With that bug out of the way the test ran for a long time producing only th= e=20 occasional "The value NIL is not of type WEAK-POINTER." message. The attach= ed=20 patch makes the finalizer thread safe. With this and the above patch applie= d=20 the test server survives the apache bench onslaught with 60 threads seeming= ly=20 indefinitely. > > Gabor |