LINUX.ORG.RU
ФорумAdmin

Резко падает производительность Centos 7

 


0

1

Периодически резко падает производительность Centos 7. Железо - Dell PowerEdge T620, intel E5-2620v2 , 32GB ram, perc H710 raid10: 4*SSD intel S3500 + raid 1: 2*HDD wd blue 500 GB. Стоят последние обновления. Во время нормальной работы hdparm -t /dev/sda выдает ~450 MB/s, реальная скорость записи >300 MB/s. Во время тормозов hdparm -t /dev/sda ~90 MB, реальная скорость записи ~7 MB. В логах ОС никаких сообщений не появляется, в логах сервера тоже. Не представляю с чем может быть связано.

Изначально проблема проявилась через ~2 месяца аптайма. Было пару раз, что через некоторое время (пол часа-час) восстанавливалась нормальная работа. После выключения/включения сервера может нормально проработать больше месяца, а может через неделю повторится. С момента установки ОС (Январь 2015) по настоящее время сервер практически простаивал, нагрузка минимальна, но за это время уже раз 8-10 возникала такая проблема.

На сервере используется ПО: kvm (гостевые ОС win2008 + centos 7), 1c 8.3 (в работе реально не используется) + postgresql 9.2 (etersoft).

Во время тормозов наблюдается высокая нагрузка выделенных ядер CPU процессом kvm с win2008, хотя в самой гостевой ОС особой активности нету. После выключения гостевых ОС и останова kvm нагрузка на проц пропадает, но ничего не меняется.

Пару раз выскакивало сообщение в лог типа perf samples too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 Но по времени и дате не совпадало с началом тормозов.

Может ли такое поведение быть связано с железом и как это можно проверить?



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

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

Смотрите дисковые очереди.

Если ситуация позволяет - просто отключайте по-очереди всё, включая 1C и Postgres. Это позволит вам быстро понять, являются ли они прямыми или косвенными источниками проблемы. (виртуальные машины и KVM вы вычеркнули).

Следует учесть, что в SSD есть т.н. garbage collector, который может так же негативно влиять на производительность и patrol read контроллера, который может внезапно решиться проверить устройства на сбои. (тут утилита просмотра параметров контроллера вам поможет). Могут сбоить SSD - но боюсь за контроллером вы не увидите настоящих причин, поскольку напрямую они недоступны.

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

patrol read делается каждые две недели и сообщения об этом пишутся в лог сервера - по времени они не совпадают. garbage collector. Активность на сервере минимальна, и объемы записываемой инфы минимальны. Не уверен даже, что накопители были перезаписаны хотя бы один раз. Не думал, что из-за garbage collector может настолько проседать производительность. Смущает общая задумчивость системы. В момент тормозов даже пинг проходит со значительно большей задержкой, а при подключении по ssh возникает ощущение, что работаешь на каком-нить pentium 3 по dial-up, хотя cpu простаивает, а подключаюсь через локальный ethernet.

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