Contents
Monit
M/Monit
Wiki
Table of Contents
Jabber "Authentication failed"
Keywords: jabber auth login top
M/Monit use the SASL PLAIN authentication mechanism to login to a jabber server. If M/Monit reports an "Authentication failed" error, please make sure that you have this authentication mechanism enabled in your server. Also make sure that your jabber server software is updated. Several jabber servers (jabberd, prosody, ejabber) have a bug in their SASL PLAIN implementation which only recently has been fixed. For instance, ejabberd before version 2.1.2 had this bug.
Systems settings and scaling
Keywords: mmonit settings configuration scaling top
The below sketch describe the basic architecture of the M/Monit Connector. The Connector is the main processing component in M/Monit and is responsible for reading requests and creating responses. Many more sub-components are in use, but here we focus on the parts of the Connector which are configurable from server.xml via the <Connector> element; in practice, the number of processor threads (processors) and processorTimeout. Of these, the processors attribute is the most important.
Contrary to what one may think, increasing the number of processor threads may not help with scaling nor speed up M/Monit. In fact the effect is often the opposite. The reason is that M/Monit uses locking internally. Adding more threads may lead to lock contention, that is, threads may fight over the same lock which can slow down the server. In addition, and to a lesser extent, the OS kernel has to do context-switching between threads, that is, pause a running thread, wake up and start the next thread in the queue etc. This context switching can also lead to a slowdown if there are many threads.
As a rule of thumb we recommend to use the following settings in server.xml:
- 10 processor threads or 2 times the number of CPU cores for the processor attribute of <Connector>, never more.
- The Database connection pool defined in <Realm>. Set maxConnections to 2 times the number of processor threads + 5. Adding more connections may actually slow down the system.
Short description: 1. When a new request is received it is put in a first-in-first-out (FIFO) request queue. 2. The first available processor thread will dequeue the request, process it and create the response. If no threads are available, a new thread is created if the pool contains less than processor number of threads. Otherwise, the request waits in the queue and as soon as a processor thread becomes available it will dequeue and process the first request in the queue. If there are no more incoming requests, a processor thread will hang around for processorTimeout seconds, waiting for more work before it exit. This means that during peak hours, the pool will have max processor threads available to handle requests. and during slow periods, threads will be closed down and thereby reduce the resources used by M/Monit. 3. and 4. Once a response is created it is put on an outbound i/o queue. One I/O thread is used to flush the queue and write output non-blocking. This means that a processor thread works fast because there normally is no read or write i/o done by the thread, except if database access is required, but this is the exception as we try to use the in-memory cache as much as possible.
M/Monit log files
Keywords: mmonit log file top
Do make it a habit to check M/Monit log files from time to time, particularly the error.log. Alternatively setup Monit to watch the size of M/Monit's log files. If a M/Monit log file grows above 2GB it may cause M/Monit to stop responding. Monit agents reporting frequently in to M/Monit and producing errors, for instance because of a version number mismatch, may cause the error log to grow over time.