Hi list,
I've a problem with elephant and threading that drives me to despair. In the
hope that anyone solved similar problems and may suggest a solution I am
posting this thread.
I am running the latest darcs version of elephant on a 64 bit debian dual-core
system on sbcl 1.0.40.0.debian with berkeley db 4.7.25.
The last days I ran a performance test on our system. Since the system is
multi-threaded and we use transactions, we also use mutexes to synchronize the
write and read operations (our mutex synchronisation is working!). The test I
performed has only read the storage, i.e. clients started a TCP connection and
invoked a read operation on the system. If more than 4 clients/threads read
concurrently the storage, the memory/swap of the server system was fully
reserved by the SBCL process and not released after the requests.
The requested data we use is persisted by using defpclass on several class
definitions.
During my tests I made the following observations:
* the more intensive the algorithm and reading operations, the faster the
memory is reserved, i.e. more reading operations lead to more memory usage
* running SBCL on one core (with taskset) leads to a common memory usage, i.e.
constantly about 140 - 150 MB for the SBCL process
* in the past we made a similar test, that worked properly - but since this
test, our data model has become more complex, i.e. we use more objects that are
handled by each request
Sincerely,
Lukas
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
