Как бороться с утечкой памяти из-под вилки в Linux?
Я знаю, что вилочную бомбу можно предотвратить, ограничив число процессов одного пользователя, и утечка памяти не замерзнет, моя ОС для Linux имеет OOM killer. Но как насчет бомбы с утечкой памяти?
#include <vector>
#include <unistd.h>
#include <ctime>
#include <cstdlib>
using namespace std;
int main() {
srand(time(NULL));
vector<int> vec;
do {
try {
for (int i=0; i<10000000; i++)
vec.push_back(rand());
} catch (bad_alloc e) {
}
fork();
} while (1);
return 0;
}
Мой Linux завис после того, как попробовал этот код. Могу ли я в любом случае предотвратить его замерзание?
Код протестирован на Archlinux, Linux 4.0.5
скомпилируйте код, используя эту команду:g++ -o test test.cpp
Дополнительная информация: поскольку код может поглотить всю мою память, просто разветвившись несколько раз, он не похож на обычную вилочную бомбу, и ограничение числа процессов бесполезно. Кроме того, fork() часто выполняется (при нехватке памяти), поэтому OOM-killer намного медленнее, чем вилки. В результате я должен использовать Alt-SysRq-REI, чтобы остановить эти процессы, но это не то, что я хочу.
Я впервые спрашиваю о SuperUser. Помоги мне, если мой вопрос неуместен. И спасибо за вашу помощь.
1 ответ
Это не должно быть бомба с утечкой памяти - даже, например, make -j
(или со слишком высоким j
фактор) при умеренном размере кода или любом процессе, порождающем кучу потомков (меньше, чем разумный предел для активного пользователя), каждый из которых жует объем памяти, значительный сам по себе, но слишком маленький, чтобы быть целью убийцы ООМ (или предлагать значительное облегчение, когда он прибит убийцей ООМ) может иметь аналогичный эффект.
Можно написать собственный скрипт / инструмент мониторинга (который будет выполняться пользователем root с высоким приоритетом), который мог бы отслеживать такие шаблоны порождения процесса и, при необходимости, уничтожать их с помощью pgid или userid (то есть одновременно, а не по одному, как OOM убийца) прежде чем они станут роковыми для системы. Будет работать по разумным ставкам нереста / истощения ресурсов, но я не уверен, если это возможно, для любых ставок.