Я бы сказал, что лучший способ предотвратить зависание OOM - не исчерпать виртуальную память. Если вы регулярно исчерпываете виртуальную память или приближаетесь, то у вас большие проблемы.
Большинство задач не очень хорошо справляются с ошибочными распределениями памяти, поэтому имеют тенденцию к краху или потере данных. Исчерпание виртуальной памяти (с перегрузкой или без нее) приведет к сбою некоторых выделений. Обычно это плохо.
Кроме того, до того, как в вашей операционной системе закончится виртуальная память, она начнет делать плохие вещи, такие как удаление страниц из часто используемых общих библиотек, что может привести к снижению производительности, так как их приходится часто возвращать назад, что очень плохо для пропускной способности.
Мои предложения:
И, возможно, также
Если это полезно в вашем случае использования.
Большинство многопроцессорных серверов работают с настраиваемым (максимальным) числом процессов, поэтому обычно его можно уменьшить. Многопоточные серверы обычно позволяют вам сконфигурировать, сколько памяти использовать для своих буферов и т.д. внутри.
Нет и нет.
Вам просто нужно быть осторожным и установить close-on-exec для всех файловых дескрипторов, которые вам нужны.
Настройка это просто:
#include <fcntl.h>
fcntl(fd, F_SETFD, fcntl(fd, F_GETFD) | FD_CLOEXEC);
#include <unistd.h>
/* please don't do this */
for (i = getdtablesize(); i --> 3;) {
if ((flags = fcntl(i, F_GETFD)) != -1)
fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
}
Если вы используете ядро Linux ≥2.6.23 и glibc ≥2.7, open
(вместе с другими аналогичными системными вызовами) принимает новый флаг O_CLOEXEC
:
#include <unistd.h>
fd = open("...", ... | O_CLOEXEC);
Если вы используете ядро Linux ≥2.6.24 и glibc ≥2.7, fcntl
принимает новый аргумент F_DUPFD_CLOEXEC
:
#include <fcntl.h>
newfd = fcntl(oldfd, F_DUPFD_CLOEXEC);
Если вы используете ядро Linux ≥2.6.27 и glibc ≥2.9, появились новые системные вызовы pipe2
, dup3
и т. д.,