Couchbase Server has a process to eject items from RAM when too much space is being taken up in RAM; ejection means that documents will be removed from RAM, however the key and metadata for the item will remain in RAM. When a certain amount of RAM is consumed by items, the server will eject items starting with replica data. This threshold is known as the low water mark. If a second, higher threshold is breached, Couchbase Server will not only eject replica data, it will also eject less-frequently used items. This second RAM threshold is known as the high water mark. The server determines that items are not frequently used based on a boolean for each item known as NRU (Not-Recently-used). There a few settings you can adjust to change server behavior during the ejection process. In general, we do not recommend you change ejection defaults for Couchbase Server 2.0 unless you are required to do so.
Be aware that this tool is a per-node, per-bucket operation. That means that if you want to perform this operation, you must specify the IP address of a node in the cluster and a named bucket. If you do not provided a named bucket, the server will apply the setting to any default bucket that exists at the specified node. If you want to perform this operation for an entire cluster, you will need to perform the command for every node/bucket combination that exists for that cluster.
For technical information about the ejection process, the role of NRU and server processes related to ejection, see Section 5.3, “Ejection and Working Set Management”.
Setting the Low Water Mark
This represents the amount of RAM you ideally want to consume on a node. If this threshold is met, the server will begin ejecting replica items as they are written to disk. To change this percentage for instance:
shell> ./cbepctl 10.5.2.31:11210 -b bucket_name -p bucket_password set flush_param mem_low_wat 65You can also provides an absolute number of bytes when you change this setting.
Setting the High Water Mark
This represents the amount of RAM consumed by items that must be breached before infrequently used items will be ejected. To change this amount, you use the Couchbase command-line tool, cbepctl:
shell> ./cbepctl 10.5.2.31:11210 -b bucket_name -b bucket_password set flush_param mem_high_wat 70Here we set the high water mark to be 70% of RAM for a specific data bucket on a given node. This means that items in RAM on this node can consume up to 70% of RAM before the item pager begins ejecting items. You can also specify an absolute number of bytes when you set this threshold.
Setting Percentage of Ejected Items
After Couchbase Server removes all infrequently-used items and the high water mark is still breached, the server will then eject replicated data and active data from a node whether or not the data is frequently or infrequently used. By default, the server is configured to eject 40% random active items and will eject 60% random replica data from a node.
You change also the default percentage for ejection of active items versus replica items using the Couchbase command-line tool, cbepctl:
shell> ./cbepctl 10.5.2.31:11210 -b bucket_name -p bucket_password set flush_param pager_active_vb_pcnt 50This increases the percentage of active items that can be ejected from a node to 50%. Be aware of potential performance implications when you make this change. In very simple terms, it may seem more desirable to eject as many replica items as possible and limit the amount of active data that can be ejected. In doing so, you will be able to maintain as much active data from a source node as possible, and maintain incoming requests to that node. However, if you have the server eject a very large percentage of replica data, should a node fail, the replica data will not be immediately available. In that case, Couchbase Server has to retrieve the items from disk back into RAM and then it can respond to the requests. For Couchbase Server 2.0 we generally recommend that you do not change these defaults.
For technical information about the ejection process, the role of NRU and server processes related to ejection, see Section 5.3, “Ejection and Working Set Management”.