Jump to content
Калькуляторы

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

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

 

после достаточно продолжительных попыток самолечения решил воспользоваться коллективным разумом: Есть сервер 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.

 

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

io.png

Share this post


Link to post
Share on other sites
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.

 

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

io.png

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

Share this post


Link to post
Share on other sites
2 часа назад, nuclearcat сказал:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
14 минут назад, taf_321 сказал:

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

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

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

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

ram.png

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
12 часов назад, NiTr0 сказал:

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by default_vlan

Share this post


Link to post
Share on other sites
33 минуты назад, default_vlan сказал:

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

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

Share this post


Link to post
Share on other sites

ИМХО:

Сами по себе попугаи 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?

Share this post


Link to post
Share on other sites
9 часов назад, Tosha сказал:

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

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

Share this post


Link to post
Share on other sites
13 часов назад, Tosha сказал:

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

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

Share this post


Link to post
Share on other sites
13 часов назад, RN3DCX сказал:

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

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

Share this post


Link to post
Share on other sites
14 часов назад, RN3DCX сказал:

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

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

Share this post


Link to post
Share on other sites
1 час назад, RN3DCX сказал:

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now