gem version

Dealing with memory leaks

Relevant selection for this article:


Analyzing application memory use

You can use passenger-status to inspect the memory that your application process(es) are currently using. There are also other tools such as ps and top, but their output must be filtered manually and can even be misleading (see: accurately measuring memory use).

It is normal for processes to initially keep increasing their memory use as they warm up, handling their first few requests. However, if the increase continues indefinitely then the application is most likely leaking memory, which will eventually make the system grind to a halt with "out of memory" errors. Note that memory leaks may also originate from libraries that your application depends on.

Protecting the server with Passenger

Passenger can restart application processes in order to reclaim leaked memory. This is done in the background so that users do not experience any disturbance.

The max_requests configuration option can be used to restart processes based on how many requests they have handled. You tune this number depending on the speed and the amount of memory leaking.

A more advanced option is memory_limit (available in Passenger Enterprise), which checks the memory usage of a process after each request and restarts it in the background if the specified limit was exceeded.

Memory leaks elsewhere

If the memory usage of your application is stable, but the system still keeps running out of memory, there might be a memory leak in another component. There are presently no known memory leaks in any of the Passenger components, and to rule out this possibility in your setup can use the passenger-memory-stats command. It shows the memory use (in the "Private" column) of Passenger core components as well as the application processes.

light mode dark mode
Passenger 6 Passenger 6