CouchBase server system resources

Couchbase Server
1

I have talked about memory use by Membase (Couchbase).

When i check the Web Console and Log,

System free memory continues to decrease, and cache memory continues to increase
In the end, I’m having problems spitting out of memory.

Membase is used for session management in a server where traffic is high,
Operation is get, set, touch.

Question 1. Why does free memory decrease and cache memory grow when I use the get, set, and touch commands?
When i look at the cacheLayer document (http://docs.couchbase.com/admin/admin/Concepts/concept-cacheLayer.html), Membase is said to automatically manage memory. Is it considered to be managed via erlang, because the request traffic is faster than erlang is freeing resources?

Question 2: Even if set, touch and get are requested with the same key value, free memory decreases and cache memory increases. What is this?

I am a beginner developer who has been in development for over a year now! There may be something wrong with the question.

2

Thanks for the questions @kingbbode.

The answer to both questions are related.

Couchbase actively manages memory and works to do so efficiently within the quota of memory you give it. Because of everything Couchbase does with an item, even if you’re updating it, there may be multiple copies in memory for a short while. These will be cleaned up as additional background processing completes. It’s not managed by erlang, no. The quota you give to a bucket is managed by the KV engine.

What you see in the Web UI for a bucket, represents the memory used by the KV engine. That’ll be managed to be under the quota you specify, but may not be exactly the number of items currently in the bucket.

It’s also relevant to mention that the way memory allocators work in general (including the one we use in Couchbase), they can return memory to the OS, but will frequently hold on to memory allocated for a while because it’s more efficient to reuse memory a process already has rather than need to return it to the OS and then ask the OS for memory again. That means, for instance, if you were to update the same item a large number of times with get/set/touch, you’ll see memory usage grow to a certain level that is under the quota, but then it will stabilize there.

As you add more items, Couchbase will work to keep as much in memory as you have given it under the quota, but will occasionally give free space back to the OS.

From a user perspective, as long as you feel that in steady-state the right items are in memory and it is staying under the quota, there is no reason to worry about it moving up and down with respect to updating a single item.

Just to add a bit more technical detail…

Some of the above is accomplished by working with shared pointers in C++ and some of it is done by carefully working with the open source memory allocator, jemalloc. Couchbase leverages some of jemalloc’s functionality for tracking that quota and freeing space back to the OS if needed. As the team find better ways to manage this and balance performance with memory usage, the implementation may change but the contract is fundamentally the same: use as much space as needed to be efficient under the the quota, but don’t go above the quota.