On Monday 04 April 2005 18:00, G=C3=A1bor Melis wrote:
> I've found a message describing the exact same problem:
> SBCL allocates two buffers on the wrong thread (accept), and never calls
> deallocate-system-memory when the thread exits, so not even restarting
> server can discard the accumulated buffers.
> Some measurements were conducted on sbcl 0.8.21 with the attached
> 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
> 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=
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=
occasional "The value NIL is not of type WEAK-POINTER." message. The attach=
patch makes the finalizer thread safe. With this and the above patch applie=
the test server survives the apache bench onslaught with 60 threads seeming=