На одном физическом сервере (Debian 10) работают PostgreSQL (постоянное хранилище) и Redis (кэш).
Согласно официальной документации, для улучшения производительности PostgreSQL рекомендуют установить
(vm.overcommit_memory = 2) . В то же время, в официальной документации к Redis настоятельно рекомендуют установить
(vm.overcommit_memory = 1)
Вопросы :
1 . Какой режим "vm.overcommit_memory" всё таки целесообразно установить для связки PostgreSQL + Redis, работающих на одной машине ?
2 . В случае с PostgreSQL рекомендация
(vm.overcommit_memory = 2 = не использовать оверкоммит) связана с тем, что лучше пусть "сломается" дочерний процесс (из-за отказа ОС выделить запрошенный объём памяти), чем дать управление OOM-киллеру, который с большой вероятностью может убить мастер-процесс. Но с чем связана рекомендация
(vm.overcommit_memory = 1) для Redis ? Почему не 2 - понятно (все создаваемые процессы Redis являются значимыми и ни один из этих процессов не должен "падать"). Но почему именно 1, а не 0 (эвристика) ?
3 . Где фиксировать опцию
(vm.overcommit_memory = ...) ?
В "
/etc/sysctl.conf " (по умолчанию опция отсутствует) или в "
/proc/sys/vm/overcommit_memory " (по умолчанию
0 ) ?
4 . Какое значение "vm.swappiness" целесообразно задать для сабжевой связки при условии, что памяти немного (своп = объёму памяти) ? По умолчанию "/proc/sys/vm/overcommit_memory" = 60. В документации пишут:
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/ The default value on a Linux system is 60. A higher value causes the MMU (memory management unit) to utilize more swap space than RAM, whereas a lower value preserves more data/code in memory.
A smaller value is a good bet to improve performance in PostgreSQL Стоит ли уменьшать менее 60% ? Очевидно, что 0-20% ставить нельзя. Тогда сколько ? Оставить 60% или поставить 40% ?
Не приведёт ли ли к падениям Redis ?
Официальная документация :
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/ Tune Linux Kernel Parameters For PostgreSQL Optimization .
A value of 2 for vm.overcommit_memory yields better performance for PostgreSQL . This value maximizes RAM utilization by the server process without any significant risk of getting killed by the OOM killer process. An application will be able to overcommit, but only within the overcommit ratio, thus reducing the risk of having OOM killer kill the process. Hence a value to 2 gives better performance than the default 0 value. However, reliability can be improved by ensuring that memory beyond an allowable range is not overcommitted. It avoids the risk of the process being killed by OOM-killer.
https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT On Linux 2.6 and later, it is possible to modify the kernel's behavior so that it will not “overcommit” memory. Although this setting will not prevent the OOM killer from being invoked altogether, it will lower the chances significantly and will therefore lead to more robust system behavior. This is done by selecting strict overcommit mode via sysctl:
sysctl -w vm.overcommit_memory=2
or placing an equivalent entry in
/etc/sysctl.conf . You might also wish to modify the related setting vm.overcommit_ratio.
https://redis.io/topics/admin Redis Administration
Make sure to set the Linux kernel
overcommit memory setting to 1 . Add vm.overcommit_memory = 1 to /etc/sysctl.conf and then reboot or run the command sysctl vm.overcommit_memory=1 for this to take effect immediately.
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting The Linux kernel supports the following overcommit handling modes :
0 = Heuristic overcommit handling. Obvious overcommits ofaddress space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.
1 = Always overcommit. Appropriate for some scientific applications. Classic example is code using sparse arrays and just relying on the virtual memory consisting almost entirely of zero pages.
2 = Don't overcommit. The total address space commit for the system is not permitted to exceed swap + a configurable amount (default is 50%) of physical RAM. Depending on the amount you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate. Useful for applications that want to guarantee their memory allocations will be available in the future without having to initialize every page.
