вести с грабельных полей,

[netch80]

Период смешных ошибок с неожиданными последствиями.

Не моя: в pidfile пишется просто число - PID, ничем не терминируется, файл предварительно (или после) не зачищается. Работало под pid=12347, запущен новый с pid=3642, в pidfile оказалось 36427.

Моя: в кластере живут данные, реплицирующиеся между нодами, но функция вычистки устаревших данных не доработана. Запускается узел, пытается одновременно добавить новую запись истории о своём запуске и синхронизироваться с остальными, умирает под тяжестью данных и приложений (не хватает виртуальной памяти), но остальные, кто ещё жив, запомнили этот запуск. Запускается заново, ещё добавляет, снова умирает... Когда нашли и идентифицировали проблему, уже вычитка базы с другого узла оказывалась слишком тяжёлой и рвала синхронизацию в кластере. Пришлось полностью погасить сервис динамических данных, чтобы остановить размножение мусора.

Пока не знаю, какие выводы тут делать.

Comments

[dadv.livejournal.com]

Лимиты при сведении задачи из kernel land в user land. Чтобы в момент X ядро не давало по голове процесса OOM-killer'ом, а просто возвращало ошибку в ответ на запрос памяти. А приложение уже научить тому, чтобы делало себе лимит памяти и аккуратно свертывалось.

[netch80.livejournal.com]

Ты тоже уже всё забыл. А ведь обсуждали и при тебе:

http://groups.google.com/group/fido7.ru.unix.prog/browse_thread/thread/551b8b584a43ea6c/d2032971ec69a1e8

Проблема в том, что "сделать себе лимит памяти" требует специального ядерного механизма, которого не дают.

[dadv.livejournal.com]

Весь тред перечитывать некогда, перечитал первую страницу. Нужно различать две принципиально разные ситуации: OS не даёт программисту метода писать приложение так, что оно может узнать, что память кончилась и корректно завершиться/отреагировать без запроса дополнительной памяти к тому, что у него уже есть; либо OS даёт подобный метод. Если в OS не даёт методов (например, лимиты в Linux не работают?), то эта OS плохая, негодная для твоей задачи и её надо либо чинить (патчить), либо менять. Если даёт методы, надо ими активно пользоваться.

На фре есть RLIMIT_VMEM (vmemoryuse): /* virtual process size (inclusive of mmap) */, оно же RLIMIT_AS (это же имя упоминалось в контексте линукса в обсуждении в ru.unix.prog).

[netch80.livejournal.com]

> Весь тред перечитывать некогда, перечитал первую страницу.

Видимо, плохо прочитал. Потому что суть как раз проигнорировал.

> Если в OS не даёт методов (например, лимиты в Linux не работают?)

При чём тут вообще лимиты в нынешнем виде? Они срабатывают только при их переполнении, и уже в том месте, где попросили ресурс. А если этот запрос неявный (например, copy-on-write страницы), то и сообщить о проблеме невозможно. Надо делать так, чтобы она опознавалась заранее. А теперь покажи, как мне подсчитать лёгким образом (без залазания в /proc/$pid/), какой текущий объём VM процесса и сколько осталось до исчерпания лимита?

> Если даёт методы, надо ими активно пользоваться.

Если бы она давала методы - всё было бы хорошо. Но она ни хрена не даёт.

> На фре есть RLIMIT_VMEM

Ровно настолько же бесполезная хня.

[dadv.livejournal.com]

copy-on-write будет в память, которая предварительно аллоцирована же. Вот на это аллоцирование лимиты и действуют.

> как мне подсчитать лёгким образом (без залазания в /proc/$pid/), какой текущий объём VM процесса и сколько осталось до исчерпания лимита

Не знаю, но это не критично - когда лимит исчерпается, тебе система об этом скажет и ты просто откатишь транзакцию, используя резервную память.

[netch80.livejournal.com]

> copy-on-write будет в память, которая предварительно аллоцирована же. Вот на это аллоцирование лимиты и действуют.

Это лимиты 1 (прописью: одного) процесса. Уже лимиты группы процессов, а тем более фактический лимит всей системы, не может заранее ограничить расширение по copy-on-write.

> Не знаю, но это не критично - когда лимит исчерпается, тебе система об этом скажет и ты просто откатишь транзакцию, используя резервную память.

Отлично! Покажи мне, где этот механизм работает уже сейчас.

[dadv.livejournal.com]

> Уже лимиты группы процессов,

Зачем?

> а тем более фактический лимит всей системы, не может заранее ограничить расширение по copy-on-write.

Зачем системе иметь какой-то лимит? Своп же можно наращивать динамически, а в перспективе и RAM.

[dadv.livejournal.com]

>> Не знаю, но это не критично - когда лимит исчерпается, тебе система об этом скажет и ты просто откатишь транзакцию, используя резервную память.
> Отлично! Покажи мне, где этот механизм работает уже сейчас.

Все методы выделения (виртуальной) памяти предусматривают отказ и возврат ошибки, я не понимаю проблемы.