Hacker News Reader

Comment by lkrubner | Hacker News Reader

This is slightly off-topic, but I worked on a Ruby project where we did something just like this:

"It was easy enough to work around the leak by adding monitoring and restarting the process whenever memory usage grew too large"

I was surprised, because I can not think of any other language and/or framework where "just restart the process" is done so often. I mean, this is not a common attitude among Java programmers, I don't think it is common among C programmers, and I don't think it is common among Python programmers. But it does seem to be fairly standard in the Ruby community. David Heinemeier Hansson admitted this used to happen with Basecamp:

http://david.heinemeierhansson.com/posts/31-myth-2-rails-is-...

Can anyone else tell me of a community where this is done so commonly?

View on HN

Hacker News itself does this.

> We restart HN every 5 or 6 days, or it gets slow (memory leaks). [1]

pg went into more depth about this somewhere, but I don't have the link on hand at the moment. Essentially, the software running it is riddled with memory leaks, but it's more time-efficient to simply reboot it every so often than it is to actually go in and fix it.

[1] https://news.ycombinator.com/item?id=4730251

That might work for HN, but it doesn't really matter if HN is down for a while. For something like Basecamp (the original 'restart it every few minutes' example, it does not seem nearly as professional.

This isn't uncommon in the python community for long running processes - especially those that frequently that create large amounts of small objects. An application server sitting in front of mongodb does exactly this. It forwards queries to mongo, then pymongo json loads the result for you, the application server does what it wants with the objects, then json dumps them to serve to clients. The json loads/dumps calls create tons of objects and memory bloat. The GC cleans them all up, yet memory isn't returned to the OS. See here:

http://effbot.org/pyfaq/why-doesnt-python-release-the-memory...

In my tests of python 2.6.6, 2.7.3, and 3.3, python 2.7.3 was by far the worst in hanging on to memory. Yet the performance increase (due to integration of simplejson) is worth the memory penalty. We use gunicorn with sync workers to serve our WSGI app and a memory watchdog to signal the worker to gracefully retire after it handles a query large enough to leave it with a large memory footprint.

Performance has been awesome and we're very happy with the result.

That was five years ago. That's not really relevant anymore. It used to be a quick fix but many things have changed since then.

Windows. Turning it off and on again always fixes the BSOD.

Reply on news.ycombinator.com