LINUX.ORG.RU
решено ФорумAdmin

Хрень какая-то с сервером.

 , ,


1

3

Есть хост с обычной серверной Ubuntu 14.04 LTS без хитростей.

Есть в ней уйма Docker и LXC-контейнеров.

Сервер без нареканий пахал 3.5 года.

Недавно (две недели назад) начались проблемы. Симптомы:

— В LXC-контейнерах (сразу всех) виснет php5-fpm. Виснет так, что ни перезапустить, ни даже убить. Процессы даже в зомби не превращаются. Просто попытки их убивать ни к чему не приводят. Попытка перезапустить сервис приводит к завису процесса перезапуска. Попытка остановить или убить LXC-контейнер приводит к завису lxc-stop/lxc-kill.

— Всё остальное работает нормально: — И nginx внутри LXC отдаёт данные корректно (кроме того, что обращение php выдаёт 502-ю ошибку). — И Docker-контейнеры работают (в т.ч. с PHP) и перезапускаются штатно. — И хост весь рабочий. — Диски в отличном состоянии, в dmesg пусто. — Загрузка системы после зависа нагруженных тяжёлых LXC-контейнеров падает практически до нуля. CPU — почти 100% idle, дисковая активность — тоже.

Поскольку никакие средства lxc не оживляют, сервер приходится перезапускать. Перезапуск проходит штатно, после перезапуска всё работает.

Ещё два замечания:

У меня висят cron-процессы с традицонной много-много лет назад добавленной защитой от повторного запуска, если старый не отработал до конца. Это ещё в нулевых, когда cron-скрипты минутные за минуту иногда не успевали отработать. Код проверки такой:

if [ ! -z "`ps -C \`basename $0\` --no-headers -o "pid,ppid,sid,comm"|grep -v "$$ "|grep -v "<defunct>"`" ]; then
   echo script is already running . abort
   exit 0
fi

Так вот, где-то с месяц назад (точно не помню) cron-скрипыт иногда стали «зависать». Скрипт всё сделал, но процесс висит (кажется, уже не помню точные симптомы). Новый скрипт поэтому не запускается. Я пожал плечами и убрал эту проверку. Всё стало работать нормально. Машина к тому времени была 160 дней без рестарта, подумал, мало ли какие-то проблемы стали в ядре накапливаться и забил. Теперь думаю, не связано ли оно как-то вместе...

После этих зависов и рестартов трижды были проблемы madm-raid. Первый раз я в попытках понять, почему висят php-процессы в контейнере доигрался до того, что сервер не перезапускался. Пришлось его удалённо ресетить. Через какое-то время после перезапуска (специально не контролировал) обнаружил, что вся активность идёт на одном из hdd, второй — стоит. Беглый просмотр показал, что зеркало развалилось и работает только один том. С какой точно формулировкой проблемы была не помню. Удалил отвалившийся том, добавил снова — всё завелось штатно и без проблем. Конечно, тщательно изучил smartctl и т.п. — всё было ок. Т.е., скорее всего, проблема была где-то в жёстком перезапуске.

Добавил мониторинг mdam в munin.

После второго рестарта, уже мягкого, всё было ок пару дней. Потом — munin выдал alert. Смотрю — зеркало развалилось. На этот раз без ошибок, просто hdd оказался исключённым o_O Включил в зеркало, сразу подхватился, засинхронизировался, всё стало ок.

После третьего рестарта, не сразу, а где-то через пол-дня, munin опять сигнализирует. На этот раз «жёлтеньким», типа, предупреждением. Смотрю — raid в процессе восстановления снова. Но на этот раз сам. Конечно, тренд позитивный, с полного развала к лёгкой починке и потом к самовосстановлению, но какого фига? Я бы понял, если бы проблема лезла сразу после рестарта. Но она не синхронна с зависами/перезапусками...

Сегодня был 4-й завис. Опять всё чисто, никаких проблем. Специально тщательно потыркал палочкой Docker-контейнеры, работают как часы. А вот в LXC — опять мёртвые php-fpm. И опять пришлось перезапускать...

Есть мысли, что это может быть? :) И как с этим бороться, кроме навешивания watchdog (благо, сервер рестартует нормально и хост остаётся работоспособен).

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)

Ответ на: комментарий от upcFrost

Ты не обновлялся и ничего точно не менял

Обновляю софт постоянно. Все штатные обновления Ubuntu. Так что, в общем-то, можно списать, например, на изменения в ядре какие-то. При чём они могли вылезти давно, сервер-то 160+ дней без рестарта был до момента, после которого начались проблемы.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

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

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

upcFrost ★★★★★
()

Может проблема с железом ? (метеринка, память, CPU) Есть возможность загрузить хотябы какойнибудь memtest и прогнать все ?

zaz ★★★★
()

Самое странное сдесь то что процессы не убиваются по kill -9, единственная известная для меня причина почему процесс не завершается по kill -9 это если данный процесс повис внутри какогото системного вызова (например вызвал «write/read» перешел в контекст ядра и там повис и не возвращается от туда). Такое бывает часто например при отваливании сетевого диска (когда любые операции с дисковые операции застряют надолго в ядре).

Есть смысл попытатся проверить где именно застряют зависшие процессы (например с помощью strace).

zaz ★★★★
()

Да и еще посмотрите в каком сотоянии находятся повисшие процессы, если они находятся в «D» (uninteraptable sleep) тогдя явно какието проблеммы IO ...

zaz ★★★★
()
Ответ на: комментарий от upcFrost

Ну, когда пакет так две-три версии попрыгает можно вообще чего угодно ждать.

Отчего? Это ж не винда :) Ядро обновляется отдельно. Демоны — отдельно. И они, как раз, перезапускаются. Более того, на хосте нет ничего сложного, всё сложное — в контейнерах.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от zaz

Может проблема с железом ?

Это, как раз, была первая мысль. Тем более, что я за последние ~30-50 машинолет полудюжину железок «пережил». Но, увы, не считая одновременного зависа php сразу во всех LXC-контейнерах (с сохранением работоспособости PHP в Docker-контейнерах), всё остальное работает как часы. На сбои железа не похоже никак :-/

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от svr4

Фпм после какого количество запросов перезапускает child?

В разных контейнерах от 500 до 10000. Но виснут все одинаково.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от zaz

Есть смысл попытатся проверить где именно застряют зависшие процессы (например с помощью strace).

Уже зависшие так не проверить, поймать завис сложно. Он может сегодня случиться, а может — через неделю.

kill по strace не посмотреть, поскольку он отрабатывает без зависов. Просто php-fpm не убивается.

service php5-fpm stop вешается. Но, по-моему, он там просто ждёт в цикле, пока его php исчезнут. Но попробую, по случаю, его по strace пощупать.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от zaz

Да и еще посмотрите в каком сотоянии находятся повисшие процессы, если они находятся в «D»

Сейчас уже не вспомню, но, по-моему, процессы были в нормальном состоянии.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

service php5-fpm stop мониторить смысла нету как мне кажится, нужно именно сами повисающие процессы (мне кажется у вас там может повиснуть любой - просто php наиболие активно работает, поэтому и вашается более часто).

Я бы всеже попробовал приатачить strace к повисшему процессу (strace -p <pid>) Если же strace не атачится (что также странно как и не рабочий kill -9) то можно написать скрипт который будет делать чтото вроде:

for pid in `pidof phpd`:
   strace -p $pid | gzip > /var/log/php-strace-${pid}-${today}.log.gz
end
И в кроне скажем раз в сутки (или чаще) детачить старые strace (killall -INT strace) и создовать новые

zaz ★★★★
()

оффтоп

Есть в ней уйма Docker и LXC-контейнеров.

Если не считать те проблемы о которых ты пишешь, то как тебе LXC контейнеры? От докера меня мутит и давно хочу попробовать LXC, но руки не доходят.

GoNaX ★★★
()
Ответ на: комментарий от KRoN73

Просто php-fpm не убивается.

Ты бы вывод «ps -Ao pid,tt,fname,stat,f,wchan» от своего неубиваемого php-fpm показал. А то из разряда сказок - kill -9 на него не действует. К mdadm ставить наблюдалку - сомнительно, он сам умеет почтой писать о проблемах. А вот к дискам smartd надо ставить.

LynxChaus
()
Ответ на: оффтоп от GoNaX

Дешевые виртуалки. Очень удобно, если не надо ограничивать диск/CPU/память.

Там две команды для старта.

lxc-create -n ubuntu1 -t ubuntu
lxc-start -n ubuntu1

Сразу попадаешь в консоль виртуалки. Нужны дополнительные терминалы — соединяешься по ssh, ubuntu/ubuntu.

anonymous
()
Ответ на: оффтоп от GoNaX

как тебе LXC контейнеры? От докера меня мутит и давно хочу попробовать LXC, но руки не доходят.

Они по концепции сильно разные.

Docker хорош для типовых и готовых задач в духе «развернуть очередную LEMP-связку» или «поднять Redmine, не заботясь о зависимостях и обновлениях».

LXC — это, по сути, отдельный виртуальный комп, только что работает с тем же ядром, что хост.

Области пересекаются, и Docker можно использовать в персистентном режиме, загрузив образ любимого дистрибутива и ковыряя его как захочется, и LXC можно использовать, клонируя типовые образы, но если тебе нужно иметь десятки типовых изолированных виртхостов или готовое решение без разбирательств, например, почему у тебя не работает кросскомпиляция под очередной микроконтроллер, то это задачи для Docker. Если тебе нужно заходить в контейнер по ssh и что-то там править ручками и ставить собственный софт, то это задача не для Docker, а для LXC.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от LynxChaus

Ты бы вывод «ps -Ao pid,tt,fname,stat,f,wchan» от своего неубиваемого php-fpm показал

Ок, если (не хочется, но вероятно) снова повиснет — посмотрю.

А то из разряда сказок - kill -9 на него не действует.

Тю. Знаешь, как часто я в своей практике встречаю процессы, который по kill -9 не убиваются? Да практически каждый машиногод. Это очень обыденное явление. Самое частое, как было выше сказано, когда затык где-то в ядерной части, в сетевых или дисковых операциях. Но в данном случае такого затыка нет, и дисковая система, и сеть пашут отлично. Что и странно. Если бы дисковая система вешалась, я бы ничуть не удивился, я такое много раз видел :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Спасибо за ликбез. Похоже мне всё это время был очень нужен LXC, а я всё ленился его поковырять.

А ресурсов LXC сильно много жрёт по сравнению с Docker?

GoNaX ★★★
()
Ответ на: комментарий от GoNaX

А как там с настройками сети? Можно ли например добавить контейнеру порт?

Там несколько типов подключения сети. В т.ч. и честные бриджи и, что я обычно использую, отдельные интерфейсы со своими IP. Порты, соответственно, вешаются работающими в контейнере приложениями, как им понадобится. LXC, в отличие от Docker, не берёт на себя вопросы роутинга. С точки зрения системы в контейнере, у неё есть свой сетевой интерфейс, с которым она делает то же, что делает система на реальном железе.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от GoNaX

Контейнер получает отдельный ip-шник, 10.0.3.* . Внутри этой виртуальной сети видно все, что хочешь. Внешний доступ делается стандартно, через проброс iptables.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 10.0.3.143:80
anonymous
()
Ответ на: комментарий от GoNaX

А ресурсов LXC сильно много жрёт по сравнению с Docker?

По CPU/памяти — оверхед одинаковый, околонулевой. По дисковым операциям LXC работает заметно шустрее, так как не использует aufs, а работает прямо с диском. Может как просто с подкаталогом на хосте (как эдакий продвинутый chroot), так и с отдельным томом в lvm или zfs. Docker на дисковых операциях иногда вдвое медленнее хоста, а у LXC — такая же скорость, как у хоста.

По процессам оверхед одинаковый. И там, и там у тебя работает собственная копия системы, со всеми своими демонами и т.п. Только по правилам хорошего тона Docker-контейнер вещь в себе, в которую ты не вмешиваешься, а в LXC можно снести всё, что не нужно. Хотя у меня, поскольку каждый LXC-контейнер — развитая система, там, наоборот, наставлено всего что только можно :D

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от smilessss

откати php5-fpm на пред версию

В Docker-контейнерах и на хосте та же версия работает без проблем.

в пакетах дело
очевидно же

Увы, не слишком очевидно :-/ И проверить сложно. Это же не Gentoo :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от smilessss

тут из зала подсказывают - дело в LXC :)

Ну, да, есть такое подозрение, раз овно из LXC-контейнера лезет :) Странно, что в том же Docker всё ок. Хоть он нынче и не поверх LXC работает, но всё те же cgroup в ядре...

Попробовать, что ли, (если снова зависнет) вынести работу с php из LXC-контейнера в отдельные Docker-контейнеры?

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Знаешь, как часто я в своей практике встречаю процессы, который по kill -9 не убиваются?

Не, не знаю. Но если часто - то сам должен мочь диагностировать проблему, а не писать в спортлото :)

Ты таки покажи вывод ps с хост-машины.

LynxChaus
()
Ответ на: комментарий от LynxChaus

сам должен мочь диагностировать проблему, а не писать в спортлото :)

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

Ты таки покажи вывод ps с хост-машины.

Когда будет (если будет) очередной завис. В том-то и проблема, что оно не воспроизводимо в любой момент.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от smilessss

К.О. подсказывает, что для легковесной контейнеризации.

KRoN73 ★★★★★
() автор топика

Сейчас заметил, что /sys/fs/cgroup занимает 100% из выделенных ему по дефолту 4кБ. Увеличил до 1М. Думаю теперь, не в этом ли дело?

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Увеличил до 1М. Думаю теперь, не в этом ли дело?

Зависов больше не было. Но! Сегодня ночью за 5 часов /sys/fs/cgroup стремительно вырос от почти нуля до 100% (упомянутый выше 1Мб). Увеличил до 10Мб, посмотрю, как будет развиваться ситуация дальше :)

KRoN73 ★★★★★
() автор топика

У меня как-то совсем недавно контейнеры совсем не стартовали, починилось со следующим обновлением. (такое было первый раз, за все время)
Я ppa:ubuntu-lxc/lxd-git-master использую. В целом можешь попробовать lxc оттуда, или использовать постоянно и обновлять оттуда. В любом случае если что откатить на версию из дистрибутива проблем для тебя не должно составить.

anonymous_sama ★★★★★
()

Сквозная целостность необходима.

ZFS бы сразу указала, на каком участке проблема.

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Увеличил до 10Мб, посмотрю, как будет развиваться ситуация дальше :)

Уже занято 2/3 раздела. Что за хрень и как с ней бороться, блин? Ну, поставлю я 100Мб под cgroup — но, ведь, ненормально такое поведение :-/

KRoN73 ★★★★★
() автор топика

Теперь, хоть мёртвого зависа и нет, лезет такое:

https://twitter.com/AirbaseRu/status/707853597652996096

top забит в основном процессом ядра migration и всё стоит колом. Даже после опускания высоко нагруженных контейнеров :-/

KRoN73 ★★★★★
() автор топика
15 апреля 2016 г.

Если кому-то интересно, проблема прошла после отказа от использования высоконагруженного loop-образа с reiserfs поверх ext4.

В общем, что-то в reisrefs доломали... Печально. Конец эпохи и альтернативы на работе с мелочью нет, приходится с тормозами ext4 мириться и обходиться inotify-костылями для избегания сканирования каталогов.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от King_Carlo

звучит страшно...

Угу. Но на что только не пойдёшь, воюя с тормозами ext4 на удалённой системе, где нет возможности переразбить диск :)

KRoN73 ★★★★★
() автор топика
22 мая 2016 г.

По сабжу — всё было замечательно последующие три месяца…

Но пару дней назад чудовищно возросла нагрузка на io сервера. Вот просто, практически единомоментно. Интересно, что если останавливать PHP в контейнере Авиабазы, то все оставшиеся сервисы начинают летать. В т.ч. PHP в других контейнерах. Если работает PHP Авиабазы, то тормозят диск чаще не его процессы, а nginx, раздающий мелкую статику…

Если число параллельных процессов PHP в контейнере Авиабазы резко ограничивать и урезать время работы каждого — всё начинает более-менее работать. Так сейчас и выкручиваюсь. Если увеличивать число процессов и/или возвращать время работы, всё начинает резко тормозить.

Сегодня вообще прикол обнаружил. Попутно логгирую тяжёлые PHP-скрипты через xhprof, чтобы видеть, что тормозит. Обычно тормозят (sic!) MySQL-запросы (третья сущность в области тормозов). Но, вдруг, вижу, как PHP-скрипт в течении 129 секунд ожидал выполнения функции session_start(). Ну да, понятно, она файл сессии пишет на диск и когда диск тормозит, всё может тоже виснуть. Вот только файлы сессии пишутся в … tmpfs. Т.е. оно 129 секунд ждало очереди на запись в RAM-диск o_O.

В общем, в системе какие-то кранты с io и не похоже, что это проблема с HDD (smartctl/mdadm/dmesg — всё идеально). Пока планирую тупо снимать нагрузку, перенося часть тяжёлых операций на другие сервера. Но это — косметика поверх трупных пятен зомби, какая-то.

KRoN73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.