У меня была проблема с процессом, порождающим очень много потоков из-за ошибки, поглощающим память, вызывающим интенсивную подкачку в разделе подкачки. Поэтому я отключил подкачку — что в любом случае рекомендуется в серверных кластерах — чтобы позволить глючной программе выйти из строя раньше. К моему удивлению, это вообще не улучшило ситуацию! Аналогично, установка vm.swappinessна 0 не помогла. iotopпоказала интенсивнуючтениес диска (почти не пишется).
Я подозреваю, что ядро Linux все еще меняет кодовые страницы в памяти и перечитывает перезаписанные кодовые страницы с диска, когда они нужны. Когда оперативной памяти очень мало, это происходит очень часто, вызывая пробуксовку, из-за чего компьютер почти не реагирует.
Как можно предотвратить эту неудачную и потенциально опасную ситуацию? Я пробовал отключать swap, cgroups для памяти и ограничений CPU для этого процесса и ulimit для макс. 30 процессов. Ничто даже не улучшило ситуацию. (Ну, это не совсем так: ограничение RAM, которое оставляло сотни МБ постоянно неиспользованными, помогло.)
В частности: можно ли запретить перестановку сегментов кода в памяти и позволить процессу, запрашивающему ОЗУ, просто получить NULL для своего следующего malloc?
решение1
Как насчет настройки учета перерасхода памяти и установки его на опцию 2 (не перерасходовать) вместо опции по умолчанию 0 (эвристический перерасход)? В описании этого говорится
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.
Приведенный выше фрагмент взят издокументация ядра
Политику можно задать с помощью vm.overcommitнастройки.