SBCL Memory Tuning
Robert Uhl
have a simple website <http://latakia.dyndns.org/tasting-notes/> driven
by SBCL, Hunchentoot, CL-SQL and some of my own code. When started up,
it consumes _half a gigabyte_; right now it's using 904 meg! This
shouldn't eat up all that much RAM: SBCL itself, the packages used (plus
ASDF & ASDF-INSTALL, which I auto-load into SBCL), then a few _small_
functions to handle everything.
I've dug around in SBCL's manual looking for tool which might display
how the heap is allocated--and have googled a fair bit--but no joy so
far. Thanks for any pointers anyone might have.
--
Robert Uhl <http://public.xdi.org/=ruhl>
> "global" connectivity (as in, access to OTHERS' PRIVATELY OWNED
> equipment) is a COURTESY and PRIVILEGE granted by the owners of
> that equipment. It is not a birthright.
--Chris Stassen
David Golden
> Anyone have any advice or tools for examining SBCL's memory usage? I
> have a simple website <http://latakia.dyndns.org/tasting-notes/>
> driven
> by SBCL, Hunchentoot, CL-SQL and some of my own code. When started
> up,
> it consumes _half a gigabyte_; right now it's using 904 meg! This
> shouldn't eat up all that much RAM: SBCL itself, the packages used
> (plus ASDF & ASDF-INSTALL, which I auto-load into SBCL), then a few
> _small_ functions to handle everything.
>
> I've dug around in SBCL's manual looking for tool which might display
> how the heap is allocated--and have googled a fair bit--but no joy so
> far. Thanks for any pointers anyone might have.
>
Well, the half-a-gig-thing is normal: SBCL just reserves a huge chunk
(use "sbcl --dynamic-space-size" to adjust) of available virtual
address space at startup and internally manages memory within that.
Because of the way modern unix-like OSes work on platforms with CPUs
with MMUs, that allocation bears only a very loose relationship to
actual memory usage. Compare the VIRT and RES figures in "top" for the
process. VIRT is how much address space it has allocated, RES is how
much it's "really" using (roughly).
Getting VIRT up to 904 megs from a bit over 512 megs might arise because
of a few tens of threads (and hunchentoot is IIRC thread-happy) - each
SBCL thread gets an additional dynamic allocation of several megs for
local stacks, and then there may be mappings for a few shared FFI
libraries that hunchentoot's dependencies pull in.
On e.g. linux, such virtually allocated but unused mem pages will only
spring into "real" existence when sbcl first writes to them, otherwise
they'll just be spooky MMU ghosts of a page full of zeroes, not taking
up real space.
Using SBCL can kind of annoying in scientific environments where big ol'
fortran codes really do expect to use all the memory they ask for, and
thus turning off the vm.overcommit "feature" of linux at the sysctl
makes a lot of sense and is common practice, so ideally (for me)
SBCL/CMUCL wouldn't use this implementation technique, but it's not
exactly a trivial job to rework.
vm.overcommit allows linux to lie to applications, promising them more
memory than even exists on the system, and it defaults to on. :-((
Juho Snellman
> Anyone have any advice or tools for examining SBCL's memory usage? I
> have a simple website <http://latakia.dyndns.org/tasting-notes/> driven
> by SBCL, Hunchentoot, CL-SQL and some of my own code. When started up,
> it consumes _half a gigabyte_; right now it's using 904 meg!
Where are you getting those numbers from? If it's from the VSIZE field
of ps, you should be aware that it has basically nothing to do with
how much memory is actually being used by the process.
> This
> shouldn't eat up all that much RAM: SBCL itself, the packages used (plus
> ASDF & ASDF-INSTALL, which I auto-load into SBCL), then a few _small_
> functions to handle everything.
I have a process with sbcl, Araneida, clsql and a web application is
using 28MB of memory at startup. While Hunchentoot has quite a lot of
extra dependencies compared to Araneida, and can thus be reasonably
expected have a bigger footprint, I would still be surprised if it was
using up 470MB more...
> I've dug around in SBCL's manual looking for tool which might display
> how the heap is allocated--and have googled a fair bit--but no joy so
> far. Thanks for any pointers anyone might have.
The standard CL function ROOM should give you some information that's
more relevant.
--
Juho Snellman
Rafal Strzalinski
> Robert Uhl <eadm...@NOSPAMgmail.com> wrote:
>> Anyone have any advice or tools for examining SBCL's memory usage? I
>> have a simple website <http://latakia.dyndns.org/tasting-notes/> driven
>> by SBCL, Hunchentoot, CL-SQL and some of my own code. When started up,
>> it consumes _half a gigabyte_; right now it's using 904 meg!
>
> Where are you getting those numbers from? If it's from the VSIZE field
> of ps, you should be aware that it has basically nothing to do with
> how much memory is actually being used by the process.
>
>> This
>> shouldn't eat up all that much RAM: SBCL itself, the packages used (plus
>> ASDF & ASDF-INSTALL, which I auto-load into SBCL), then a few _small_
>> functions to handle everything.
>
> I have a process with sbcl, Araneida, clsql and a web application is
> using 28MB of memory at startup. While Hunchentoot has quite a lot of
> extra dependencies compared to Araneida, and can thus be reasonably
> expected have a bigger footprint, I would still be surprised if it was
> using up 470MB more...
Hunchentoot + slime takes about 50MB (RSS) at start.It is easy to reduce
footprint to 20MB (RSS) by dumping custom core with load dependencies.
--
Best regards,
Rafał Strzaliński
http://nablaone.net
Ondrej Svitek
> Anyone have any advice or tools for examining SBCL's memory usage?
I think pmap would be of interest for you, e.g.:
ondrej@snowcrash:~$ pmap `pidof sbcl`
5874: sbcl
01000000 4K rwx-- /usr/local/lib/sbcl/sbcl.core
01001000 40952K rwx-- [ anon ]
05000000 4K rwx-- /usr/local/lib/sbcl/sbcl.core
05001000 49144K rwx-- [ anon ]
...
b8000000 8K rwx-- /lib/ld-2.5.so
bffeb000 84K rwx-- [ stack ]
ffffe000 4K r-x-- [ anon ]
total 885248K
But as stated above, you usually don't have to worry about this
overcommitting scheme. (Almost) all memory pages are allocated with
MAP_NORESERVE flag and application "claims" space upon writing to
them. Or get a SIGSEGV, when low on free memory.
One issue, where this matters, is when you have limited virtual memory
usage by some means (e.g. RLIMIT) to a low value, say 256MB. In this
scenario SBCL won't succeed to "allocate" desired memory regions and
will fail to start (at least, this is what happens on Linux).
Depending on circumstances, you could get away with setting --dynamic-
space-usage option to some low value, but more likely, you'd have to
resort to tampering with address space layout in src/compiler/*/
parms.lisp and recompiling SBCL.
This file can also give you an insight on pmap output (look for
various -space-start, -space-end constants).
Juho Snellman
> One issue, where this matters, is when you have limited virtual memory
> usage by some means (e.g. RLIMIT) to a low value, say 256MB. In this
> scenario SBCL won't succeed to "allocate" desired memory regions and
> will fail to start (at least, this is what happens on Linux).
> Depending on circumstances, you could get away with setting --dynamic-
> space-usage option to some low value, but more likely, you'd have to
> resort to tampering with address space layout in src/compiler/*/
> parms.lisp and recompiling SBCL.
That should not be needed for recent SBCL releases. The memory regions
that --dynamic-space-size doesn't affect are much smaller (a total of
around 3MB).
--
Juho Snellman