Загадочная загадка - практически все пользовательские процессы получают SIGTERM в произвольный промежуток времени
SbOy 23 июля, 2011 - 23:16
Сабж. Уже не знаю куда копать. Произвольный промежуток времени - это примерно 4 дня. Всё бы ничего, но вместе со всеми убивается sshd, жуткая пакасть. В логах обычно выглядит это так:
/var/log/syslog:Jul 23 22:43:05 localhost sshd[2304]: Received signal 15; terminating.
Апач вылетает приблизительно так же
[Sat Jul 23 20:24:14 2011] [notice] caught SIGTERM, shutting down
Если оставить висеть залогиненую консоль, можно спокойно рестартануть сервисы и всё будет в порядке до следующего раза.
Интересно, что например mysql - не завершается и работает всё время нормально.
Куда тут можно копать? Идеально бы найти процесс, который всё это делает.
»
- Для комментирования войдите или зарегистрируйтесь
OOM_Killer?
OOM_Killer?
OOM_KILLER по идее должен
OOM_KILLER по идее должен писать лог в dmesg?
С Уважением, Sb0y.
Нашёл
Нашёл статью
http://www.stevekamerman.com/2011/01/keep-oom_killer-from-killing-your-server/
у человека почти такая же проблема как и у меня.
Осталось только понять куда уходит память в такие моменты. Вроде 4 гига стоит, раньше и то меньше было. Может память битая?
С Уважением, Sb0y.
Если удастся определить что
Если удастся определить что это именно oom_killer, какой именно процесс "протек" или есть на него соответствующее подозрение:
#!/bin/bash
for pid in $(pidof sshd) ; do
echo "disabling oom on pid $pid"
echo -17 | sudo tee /proc/$pid/oom_adj > /dev/null
done
показано для sshd, ибо с подобными проблемами сталкивался неоднократно на VPS (по известному всем закону эти проблемы возникают в вечер пятницы-субботу).
по крайней мере самое важное для диагностики "лежащего" серва этим можно сохранить.
Удачи.
PS Более полно тут - http://best.of.by/forum/viewtopic.php?t=385 (гостевой доступ byfly, Беларусь)
Да пребудет с тобой великий Linux.
Ой, как же прав winterheart
Ой, как же прав winterheart про блоги, бложики и прочие днявки и малявки
2 вопроса:
1)
МужикиЛинус в курсе, что омм киллер убрали2) А пруф с lkml мона ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Ребята, это п*здец. Это
Ребята, это п*здец. Это действительно OOM_KILLER и он в этой ситуации прав как никто другой. Я запустил memtest86 на серваке и он нашёл туеву хучу плохих адресов.
Оперативка еле живая, сервер жил на свопе, всё это время. Не покупайте серверы HP, ребята :(
С Уважением, Sb0y.
Не надо валить на НР или
Не надо валить на НР или кого-то еще, если головы нет!
Просто при покупке проверяйте конфигурацию на совместимость (например, мощность БП должна держать пиковую нагрузку системы, чего реально почти никто НЕ делает, etc). Не ставьте левые (без сертификации изготовителя сервера) комплектующие и т.д. - иначе ССЗБ!
Зачастую пытаются везде с'экономить, а потом кричат ХХ - плохой!
Есть у всех у них свои грешки, но не до такой степени!
Кроме того, on-site acceptance test и мониторинг (под)систем никто не отменял... ;)
А если админ не замечал, что "...сервер жил на свопе всё это время..." и "это время" более нескольких часов, то, как говорится "no comments!"...
Мсье классически считает, что
Мсье классически считает, что он умнее других? Серверу недели нет, никто туда ничего не ставил.
>Зачастую пытаются везде с'экономить, а потом кричат ХХ - плохой!
Сэкономила в данном случае HP, поставив сервер с гнилой оперативкой.
>Просто при покупке проверяйте конфигурацию на совместимость (например, мощность БП должна держать пиковую нагрузку системы, чего реально почти никто НЕ делает, etc). Не ставьте левые (без сертификации изготовителя сервера) комплектующие и т.д. - иначе ССЗБ!
А это вообще к чему сказано? На сервере пломбы от HP.
>Кроме того, on-site acceptance test и мониторинг (под)систем никто не отменял... ;)
Такие тесты не выявляют эту проблему. Когда начинается этот глюк, всё происходит за считанные минуты и OOM_KILLER вышибает все ваши хвалёные системы мониторинга, ибо система под нагрузкой. До этого момента, система не свопает практически вообще. Ещё раз говорю, в биусе всё в полном порядке. Только при хардкорном тестировании оперетивной памяти и то не сразу, в memtest86 выявилась ошибка. Если смотреть munin график оперативной в какой-то момент, резко падает до критических отметок. В htop тоже скачет от 200 мегабайт до 4000. А иногда вообще проходит гладко. У вас видимо нет опыта борьбы с битым железом и кажется, что море по колено.
>А если админ не замечал, что "...сервер жил на свопе всё это время..." и "это время" более нескольких часов, то, как говорится "no comments!"...
Да вообще-то как только так сразу, вы так говорите, как будто сидели рядом с этим админом.
С Уважением, Sb0y.
SbOy написал(а): ... >Кроме
FYI: В "site acceptance test" (в вольном переводе: "приемка оборудования на месте у заказчика") одним из этапов входит тестирование всего железа и НР даже диагностический диск дает в комплекте с сервером... ;)
Не показатель. вот если бы из
Не показатель. вот если бы из 10 сервером HP у 5 такая проблема была -тогда да. А так, брак и прочая муть бывает весде.
Я думаю что конкретно этот
Я думаю, что конкретно этот сервер поставляется с такой оперативкой. Вид у неё больно похож на китайский NoName.
С Уважением, Sb0y.
А ещё, у HP взависимости от
А ещё, у HP взависимости от региона куда поставка может быть весьма разная сборка, даже железки сильно разные...
Такие вещи должен отлавливать
Такие вещи должен отлавливать ОТК. И если он у них вообще есть, не понятно как можно было такое провафлить.
С Уважением, Sb0y.
Хапэшный snmp agent (и их
Хапэшный snmp agent (и их какая-то там мониторилка железа в веб мордой) может показать некий весовой коэффициент, который может сказать о состоянии памяти. К нему есть доступ? Интересно, какое у него значение.
Похоже у меня в генте такой
Похоже у меня в генте такой софтины нет (emerge -s не находит). Поделитесь портом? Или может я ищу не правильно - "snmp-agent" ?
С Уважением, Sb0y.
Это набор софта он самого HP,
Это набор софта он самого HP, репо тут http://downloads.linux.hp.com/SDR/psp/ . Я его ставил на ось, которая сапортится самим HP, поэтому установкой на Gentoo помочь пока нечем. Но судя по поиску, что -то из списка ниже в оверлеях попадается.
Из того, что ставил это
Статус режима отслеживания ошибок в памяти OID 1.3.6.1.4.1.232.6.2.3.1 2 – not supported 3 – disabled 4 – enabledВ MIB утверждается, что если текущее значение больше или равно 2147483647, необходимо заменить модуль памяти.