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
|