Эти ваши системы управления процессами...

0

1

На сервере сейчас 2481 defunct процесс:

balancer 28319  0.0  0.0      0     0 pts/20   Z+   18:46   0:00 [php] <defunct>
balancer 28474  0.1  0.0      0     0 pts/20   Z+   18:47   0:00 [php] <defunct>
balancer 28481  0.0  0.0      0     0 pts/20   Z+   18:47   0:00 [php] <defunct>
balancer 28638  0.0  0.0      0     0 pts/20   Z+   17:34   0:00 [php] <defunct>
balancer 28956  0.0  0.0      0     0 pts/20   Z+   18:46   0:00 [php] <defunct>
...

Всё бы было б ичего, но они учитываются в ресурсах. И ресурсов у пользователя уже не хватает для нормального запуска процессов.

Что делать? Растарт - крайняя мера.

// кросспостинг

Ссылка

←	[iptables] Тонкости реализации NAT

Чем деплоить проект с github?

→

>2481 defunct процесс

Уже 2659. Количество непрерывно возрастает...

~~KRoN73~~ ★★★★★
(10.02.11 18:52:18 MSK) автор топика

Ссылка

Они в потомках у какого процесса?

Deleted
(10.02.11 18:59:07 MSK)

Ссылка

http://www.linuxquestions.org/questions/linux-software-2/how-to-remove-defunc...

isden ★★★★★
(10.02.11 19:01:23 MSK)

Ответ на: комментарий от isden 10.02.11 19:01:23 MSK

в 2-х словах - ребут или убиение предка этих процессов.

isden ★★★★★
(10.02.11 19:02:24 MSK)

Ответ на: комментарий от isden 10.02.11 19:02:24 MSK

> убиение предка этих процессов

что впрочем помогает не всегда.

isden ★★★★★
(10.02.11 19:03:09 MSK)

Ссылка

Всё, разобрался. PHP+Gearman-клиент дурит, походу. Если работать с таймаутом, то таймаут ставится ровно в одну секунду независимо от выставленного значения и каждую секунду рождается новый PHP-зомби.

Тупо сделал выход из скрипта через 100 циклов (aka 100 секунд) и поставил его в bash-loop :)

Странно, за полтора суток работы оно должно было породить 130 тыс. зомби. А породило только ~2700. Значит, проблемы где-то меньше часа назад начались? Ну, х.з...

~~KRoN73~~ ★★★★★
(10.02.11 19:19:14 MSK) автор топика

Ссылка

Гы. Отловил. Упасть и не встать :D В общем, на одном из контактов, которому пошло сообщение о нотификации, стоял автоответчик, походу :) И мой бот затеял с ним высокоскоростную беседу :D И, таки да, это были чистые PHP-форки, почему-то не закрывающиеся, хотя честный exit()...

~~KRoN73~~ ★★★★★
(10.02.11 23:00:56 MSK) автор топика

Ответ на: комментарий от KRoN73 10.02.11 23:00:56 MSK

И мой бот затеял с ним высокоскоростную беседу :D

Задротские у вас боты. Чёткие боты девушек клеят :)

Xenesz ★★★★
(11.02.11 07:25:35 MSK)

Ссылка

>Эти ваши системы управления процессами...

Эта ваша гента...

Led ★★★☆☆
(11.02.11 08:32:11 MSK)

Ссылка

>Эти ваши системы управления процессами...

Эти ваши PHP'ы...

Led ★★★☆☆
(11.02.11 08:33:02 MSK)

Ссылка

Может, обновить пыхпых и ядро? Такие зомби иногда и по kill -9 не убиваются...

~~Eddy_Em~~ ☆☆☆☆☆
(11.02.11 08:45:14 MSK)

Ответ на: комментарий от Eddy_Em 11.02.11 08:45:14 MSK

>Может, обновить пыхпых и ядро?

Gentoo же :)

Такие зомби иногда и по kill -9 не убиваются...

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

~~KRoN73~~ ★★★★★
(11.02.11 09:39:52 MSK) автор топика

Ответ на: комментарий от KRoN73 11.02.11 09:39:52 MSK

Ядро дырявое?

~~Eddy_Em~~ ☆☆☆☆☆
(11.02.11 09:47:29 MSK)

Ответ на: комментарий от Eddy_Em 11.02.11 09:47:29 MSK

>Ядро дырявое?

Ага. Лет 10, как минимум :D По крайней мере тогда я впервые с этой проблемой столкнулся...

И, вообще, не делайте вид, что впервые слышите :D

http://www.google.ru/#sclient=psy&hl=ru&newwindow=1&q=%D0%B7%D0%BE%D0%BC%D0%B...

~~KRoN73~~ ★★★★★
(11.02.11 10:07:07 MSK) автор топика

Ответ на: комментарий от KRoN73 11.02.11 10:07:07 MSK

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

~~Eddy_Em~~ ☆☆☆☆☆
(11.02.11 10:42:17 MSK)

Мда ... прелести PHP ... в полный рост ... отсутствие нормального управления памятью пока не дает о себе знать ? Ну, да все еще впереди :-)

ef37 ★★
(11.02.11 10:48:38 MSK)

Ответ на: комментарий от Eddy_Em 11.02.11 10:42:17 MSK

>почему-то эту дыру никак не заткнут

А откуда тогда предок будет брать информацию о состоянии потомка? Скажем, проснулся первый через недельку, и говорит «А как там^Uwait(дитё);». К этому времени PID==дитё уже у другого процесса. И как ОС догадается, о ком отвечать?

DonkeyHot ★★★★★
(11.02.11 11:19:44 MSK)

Ответ на: комментарий от DonkeyHot 11.02.11 11:19:44 MSK

А что мешает ядру отправлять какой-нибудь SIGCHLD предку? А если через n-е время предок не среагирует, бросать ему SIGTERM, а если и на него не среагирует - то SIGKILL? Ну и кроме того, не должно быть такого, чтобы рут не мог убить какой-либо процесс по SIGKILL.

~~Eddy_Em~~ ☆☆☆☆☆
(11.02.11 11:27:55 MSK)

Ответ на: комментарий от ef37 11.02.11 10:48:38 MSK

>Мда ... прелести PHP ... в полный рост ...

То есть зомби в ядре - это работа PHP? :)

отсутствие нормального управления памятью пока не дает о себе знать ?

Так форки же. За полтора суток непрерывной работы (до сабжа) потребление памяти скриптом ни на процент не выросло :)

~~KRoN73~~ ★★★★★
(11.02.11 11:30:47 MSK) автор топика

Ссылка

Ответ на: комментарий от DonkeyHot 11.02.11 11:19:44 MSK

>К этому времени PID==дитё уже у другого процесса. И как ОС догадается, о ком отвечать?

Ну, например, ОС могла бы тогда такие «висячие PID'ы» за процессы не считать при учёте лимитов :)

~~KRoN73~~ ★★★★★
(11.02.11 11:31:31 MSK) автор топика

Ответ на: комментарий от KRoN73 11.02.11 11:31:31 MSK

Лучше, ИМХО, не раздумывая убивать предка таких мертвых процессов, чтобы разработчики лучше заботились о своем коде.

~~Eddy_Em~~ ☆☆☆☆☆
(11.02.11 11:35:12 MSK)

Ссылка

Ответ на: комментарий от Eddy_Em 11.02.11 11:27:55 MSK

>если через n-е время предок не среагирует, бросать ему SIGTERM, а если и на него не среагирует - то SIGKILL

А может предок вовсе не забыл о потомке, а делом занят? Ты знаешь абсолютное время, дольше которого заниматься делом никто никогда не должен?

DonkeyHot ★★★★★
(11.02.11 16:30:20 MSK)

Ответ на: комментарий от KRoN73 11.02.11 11:31:31 MSK

>ОС могла бы тогда такие «висячие PID'ы» за процессы не считать при учёте лимитов

Тогда мы бы имели новый тип DOS-а - исчерпание PID-ов, которые лимитами не ограничиваются:)

DonkeyHot ★★★★★
(11.02.11 16:32:04 MSK)

Ответ на: комментарий от DonkeyHot 11.02.11 16:30:20 MSK

Если предок не реагирует на SIGCHLD, можно через, скажем, минуту, послать предку еще раз SIGCHLD. Если опять реакции нет - предка можно убивать, т.к. он гарантированно висит.

~~Eddy_Em~~ ☆☆☆☆☆
(11.02.11 16:48:13 MSK)