Lighttpd

How about sharing config and possible fastcgi info, as well as a possible trace on when it out of memorys? This would help targetting the issue at hand.

-- Lfe

Try running the server under valgrind (http://valgrind.org/) and see if it reports a memory leak.

For now the problem actually stopped as sudden as it started. We are pretty sure we were attacked. Check the two attached ganglia graphs about memory usage.
We could share the config in private to avoid revealing even more information about possible attack scenarios, if you understand.

-- mail

We noticed that the access log during the problems contains strange block of 0x00's displayed in the screenshot from time to time. The logs of today, where we experience no problems, does not contain these. Can this be some kind of overflow?

-- mail

We had no problem for two months now and all of a sudden it started again. Please find a valgrind trace attached! r2019 didn't solve the problem either!

-- mail

The valgrind trace is not really helping as long you didn't have a complete one (i.e., terminate lighttpd).

Do you use server.max-worker? See http://trac.lighttpd.net/trac/wiki/Docs%3AMultiProcessor - that may be the source of your access.log problems.

Your config and a little description what your server is doing (serving big files with fastcgi? ssl? ...) would be nice too.

And just as a process is using much memory that doesn't mean it leaks!

Valgrind: OK sorry, didn't know that.

max-worker: no!

Our solution was to switch to Apache for a period of time, finished coding of our new site and cleaned up our rewrite rules a lot. Since then the problem is gone. We don't know if it was the new php coding or the config cleanup which solved it in the end.

-- mail

Hm k, nice it works for you now.

As you obviously can't provide more info about this bug and it seems to work for you now, i close it with "worksforme"