There is a gap in the docs. All of the following hasn't been documented yet:
It is best to disable the overcommit Linux kernel setting when using memtx. Overcommit leads to a runtime error. Overcommit documentation: see the sections on overcommit_kbytes, overcommit_memory, overcommit_ratio.
Using the swap mechanism may lead to lagging in some scenarios.
Swap + overcommit = huge lags.
@ Mons can provide information on how this works in practice, @ Totktonada knows well how it works in theory.
Original message from @ Totktonada:
Regarding swap: I guess fast fail (OOM killer) is much more wishful in the general case comparing to dramatically degraded performance (near to the level of full service unavailability).
Regarding sysctl vm.overcommit_memory: it is better to say that memtx_memory is incorrect on starting rather than be hit by the physical memory limit during work.
I guess @Mons can share experience of projects-in-production.
Recommend disabling certain system settings for memtx
Product: Tarantool Audience/target: dev Root document: https://www.tarantool.io/en/doc/latest/book/box/engines/memtx/#summary ? TBD SME: @ Mons, @ Totktonada
Details
There is a gap in the docs. All of the following hasn't been documented yet:
overcommit
Linux kernel setting when using memtx. Overcommit leads to a runtime error. Overcommit documentation: see the sections on overcommit_kbytes, overcommit_memory, overcommit_ratio.@ Mons can provide information on how this works in practice, @ Totktonada knows well how it works in theory.
Original message from @ Totktonada:
Regarding swap: I guess fast fail (OOM killer) is much more wishful in the general case comparing to dramatically degraded performance (near to the level of full service unavailability).
Regarding
sysctl vm.overcommit_memory
: it is better to say thatmemtx_memory
is incorrect on starting rather than be hit by the physical memory limit during work.I guess @Mons can share experience of projects-in-production.