I am facing a problem I don't really know how to approach.
On my Linux Debian box I am running SBCL of the latest (1.04) revision
and I am really concerned about the big
memory usage of the whole process.
Using the top command I got following info:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2294 lispu 15 0 884m 96m 16m S 0.0 38.6
0:46.22 sbcl
which means that my lisp image uses 884MB of virtual memory and 96MB
of physical memory.
My project depends on following packages: (:uffi :cl-gd :zpb-
ttf :hunchentoot :cl-who :s-xml :drakma), sure they
depend on other projects which probably makes it pretty big.
Also, sometimes when I connect to the lisp image (it runs under
detachtty) using slime and modify/evaluate a
function I see a lot of hard drive activity which may take a few
seconds, after that the amount of free memory in
the system drops from 90MB to 3MB (after a few evaluations).
Is it ok for the lisp image to be so big? If there is a memory leak
how could it be found?
Thank you,
Andrew
>>>>> "Trastabuga" == Trastabuga <·········@gmail.com> writes:
Trastabuga> Is it ok for the lisp image to be so big?
Yes, this is normal. SBCL will *allocate* a huge amount of memory but
only *use* the appropriate fraaction of it. Other implementation does
the same thing. At least on Linux, you can allocate more memory than
you have as long you do not actually use too much, everything till run
fine. This is also sometimes referred to as "overcommit" in memory
allocation.
Why SBCL is handling its memory like that I am not entirely sure, but
I guess it has something to do with the layout of memory and what data
is stored where. The OS memory management system is quite clever and
will pull in only the stuff that is actually used.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)