Прежде всего предыстория -
Внезапно (буквально за ночь) экземпляр начинает выдавать предупреждения об использовании ЦП. Это довольно скромная виртуальная машина (1 виртуальный ЦП, 2 ГБ ОЗУ), но все, что она делает, - это очень низкое обслуживание NFS и опрос Cacti и обслуживание нескольких систем. Эта виртуальная машина размещена у поставщика IaaS на vSphere 4.x и входит в комплект корпоративного уровня (HP / NetApp SAN и т. Д.).
В последний раз я менял что-либо в этой системе почти 4 недели назад. Просматривая показатели, один из агентов / процессов провайдера, используемых McAfee (cma), потреблял НАМНОГО больше оперативной памяти, чем обычно, пока не было выполнено задание cron. Я перезапустил службу на прошлых выходных (задание cron есть, потому что я убежден, что у этого агента есть утечка памяти). В любом случае, проблема в том, что я больше не могу запускать Cacti (httpd / mysql / php cron job, который запускает poller.php) в этой системе - нагрузка возрастет более 10, а iowait действительно высок (~ 90%). Я пробовал следующее:
Обновление yum (все) перегрузило систему в 6 раз и заняло несколько часов.
Я спросил у хостинг-провайдера, есть ли что-нибудь не так со слоем хранения, но они ответили, что нет. Но это просто не считается. Это заставило меня задуматься, может ли быть проблема с неправильным выравниванием разделов, так как я читал, что это может вызвать те симптомы, которые я, кажется, испытываю. Теперь провайдер создал бы эти разделы VMFS в клиенте vSphere / vCenter, который, как я понимаю, обеспечивает выравнивание. Но может ли он со временем выйти из строя? Если да, есть ли способ обнаружить это с виртуальной машины / гостя? Утилита mbrscan (NetApp) выглядит так, как будто обнаруживает, но ее нужно запускать с консоли ESX хоста.
Спасибо!
Изменить: вывод sfdisk с добавлением uS:
[root@nfs1 ~]# sfdisk -luS /dev/sda
Disk /dev/sda: 13054 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/sda1 * 63 208844 208782 83 Linux
/dev/sda2 208845 164055779 163846935 83 Linux
/dev/sda3 164055780 209712509 45656730 8e Linux LVM
/dev/sda4 0 - 0 0 Empty
Обновить:
Перезагрузка этого экземпляра полностью решила проблемы с производительностью. Дальнейший анализ, проведенный хостинг-провайдером, показал, что есть некоторая несогласованность, но, по их мнению, это не приведет к появлению симптомов. Они говорят, например, что несогласованность в виртуальных машинах Windows больше. На этом этапе мы собираемся подождать и посмотреть, произойдет ли это снова, и если да, изменим смещение сектора.
Единственный способ увидеть проблемы с выравниванием - измерить основную загрузочную запись. Если вы можете сделать это на своей виртуальной машине, вы увидите, не смещены ли вы.
Тем не менее, проблемы с выравниванием увеличивают количество операций ввода-вывода, которые вы выполняете для хранилища, но должны быть некоторые ограничения, которые не позволят вам выполнить это увеличенное количество операций ввода-вывода. Это особенно сильно сказывается на Netapp, поскольку они начинают ограничивать производительность, как только количество «частичных операций записи», требующих дополнительного внимания со стороны их серверной части, достигает определенного уровня. В других системах каждый ввод-вывод обрабатывается так же, как и предыдущий, поэтому не должно быть такого резкого скачка задержки хранилища, как у NetApp.
Вы должны быть в состоянии узнать согласование гостя с sfdisk в Linux. Просто посмотрите, что это начальные сектора ваших разделов. Но, это расскажет вам только половину истории, поскольку ваш провайдер может / должен учитывать выравнивание ОС по умолчанию на уровне хранения.
Таким образом, даже если кажется, что он не выровнен примерно на 63 секторах, хранилище может иметь смещение в LUN или хранилище данных, чтобы скорректировать его до выровненной границы. Но, по крайней мере, вы можете передать свои новые знания своему провайдеру и попросить их подтвердить.
Обновление (для новых результатов sfdisk): ни один из ваших разделов не выровнен по одной и той же границе блока 4 КБ или 8 КБ, поэтому вполне вероятно, что вы испытываете некоторую боль несовпадения. Вам нужно спросить своего провайдера, какое выравнивание блоков использует хранилище (например, 4 КБ) и какие коррекции выравнивания они используют, если таковые имеются. Если у них нет какой-либо коррекции выравнивания, вы хотите, чтобы все ваши разделы начинались с числа секторов, равномерно делимого на 8 или 16. Пока вы на нем, даже начальное смещение в 1 МБ (равномерно делимое на 2048) допускает любое базовое размер блока хранения изменится в будущем.