Перейти к содержимому
Калькуляторы

Ситуативный рост 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 по сети, часто возможности скинуть что-то на диск нет, особенно если беда случилась с дисковой подсистемой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

ram.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем default_vlan

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ИМХО:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.