Ситуативный рост IOWAIT с завершением крэшем

[dignity]

Добрый день, коллеги,

 

после достаточно продолжительных попыток самолечения решил воспользоваться коллективным разумом: Есть сервер Debian 8 / 2xE5640 / 48GB RAM, который периодически уходит в пике по IOWAIT. Изначально он был собран на R5 LSI HW / LVM2 / 6xSSD240, после долгих попыток добиться стабильной работы с uptime больше 2-3 недель был выкинут RAID и куплен серверный накопитель 1.9TB, на который все было перенесено (на другой такой же сервер уже без RAID, без MD, только LVM2).

 

Сегодня проблема повторилась снова.

 

Никакой корреляции между iostat / iotop и iowait я не вижу в момент проблемы. Проблема воспроизводится на двух одинаковых серверах (Fujitsu RX200). IOPS на момент возникновения проблемы ~ 2000, что никак не отличается от средних значений. В dmesg ничего подозрительного, никто не hung, никаких стектрейсов.

 

Ядро:

 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u3 (2017-08-15) x86_64 GNU/Linux

 

В скриншоте развитие ситуации с точки зрения zabbix.

 

Буду признателен направлению копания. Спасибо.

[nuclearcat]

12 минут назад, dignity сказал:

Добрый день, коллеги,

 

после достаточно продолжительных попыток самолечения решил воспользоваться коллективным разумом: Есть сервер Debian 8 / 2xE5640 / 48GB RAM, который периодически уходит в пике по IOWAIT. Изначально он был собран на R5 LSI HW / 6xSSD240, после долгих попыток добиться стабильной работы больше 2-3 недель был выкинут RAID и куплен серверный накопитель 1.9TB, на который все было перенесено (на другой такой же сервер). Сегодня проблема повторилась снова.

 

Никакой корреляции между iostat / iotop и iowait я не вижу в момент проблемы. Проблема воспроизводится на двух одинаковых серверах (Fujitsu RX200). IOPS на момент возникновения проблемы ~ 2000, что никак не отличается от средних значений. В dmesg ничего подозрительного, никто не hung, никаких стектрейсов.

 

Ядро:

 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u3 (2017-08-15) x86_64 GNU/Linux

 

В скриншоте развитие ситуации с точки зрения zabbix.

 

Буду признателен направлению копания. Спасибо.

Имхо надо скидывать куда-то по сети pidstat, и возможно при всплеске iowait начинать кидать туда же максимально подробные ps axv, cat /proc/meminfo и т.п.
также включите netconsole и syslog по сети, часто возможности скинуть что-то на диск нет, особенно если беда случилась с дисковой подсистемой.

[dignity]

2 часа назад, nuclearcat сказал:

Имхо надо скидывать куда-то по сети pidstat, и возможно при всплеске iowait начинать кидать туда же максимально подробные ps axv, cat /proc/meminfo и т.п.
также включите netconsole и syslog по сети, часто возможности скинуть что-то на диск нет, особенно если беда случилась с дисковой подсистемой.

Основная проблема-то в том, что я сегодня наблюдал именно момент этого самого роста и не видел нигде никаких аномалий, так что вариант с тем, что система что-то не успевает журналировать отпадает. Кроме того, мы не падаем по Panic, а уходим в пике IOWAIT (как на графиках видно). Обновили ядро до 4.9 из backports, будем дальше наблюдать.

[taf_321]

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

[dignity]

14 минут назад, taf_321 сказал:

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

Такая гипотеза есть, но:

- Это бы отражалось в IOPS SSD, а я не видел ничего необычного;

- во вложении картинка RAM/Swap, которая показывает, что она была на момент развития кризиса и в момент (когда Zabbix агент смог выдать результат), кроме того SWAP всего 4GB к 48GB RAM.

[nuclearcat]

Пока вы не включите netconsole - это гадание на кофейной гуще. С большой вероятностью именно в netconsole оно напишет, что случилось. Если нет - то еще есть вариант pstore, но он сложный

[NiTr0]

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

[dignity]

12 часов назад, NiTr0 сказал:

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

Обновили пока ядро до нового из бэкпортов, если будут проблемы, то сделаем netconsole. Я просто не до конца понимаю релевантность вот в связи с чем. Когда кризис, который на чарте отображен, развивался, я был на узле в этот момент и вывел dmesg, там никаких интересных вещей не было. Как я понимаю, идея в том, что в момент развития донельзя он что-то напишет в него? Просто, сервер не заканчивает жизнь Kernel panic, etc, а уходит в растущий iowait и все... Возможно, что дело, правда в swap, понаблюдаю.

[default_vlan]

Я с глупыми вопросами :)

В момент кризиса top не просматривали? (не iotop) Сколько раз сталкивался - искал проблему не там, где она была. IOWAIT может быть только следствием. Или нет?

Edited September 6, 2017 by default_vlan

[dignity]

33 минуты назад, default_vlan сказал:

В момент кризиса top не просматривали? (не iotop) Сколько раз сталкивался - искал проблему не там, где она была. IOWAIT может быть только следствием. Или нет?

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

[Tosha]

ИМХО:

Сами по себе попугаи iops не интересны - интересно сколько %util загруженности дисков показывает "iostat -mx 1"   Вы вполне можете упереться в узкое место по шине. Или в скорость стирания блоков SSD. Все зависит от размеров блоков. Например, 2000 IOPS по 1Мбайт это 16Гигабит - такое сложно переварить. А 60000+ IOPS производительности SSD в их ТТХ  - это для 512 байтных блоков. И не каждый контроллер на, допустим, 4 SATA3 порта может дать честных 24 Гигабита до оперативной памяти. 

Надо смотреть 4 числа: IOPS чтения, средний размер блока, IOPS записи, средний размер блока и %util  Только тогда можно судить насколько узким местом является система хранения и почему. 

Ну и в качестве бреда какие пределы "dirty_bytes" установлены? (там их несколько разных) Хотя проблемы с очень большим числом в этих параметрах характерны обычно только для традиционных дисков.

А в период приступа "колом" встает все или страдают только какие-то отдельные процессы? Ну банально открыть файл получается мгновенно или с заметной паузой?

И еще по поводу свопинга...  В 64-бит режиме исполняемые файлы, как я слышал, открываются методом маппинга в память. И вся совокупность запущенных процессов это есть большой "своп". Эти страницы могут вытесняться из памяти если нужна память и по необходимости снова загружаться. Т.е. может быть активный неявный свопинг если свободной памяти мало. Даже если выделенный своп вообще не подключен.

Может быть какие-то процессы не могут поделить какой-то общий для них ресурс. И не обязательно это диск. Может быть идет война за блокировку любого дискриптора. Семафоры там какие-нибудь и мьютексы. Вполне может быть это либо плохо написанное приложение либо просто плохо поддающееся распаралелливанию. Такое Вы никаким "iostat" и "iotop" не отследите. Тут надо профилировать сами процессы. В каких системных вызовах они зависают. Впрочем, я не уверен что это учитывается в iowait.

Вы не смотрели какие именно процессы повисают в состоянии высокого iowait?

Высокий iowait может и не быть сам по себе плохим признаком если не происходит деградации в работе системы. Т.е. если ничего не тормозит.

Какие есть еще симптомы кроме высокого iowait?

[TheUser]

В момент возникновения проблемы выключить сеть?

[ichthyandr]

Приклады какие работают на сервере?

[NiTr0]

9 часов назад, Tosha сказал:

 В 64-бит режиме исполняемые файлы, как я слышал, открываются методом маппинга в память.

в любом режиме, хоть 64 хоть 32. и в любой ос (ну кроме реликтов типа windows 3.11 - про них речь не идет).

[RN3DCX]

13 часов назад, Tosha сказал:

И не каждый контроллер на, допустим, 4 SATA3 порта может дать честных 24 Гигабита до оперативной памяти

Я может и ошибаюсь, но вроде 12,5 ГБайт/с это потолок для материнской платы.

[Tosha]

13 часов назад, RN3DCX сказал:

Я может и ошибаюсь, но вроде 12,5 ГБайт/с это потолок для материнской платы.

12 Гигабайт это 96 Гигабит :)
 

[RN3DCX]

14 часов назад, RN3DCX сказал:

Я может и ошибаюсь, но вроде 12,5 ГБайт/с это потолок для материнской платы.

Тфю, я имел ввиду 12,5 Гбит.

[kayot]

1 час назад, RN3DCX сказал:

Тфю, я имел ввиду 12,5 Гбит.

Откуда такие дикие измышления? Одна линия PCIE 3.0 дает 8гбит/с. А линий таких на серверной матери может быть и 50 штук.

Стандартный 16x слот уже дает 125гбит/с, это если про внешние разъемы и шины. Ну а скорость памяти давно многие десятки гигабайт/с..