Which Common Lisp implementation is suited for a long running web
application on a VPS (virtual private server)? Web server:
Hunchentoot.
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
Stefan Scholl <······@no-spoon.de> wrote:
+---------------
| Which Common Lisp implementation is suited for a long running web
| application on a VPS (virtual private server)? Web server:
| Hunchentoot.
+---------------
I don't know about either VPS or Hunchentoot in detail, but I've
been using CMUCL [on both FreeBSD & Linux] to run my own "appsrv" web
infrastructure [which does some of the same things as Hunchentoot]
with uptimes of up to a year at a shot. The CMUCL-hosted application
has never been the cause of the server rebooting; it's always been
something else [co-lo mandated reboots, O/S upgrades, etc.].
There is some kind of periodic background consing of ~300 bytes/s
that goes on which I suspect is because I'm using CMUCL's green
threads [the "multiprocessing" package, though it's really just
coroutines] and at every "idle timeout" there's a context switch
which allocates ~30 bytes somewhere, but I haven't bothered to
track it down since the GC collects it all just fine every couple
of hours, e.g., from the log file of one of the servers:
; Oct 13 17:11:37.06 GC: Start: 17.814016 MB in use.
; Oct 13 17:11:37.07 GC: Done: 5.818672 MB in use, 11.995344 MB freed, 0.01 secs.
; Oct 14 02:25:35.89 cgi-sock[3116]: GET "/~rpw3/uf.lhp"
; Oct 14 03:40:55.13 GC: Start: 17.831992 MB in use.
; Oct 14 03:40:55.15 GC: Done: 5.86108 MB in use, 11.970912 MB freed, 0.02 secs.
; Oct 14 14:11:59.72 GC: Start: 17.866448 MB in use.
; Oct 14 14:11:59.73 GC: Done: 5.87048 MB in use, 11.995968 MB freed, 0.01 secs.
; Oct 15 00:43:05.57 GC: Start: 17.875824 MB in use.
; Oct 15 00:43:05.59 GC: Done: 5.878736 MB in use, 11.997088 MB freed, 0.02 secs.
; Oct 15 01:24:38.94 cgi-sock[3117]: GET "/~rpw3/uf.lhp"
; Oct 15 07:39:11.12 cgi-sock[3118]: GET "/hacks/lisp/appsrv-demo.lhp"
; Oct 15 11:03:18.23 GC: Start: 17.887784 MB in use.
; Oct 15 11:03:18.25 GC: Done: 5.934576 MB in use, 11.953208 MB freed, 0.02 secs.
; Oct 15 21:34:45.63 GC: Start: 17.947248 MB in use.
; Oct 15 21:34:45.64 GC: Done: 5.922192 MB in use, 12.025056 MB freed, 0.01 secs.
That 5-6 MB base usage stays constant for months at a time, only
going up significantly if I do "live" patching of the code [and
even then, when I'm done a (GC :FULL T) usually drops it again].
So I'd say CMUCL is certainly a viable candidate for a long-running
web app server, if you're using BSD or Linux...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: John Thingstad
Subject: Re: CL Implementation for long running web app (Hunchentoot)
Date:
Message-ID: <op.t0al18grpqzri1@pandora.upc.no>
P� Tue, 16 Oct 2007 08:54:38 +0200, skrev Stefan Scholl
<······@no-spoon.de>:
> Which Common Lisp implementation is suited for a long running web
> application on a VPS (virtual private server)? Web server:
> Hunchentoot.
>
>
Hunchentoot was developed on LispWorks. It seems to work fine there.
SS> Which Common Lisp implementation is suited for a long running web
SS> application on a VPS (virtual private server)?
if you want a free implementation, there's not that much choice, ye?
i suspect you might have problems with VPS -- for example, Virtuozzo-based
ones have a strict limit on _virtual_ memory given to applications, so i'm
afraid it won't be pleasant to run CMUCL/SBCL on them. other, like Xen-based
might work better..
On Oct 16, 4:01 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> SS> Which Common Lisp implementation is suited for a long running web
> SS> application on a VPS (virtual private server)?
>
> if you want a free implementation, there's not that much choice, ye?
>
> i suspect you might have problems with VPS -- for example, Virtuozzo-based
> ones have a strict limit on _virtual_ memory given to applications, so i'm
> afraid it won't be pleasant to run CMUCL/SBCL on them. other, like Xen-based
> might work better..
I ran a small web-app quite happily using TBNL on SBCL on a UML-based
VPS a year or so ago, though ultimately the memory requirements of a
second app pushed me over the line where it made more sense to get a
proper dedicated server. It's certainly doable, though.
Rob
Alex Mizrahi wrote:
> SS> Which Common Lisp implementation is suited for a long running web
> SS> application on a VPS (virtual private server)?
>
> if you want a free implementation, there's not that much choice, ye?
>
> i suspect you might have problems with VPS -- for example,
> Virtuozzo-based ones have a strict limit on _virtual_ memory given to
> applications, so i'm afraid it won't be pleasant to run CMUCL/SBCL on
> them. other, like Xen-based might work better..
I assume if the available memory in Xen was configured lower than
CMUCLs/SBCL's big-bang dynamic space size allocation, there could be
problems of sudden death by OOM. That said, even the entry-level xen
hosting packages typically allow enough vmem with some fiddling.
Following could be considered some SBCL on Xen tips I guess:
I. VMEM
e.g out of box, an entry-level xen hosting package might only have 128MB
(virtual) ram + 96MB swap, say, but it also might have something like
4GB disk space, which you can just make a swap file on and use as
further swap or (friendlier) just talk to your hosting company and get
them to adjust your swap/fs split, until you've got enough vmem to be
bigger than a sensible --dynamic-space-size and a reasonable number of
thread stacks (which IIRC are malloced as needed on sbcl).
Of course, you should try to keep the usual active memory usage within
real RAM for performance. You could just size
your --dynamic-space-size to fit in your RAM, but that might be rather
low, so you might want a larger dynamic space size to allow for larger
transients, and then it is smart to have enough vmem backing to match
the entire dynamic space size: then there is opportunity for a somewhat
more graceful failure than a sudden firey OOM death when sbcl tries to
use a page the kernel can't really provide, which leads on to the major
point:
*** Setting linux sysctl vm.overcommit=2 is good, stops the kernel lying
so much about available memory - sbcl then won't even start until
there's enough vmem to back your chosen (or the
default) --dynamic-space-size. Then, failure is a (relatively)
graceful heap exhaustion error message, rather than e.g. triggering of
the dreaded linux OOM killer, which may do something (relatively)
reasonable (slaying SBCL) or may not (slaying some other process).
(I do sometimes wish SBCL had an incremental allocator...)
II. MULTITHREADING
Loosely related: Multithreaded SBCL seems to work okay under Xen guests
on x86, provided you also use a distro with a glibc build that has the
xen-oriented "nosegneg" tls support magic (nowadays most xen hosting
packages do unless you select a quite old linux distro with them).
[and an ld that actually uses the correct tls libraries under xen guests
(typically (redhat) controlled by a kernelcap-<blah> file
containing "hwcap 0 nosegneg" in /etc/ld.so.conf.d) - I mention this
latter part because following a manual upgrade I somehow wound up with
nosegneg tls libraries but a ldconfig that didn't to use them because
that hwcap info was missing - because I hadn't installed the kernel
package that the kernelcap file typically comes from, since I was using
a custom build...]
David Golden wrote:
> *** Setting linux sysctl vm.overcommit=2 is good,
Gaah. vm.overcommit_memory = 2
And remember that vm.overcommit_ratio exists too.
Alex Mizrahi <········@users.sourceforge.net> wrote:
> i suspect you might have problems with VPS -- for example, Virtuozzo-based
> ones have a strict limit on _virtual_ memory given to applications, so i'm
> afraid it won't be pleasant to run CMUCL/SBCL on them. other, like Xen-based
> might work better..
It's Virtuozzo-based. Is "won't be pleasant" more like
"impossible", "slow", or "you have to spend a weekend configuring
the hell out of the system"?
I toss a coin for SBCL or CMUCL. Both were mentioned here and in
e-mails. At least they sould run with a small footprint, if they
run at all.
Thanks everybody!
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
(message (Hello 'Stefan)
(you :wrote :on '(Fri, 19 Oct 2007 15:53:33 +0200))
(
??>> i suspect you might have problems with VPS -- for example,
??>> Virtuozzo-based ones have a strict limit on _virtual_ memory given to
??>> applications, so i'm afraid it won't be pleasant to run CMUCL/SBCL on
??>> them. other, like Xen-based might work better..
SS> It's Virtuozzo-based. Is "won't be pleasant" more like
SS> "impossible", "slow", or "you have to spend a weekend configuring
SS> the hell out of the system"?
i suspect that with default settings SBCL won't be able to run on 512 MB vz
VPS because it allocates about 512 MB virtual memory from start.
quite probably you'll be able to tweak this (--dynamic-space-size option
from command line), though, but still i find it unpleasant to be billed for
"reserved" memory rather than actually used -- i.e. you'd need 512MB vz VPS
where it could be done with 256 MB "other" VPS.
from my personal experience, i was not able to launch Java web server in a
stable way on 256 MB VPS, and i believe that SBCL is even more demanding
than Java. however it might be more tunable, i don't know..
so i'd recommend to do trial if it's possible, to choose Xen one if
possible, and, finally, ask hosters if it supports running Java (e.g. Apache
Tomcat, J2EE) -- that can be indicator whether it will be able to run Lisp
or not, although not 100% exact.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"Hanging In The Balance Of Deceit And Blasphemy")
From: Maciek Pasternacki
Subject: Re: CL Implementation for long running web app (Hunchentoot)
Date:
Message-ID: <20071022001206.2457e54d@localhost>
On Sun, 21 Oct 2007 15:44:36 +0300
"Alex Mizrahi" <········@users.sourceforge.net> wrote:
> ??>> i suspect you might have problems with VPS -- for example,
> ??>> Virtuozzo-based ones have a strict limit on _virtual_ memory given to
> ??>> applications, so i'm afraid it won't be pleasant to run CMUCL/SBCL on
> ??>> them. other, like Xen-based might work better..
>
> SS> It's Virtuozzo-based. Is "won't be pleasant" more like
> SS> "impossible", "slow", or "you have to spend a weekend configuring
> SS> the hell out of the system"?
>
> i suspect that with default settings SBCL won't be able to run on 512 MB vz
> VPS because it allocates about 512 MB virtual memory from start.
> quite probably you'll be able to tweak this (--dynamic-space-size option
> from command line), though, but still i find it unpleasant to be billed for
> "reserved" memory rather than actually used -- i.e. you'd need 512MB vz VPS
> where it could be done with 256 MB "other" VPS.
Just checked on 256MB RAM Virtuozzo VPS hosted at tektonic.net:
·····@3ofcoins:~$ uname -a
Linux 3ofcoins.net 2.6.9-023stab043.1-smp #1 SMP Mon Mar 5 16:35:19 MSK 2007
i686 GNU/Linux ·····@3ofcoins:~$ free -m
total used free shared buffers cached
Mem: 256 120 135 0 0 0
-/+ buffers/cache: 120 135
Swap: 0 0 0
·····@3ofcoins:~$ sbcl
This is SBCL 1.0.3, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (room)
Dynamic space usage is: 24,456,392 bytes.
Read-only space usage is: 1,912 bytes.
Static space usage is: 1,936 bytes.
Control stack usage is: 1,276 bytes.
Binding stack usage is: 328 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.
Breakdown for dynamic space:
9,764,416 bytes for 11,021 code objects.
3,251,592 bytes for 74,716 instance objects.
3,165,776 bytes for 51,848 simple-vector objects.
2,838,552 bytes for 354,819 cons objects.
5,456,552 bytes for 131,089 other objects.
24,476,888 bytes for 623,493 dynamic objects (space total.)
*
Starts just fine. Didn't try to start long-running service though; I'll be
actually trying this in next few weeks.
Regards,
Maciej
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { Any road followed to its end leads precisely nowhere. Climb
,|{-}|}| }\/ the mountain just a little to test it's a mountain. From the top
\/ |____/ of the mountain you cannot see the mountain. } ( F.Herbert ) -><-
On Tue, 16 Oct 2007 08:54:38 +0200, Stefan Scholl wrote:
> Which Common Lisp implementation is suited for a long running web
> application on a VPS (virtual private server)? Web server:
> Hunchentoot.
Many of our members at The Tech Co-op run various Lisps on our Xen hosting
platform. I've run multiple SBCLs in as little as 128mb physical ram on
Xen. One of our members runs a bknr based site running under CMUCL, and I
think another may be using allegro. Our website (http://www.tech.coop)
runs in a cliki that has been up for almost 2 years, i'd say that
counts as long running. At least one of our members runs runs a
hunchentoot based blog on our shared hosting platform, which itself runs on
Xen.
We run both common-lisp.net and cliki under Xen as well. There are certain
steps one must take for SBCL to be happy under Xen. On i386, you'll need
to install a patched libc6. This isn't needed on AMD64. We offer both,
though personally i think 32 bit makes the most sense in a VPS situation
unless you really need the large heap.
If you're not installing xen yourself, but rather going with a hosting
provider, make sure they are running a version of Xen that supports sbcl.
The older Xen 2 is known to work, as is the quite new Xen 3.0.3. I'm not
sure about 3.1.
(plug :type 'shameless
"The Tech Co-op is a great choice for a Xen provider. We explicitly
support Common Lisp, and our new prices are dirt cheap. ")
HTH,
drewc
http://tech.coop
>
>
--
Posted via a free Usenet account from http://www.teranews.com