Changed RN to:
Previously, there was only one process that was responsible for monitoring
and managing all the other underlying server processes. This includes Moxi and memcached, and also statistics gathering.
Now there are two processes. One is responsible for just Moxi/Memcached and the other is responsible for monitoring all other processes.
This should help prevent the max_restart_intensity seen when timeouts start and temporarily disrupted the server. The most noticeable
change you see with this fix is that there are now two beam.smp processes running on Linux and two erl.exe running
on Windows. For more details, see <xref linkend="couchbase-underlying-processes" />.
Updated Content in "Monitoring Couchbase: Underlying Server Processes" to:
There are several different server processes that constantly run in Couchbase Server whether or not the server is actively handling reads/writes or handling other operations from a client application. Right after you start up a node, you may notice a spike in CPU utilization, and the utilization rate will plateau at some level greater than zero. The following describes the ongoing processes that are running on your node:
beam.smp on Linux: erl.exe on Windows
These processes are responsible for monitoring and managing all other underlying server processes such as ongoing XDCR replications, cluster operations, and views. Prior to 2.1.0 we had a single process for memcached, Moxi and to monitor all server processes. This resulted in server disruption and crashes due to lack of memory.
As of Couchbase Server 2.1.0+ there is a separate monitoring/babysitting process running on each node. The process is small and simple and therefore unlikely to crash due to lack of memory. It is responsible for spawning and monitoring the second, larger process for cluster management, XDCR and views. It also spawns and monitor the processes for Moxi and memcached. If any of these three processes fail, the monitoring process will re-spawn them.
The main benefit of this approach is that an Erlang VM crash will not cause the Moxi and memcached processes to also crash. You will also see two beam.smp or erl.exe processes running on Linux or Windows respectively.
The set of log files for this monitoring process is ns_server.babysitter.log which you can collect with cbcollect_info. See .
memcached: This process is responsible for caching items in RAM and persisting them to disk.
moxi: This process enables third-party memcached clients to connect to the server.