Number of sub-monitors/monitor instances. This number should usually be steady. If there is a consistent increase in this number, it is an indication that monitors are being spawned but not terminating. This will eventually lead to an out of memory condition.

Number of monitor instances

Number of contexts in the correlator. This includes the main context plus any user-defined contexts. This number should usually be steady.

Number of contexts

Sum of listeners in all contexts. This includes each on statement and each stream source template. This number should usually be steady. If ls is increasing but sm is not, this is probably due to custom EPL or JMon that is creating listeners that are never satisfied or quit.

Number of listeners

Route queue. Sum of the number of routed events on the input queues of all contexts. This number is typically 0 or near 0. If this number is largish (greater than 50), there is probably a very lengthy loop (possibly infinite) routing events.

Number of events

Enqueue queue. Number of events on the enqueued events queue. This number is typically 0 or near 0.

Number of events

Input queue. Sum of the number of entries on the input queues of all contexts. This number is typically 0 or near 0. If this number increases, this indicates that contexts are not keeping up with incoming events.

Every context has an input queue, and each queue has a maximum size of 20,000 events. It is perfectly normal to see this number in the hundreds. But if this number is steadily increasing, this indicates that the system is not keeping up and may eventually block senders. Either the correlator simply cannot process the events at the rate they arrive, or there is back pressure from the output queue.

Number of events

Output queue. Number of events waiting on the correlator's output queue to be dispatched to any registered receivers. This number is typically 0 or near 0. If this number increases, this indicates one or more slow receivers.

The output queue is fed by the emit or send...to statement. There may be multiple processes attached as consumers to the output queue. If any one of them cannot consume events at the rate the correlator is emitting them, the queue will back up and this number will start getting large. By default, it has a limit of 10,000 events per receiver. If this limit is reached, the correlator will, by default, stop processing events and wait for the output queue to drain.

Number of events

Total number of enqueued events on the input queues of all public contexts. This is a subset of the events included in the iq count. This number is typically 0 or near 0. If this number increases, this indicates that contexts are not keeping up with incoming events.

Number of events

Name of the slowest context.

Not applicable

For the context identified by lcn, this is the number of entries on its queue.

Number of events

For the context identified by lcn, this is the time difference between its current logical time and the most recent time tick added to its input queue.

Seconds

Number of events the correlator has received from external sources since the correlator was started. This number increases as events are received. It only increases; it can never go down.

Number of events

Number of events the correlator has sent to receivers since the correlator was started. This number normally increases as events are emitted. This number includes duplicate events sent to multiple receivers. For example, you inject EPL code that emits an event, and there are five receivers that are subscribed to channels that publish that event. In this situation, the tx count goes up by five. Although there was only one event, it was sent five times.

Number of events

Route total. Total number of events that have been routed across all contexts since the correlator was started. This number normally increases as events are routed.

Number of events

Number of consumers, that is, the number of components connected to receive emitted events. This number should usually be steady.

Number of connections

Virtual memory. This number should usually be steady, though may vary slightly.

Kilobytes

Physical memory. This number should usually be steady, though may vary slightly.

Kilobytes

Run queue. Number of contexts that have work to do but are not currently running. This number is typically 0 or near 0. If this number increases, this indicates a performance issue and that the application is not keeping up.

Number of contexts

Rate at which pages are being read from swap space. This number is typically 0 or near 0. If si is non-zero, the host is running out of memory and will not perform well. This severely affects latency, and it is possible that this will prevent status lines being regularly logged every five seconds (the default behavior) or at an interval that you specify.

Pages per second

Rate at which pages are being written to swap space. This number is typically 0 or near 0. If so is non-zero, the host is running out of memory and will not perform well. This severely affects latency, and it is possible that this will prevent status lines being regularly logged every five seconds (the default behavior) or at an interval that you specify.

Pages per second

Slowest receiver name. The receiver with the largest number of incoming events waiting to be processed.

Not applicable

Slowest receiver queue size. For the receiver with the largest number of incoming events waiting to be processed, this is the number of events that are waiting.

Number of events