Project

General

Profile

Lighttpd 1.4.28 + SSL == fast memory exhaustion?

Added by cat2 over 13 years ago

Hello! Just one problem from another lighty newbie...

I've just started use Lighty, and from the first seconds I was fascinated by it's speed, flexibility and of course lightness. All went OK before I tried to test my server (VPS) with siege benchmarking tool.
Lighttpd perfectly handled its job with static files and PHP scripts through FastCGI interface. But I also added SSL support to my server and decided to test Lighty with SSL separately and saw that main Lighty process started to consume memory from the very beginning of the test, and it's memory consumption process was very quick. I was forced to stop the test, because I of course didn't want my server to run out of resources.
This situation occured regardless of content type: static, PHP-generated or other, even running siege to https://my.vps.org/index.html (only 794 bytes HTML test-file) led to this problem. When I launched test again with plain HTTP version - no such a problem appeared, only with SSL/TLS connection. Lighttpd ate memory just about a 4Mb/sec, and won't stop or free it after the end of the siege.

I've read several bugreports that can be connected with my problem, like #758 and #1283, but they are describing not exactly mine, only similiar ones, and had answers like "wont't fix in 1.4.x".

So I just want to ask - is such a Lighty's behaviour is normal for my version (1.4.28)? Was it fixed in 1.5.x or 2.x, or what should I do to avoid it? Maybe i've just misconfigured Lighty in some way?
My system is CentOS 5 (kernel 2.6.18) 32-bit, Lighty config attached (not so many changes from the default one), PHP through FastCGI is used, static files' compression, no proxying to some backend at all. Siege parameters were "siege -c 300 https://my.vps.org/index.html". My VPS' parameters are: 256Mb RAM, 600MHz processor (so I've set a small number of FCGI processes).

Thanks in advance, and sorry for my bad English.

lighty-config-dir.zip (8.68 KB) lighty-config-dir.zip lighttpd config files directory (stripped unneeded ones)

Replies (2)

RE: Lighttpd 1.4.28 + SSL == fast memory exhaustion? - Added by stbuehler over 13 years ago

  • there is always a chance that you hit a real memory leak ofc, but it is more likely that it is a problem with memory fragmentation.
  • ssl has a "large" memory overhead per connection (could be 300kB, but i'm not sure).
  • your vps is a little bit small to run benchmarks
  • You can try "LD_PRELOAD"ing other allocators, like jemalloc or tcmalloc.

RE: Lighttpd 1.4.28 + SSL == fast memory exhaustion? - Added by cat2 over 13 years ago

Hi, thanks for the reply, stbuehler.

I've also made almost the same test with Lighty 1.4.29 on my virtual machine (VBox) at home computer with Arch Linux on it (config is almost the same, except compression; again the simple small index.html file it the web root) - problem persists (very fast memory consumption, led to swapping), but in that time some amount of eaten memory returned to OS, but not so much (about 5-10 Mb), so the problem is still here.
Updated to 1.4.30 and tried again - Lighty ate much lesser memory amount (about +30Mb) and stopped eating it, after the test about 2Mb were returned back to OS; but when I ran it one more time Lighttpd ate another smaller amount of memory and didn't returned it :(

I understand that hardware parameters of my VPS are quite tight, but there are another small daemons that are running on it and I also want to let them work :) Also as I said this problem occurs only when the HTTPS is used; memory overhead per encryption purposes is clear for me.

So I think that the last thing that I can try is the LD_PRELOAD trick, right?
And all this situation is explained as ralf said here, but if there is really no other method of avoiding it rather than somehow change memory allocation manager or Lighty's memory allocation behaviour? Would it be done in versions like 1.5.x or 2.x, or already done in one of them and so what should I do now?

Thanks for messing with my problem, indeed.

    (1-2/2)