Узнать киллера (:))

[sergius]

У меня на одной тачке постоянно кто-то (другой процесс) убивает мой процесс.
Можно ли каким-нить образом выявить этого гада?

ЗЫ Мой процесс пожирает все ресурсы компа, примерно, на 5-10 минут (обходит директории, парсит логи и т.п.).

[Angel_13th]

Снорт какой нить.

[flook]

Может oom в дяре сработал

[t.t]

Ещё такое бывает когда своп кончается.

[Jan2ary]

А еще есть такая опция в ядре, которая позволяет ядру снимать процессы, которые систему сильно грузят. Как называется не помню. Может в логах что есть....

[sergius]

Ещё такое бывает когда своп кончается.

<_< А это вполне возможно.

Всем спасибо. Буду смотреть.

[madskull]

Подозреваю, что надо [пере]смотреть саму программу, ее алгоритм.

[sergius]

Подозреваю, что надо [пере]смотреть саму программу, ее алгоритм.

Этим сейчас и занимаюсь

ЗЫ Проблема в том, что этот скрипт так и должен грузить тачку.

[flook]

Ещё такое бывает когда своп кончается.

Это и есть oom Out of memory killer. А цепочка приводящая от свопа к oom выглядит так:
1. Процесс позвал (например) mmap
2. Ядро позвало get_free_page (buddy page allocator если кто слышал)
3. Этот buddy сказал try_to_free_pages, когда увидел, что у него страницы кончились
4. try_to_free_pages пошел освобождать страницы из (в частности) page cache
5. Не смог => полез к свопу
6. Своп решил, что у него тоже с местом туго
7. try_to_free_pages решил, что что-то неладно и на всякий случай позвал oom...
8. oom пошарился по списку процессов и пристрелил самого толстого
вот так вот сложно. Причем от момента конца памяти до момента вызова oom может пройти много времени, т.к. механизм освобожения страниц из page cache и/или сброса их в своп - это довольно муторная, нелинейная и полуэвристическая процедура...

Отсюда вывод - можно наплодить много процессов, каждый из которых съест чуть чуть, а в результате может сдохнуить Xы или Apache...

[t.t]

Это и есть oom Out of memory killer. А цепочка приводящая от свопа к oom выглядит так:
1. Процесс позвал (например) mmap
2. Ядро позвало get_free_page (buddy page allocator если кто слышал)
3. Этот buddy сказал try_to_free_pages, когда увидел, что у него страницы кончились
4. try_to_free_pages пошел освобождать страницы из (в частности) page cache
5. Не смог => полез к свопу
6. Своп решил, что у него тоже с местом туго
7. try_to_free_pages решил, что что-то неладно и на всякий случай позвал oom...
8. oom пошарился по списку процессов и пристрелил самого толстого

Так художественно рассказываешь -- класс