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

[netch80]

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

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

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

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

Comments

[netch80.livejournal.com]

Вообще-то про память я имел в виду немного другое - не само поведение процесса под такой фигнёй, а как делать, чтобы не доводить до этой ситуации, потому что зловред оказался самовоспроизводящимся именно в случае тяжёлой фигни, когда и так всем хреново. Если дойдут руки (этот продукт "в загоне", по крайней мере временно), то надо будет делать какую-то умную систему типа "мы принимаем для себя только несколько последних событий о себе же, остальные пристреливаем", но это всё равно может вылиться в достаточно длительный колбасит (-ит потому что заразный, заражает соседей в пределах кластера, спасает только разрыв связей и очистка после разрыва - очень дорогой путь).

Создание аварийного выхода в случае недостатка памяти, конечно, метод полезный, но в данном случае ещё и непонятно, как его вообще тут применять.