0
@@ -624,6 +624,46 @@ applications, each which must be available at all times.
0
 This option may only occur once, in the global server configuration.
0
 The default value is '300'.
0
 
0
+[[PassengerMaxRequests]]
0
+==== PassengerMaxRequests <integer> ====
0
+The maximum number of requests an application instance will process. After
0
+serving that many requests, the application instance will be shut down and
0
+Phusion Passenger will restart it.
0
+
0
+This option may occur in the global server configuration, in a virtual host
0
+configuration block and in `<Directory>` or `<Location>` directives. The
0
+default value is '0', which means the maximum number of requests is unlimited.
0
+
0
+[[PassengerMemoryLimit]]
0
+==== PassengerMemoryLimit <integer> ====
0
+The maximum amount of memory an application instance may use, in megabytes.
0
+Once an application instance has surpassed its memory limit, it will process
0
+all the requests currently present in its queue and then shut down.
0
+
0
+This option may occur in the global server configuration, in a virtual host
0
+configuration block and in `<Directory>` or `<Location>` directives. The
0
+default value is '200'. A value of '0' indicates the maximum memory usage is
0
+unlimited.
0
+
0
+[TIP]
0
+=====================================================
0
+The <<PassengerMemoryLimit,PassengerMemoryLimit>> directive requires the
0
+user running the application (see <<PassengerUserSwitching,PassengerUserSwitching>>)
0
+to have access to the `/proc` file system or to be able to inspect its status
0
+with `ps` (which in Linux systems basically means the same thing, since `ps`
0
+reads process information from `/proc`). Therefore, in servers running with
0
+tight permissions on that file system, this directive may not work.
0
+=====================================================
0
+
0
+[TIP]
0
+=====================================================
0
+The <<PassengerMaxRequests,PassengerMaxRequests>> and
0
+<<PassengerMemoryLimit,PassengerMemoryLimit>> directives should be considered
0
+as workarounds for misbehaving applications. It is advised that you fix the
0
+problem in your application rather than relying on these directives as a
0
+measure to avoid memory leaks.
0
+=====================================================
0
+
0
 === Ruby on Rails-specific options ===
0
 
0
 ==== RailsAutoDetect <on|off> ====
0
@@ -724,6 +764,18 @@ Some Ruby on Rails applications and libraries are not compatible with smart spaw
0
 If that's the case for your application, then you should use 'conservative' as
0
 spawning method.
0
 
0
+smart-lv2::
0
+This spawning method is similar to 'smart' but it skips the framework spawner
0
+and uses the application spawner directly. This means the framework code is not
0
+cached between multiple applications, although it is still cached within
0
+instances of the same application.
0
++
0
+*Pros:* It is compatible with a larger number of applications when compared to
0
+the 'smart' method, and still performs some caching.
0
++
0
+*Cons:* It is slower than smart spawning if you have many applications which
0
+use the same framework version.
0
+
0
 conservative::
0
 This spawning method is similar to the one used in Mongrel Cluster. It does not perform
0
 any code caching at all.
0
@@ -1229,7 +1281,7 @@ inactive = 1
0
 
0
 ----------- Domains -----------
0
 /var/www/projects/app1-foobar: 
0
-  PID: 9617      Sessions: 0
0
+  PID: 9617      Sessions: 0    Processed: 7       Uptime: 2m 23s
0
 --------------------------------------------------
0
 
0
 The 'general information' section shows the following information:
0
@@ -1247,26 +1299,33 @@ value is set to 0, in which case application instances are never shut down via i
0
 time). The value of 'inactive' equals `count - active`.
0
 
0
 The 'domains' section shows, for each application directory, information about running
0
-application instances. The 'sessions' field shows how many HTTP client are currently
0
-in the queue of that application instance, waiting to be processed.
0
+application instances:
0
+
0
+Sessions:: Shows how many HTTP client are currently in the queue of that application
0
+Instance, waiting to be processed.
0
+Processed:: Indicates how many requests the instance has served (see the
0
+<<PassengerMaxRequests,PassengerMaxRequests>> configuration directive).
0
+Uptime:: Shows for how long the application instance has been running.
0
 
0
 Since Phusion Passenger uses fair load balancing by default, the number of sessions for the
0
 application instances should be fairly close to each other. For example, this is fairly
0
 normal:
0
 --------------------------------
0
-  PID: 4281      Sessions: 2
0
-  PID: 4268      Sessions: 0
0
-  PID: 4265      Sessions: 1
0
-  PID: 4275      Sessions: 1
0
+  PID: 4281      Sessions: 2      Processed: 7      Uptime: 5m 11s
0
+  PID: 4268      Sessions: 0      Processed: 5      Uptime: 4m 52s
0
+  PID: 4265      Sessions: 1      Processed: 6      Uptime: 5m 38s
0
+  PID: 4275      Sessions: 1      Processed: 7      Uptime: 3m 14s
0
 --------------------------------
0
 
0
 But if you see a "spike", i.e. an application instance has an unusually high number of
0
 sessions compared to the others, then there might be a problem:
0
 --------------------------------
0
-  PID: 4281      Sessions: 2
0
-  PID: 17468     Sessions: 8     <---- "spike"
0
-  PID: 4265      Sessions: 1
0
-  PID: 4275      Sessions: 1
0
+  PID: 4281      Sessions: 2      Processed: 7      Uptime: 5m 11s
0
+  PID: 17468     Sessions: 8 <-+  Processed: 2      Uptime: 4m 47s
0
+  PID: 4265      Sessions: 1   |  Processed: 6      Uptime: 5m 38s
0
+  PID: 4275      Sessions: 1   |  Processed: 7      Uptime: 3m 14s
0
+                               |
0
+                               +---- "spike"
0
 --------------------------------
0
 
0
 Possible reasons why spikes can occur: