Инструменты для мониторинга времени кражи (st)

Мы работаем на виртуальном «выделенном» сервере, что теоретически должно означать, что мы единственные парни на сервере. На практике .... я думаю, что мы не можем быть.

введите описание изображения здесь

Обратите внимание, что, хотя похоже, что мы убиваем нашу машину, «Время кражи» составляет 71%.

Я беру статистику по нагрузке, и я был разочарован тем, что эта статистика не отображается на моих графиках. Существуют ли инструменты, которые контролируют это, которые могут помочь?

Дополнительная информация:

У нас 4 ядра, модель:

# grep "model name" /proc/cpuinfo | sort -u
model name  : Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz

xen top virtualization

— mgjk
источник

Виртуальный посвященный? В случае XEN им нужно будет закрепить выделенные ядра для выделенного использования в вашей виртуальной машине. Похоже, у вашего провайдера перегружены процессоры из-за несправедливости. Что он говорит на это?

— Нильс

Сколько у вас vCPU и какой тип процессора указан grep "model name" /proc/cpuinfo|sort -u? Если это действительно выделенный сервер, значит, на Dom0 что-то поглощает процессорное время. ИЛИ они дали вам больше виртуальных процессоров, чем доступно в Dom0.

— Нильс

Если это не кратковременный выброс, то похоже, что ваш провайдер лжет вам, и они, на самом деле, запускают на этом компьютере другие тяжелые vms процессора, или что-то настроено очень неправильно, что заставляет dom0 перегружать процессорное время ,

— psusi

SuSE рекомендует резервировать два ядра исключительно для Dom0, чтобы он мог выполнять всю обработку ввода-вывода, не беспокоя другие виртуальные машины. На мой взгляд, это было бы необходимо только для систем с украденным временем в DomUs и интенсивным трафиком ввода-вывода. Я хотел бы знать, назначил ли ваш провайдер больше виртуальных ЦП, чем логических ядер - например, назначить 4 виртуальных ЦП, в то время как в Dom0 доступно только 2 логических ЦП - что также объясняет «украденный» (и это довольно умная идея - но возможно в XEN) ,

— Нильс

Основной причиной этого оказалось то, что провайдер неправильно настроил виртуальную машину. Гостьу сказали, что у него больше ядер, чем было на самом деле. Это, казалось, вызвало хаос с расписанием. ISP не смог обеспечить интеллектуальную техническую поддержку, но мы смогли «доказать» проблему, отключив нечетные ядра в / proc. Никогда проблем с тех пор.

— mgjk

Ответы:

Ваш вопрос четко определен, но вы не предоставляете много информации о вашей среде, о том, как вы в настоящее время отслеживаете или какие графические инструменты вы используете. Однако, учитывая, что SNMP используется практически повсеместно, я предполагаю, что вы используете его и по крайней мере знакомы с ним.

Хотя (насколько я могу судить) время похищения процессора в настоящее время недоступно из snmpd, вы можете расширить его самостоятельно с помощью UCD-SNMP-MIB::extOutputобъекта и execкоманд.

Самый простой способ (который я нашел) получить время кражи - от iostat. Используя следующую конструкцию, мы можем получить только время кражи:

$ iostat -c | awk 'NR==4 {print $5}'
0.00

Поэтому добавьте следующее в ваш snmpd.conf:

exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 {print $5}'

(В качестве альтернативы вы можете поместить команду в сценарий оболочки и вызвать оболочку изнутри snmpd.conf.)

Каждый execвход snmpd.confиндексируется начиная с 1. Поэтому, если у вас есть только один оператор exec, вам нужно будет опросить UCD-SNMP-MIB::extOutput.1. Если это 5-й оператор exec, тогда опрос UCD-SNMP-MIB::extOutput.5и т. Д.

Числовой OID для UCD-SNMP-MIB::extOutputэто .1.3.6.1.4.1.2021.8.1.101так , если вы на индексе 1 было бы .1.3.6.1.4.1.2021.8.1.101.1, а индекс 5 будет .1.3.6.1.4.1.2021.8.1.101.5, и т.д.

Затем вы создаете график опроса OID SNMPD типа gauge в диапазоне от 0 до 100. Это должно дать вам несколько симпатичных графиков.

— bahamat
источник

Отличный ответ. Как часто будут собираться эти статики? Просто во время опроса или есть способ, как в RMON-MIB, который будет записывать значения без внешнего опроса?

— Нильс

Я считаю, что это будет тянуть это каждый раз, когда snmpdзапрашивается для этого OID.

— Багамат

Если iostat не установлен: top -bn1 | sed -nr '3s /.*,// gp'

— Давид

sar -uможет быть полезным в вашем случае. sar обычно является частью пакета sysstat .

— Nils
источник

Хотел бы я, чтобы в качестве принятого ответа можно было указать более одного ответа. Оба ответа были очень полезны :-) Спасибо!

— mgjk

Ответ с наибольшим количеством голосов отличный, но в настоящее время он не полностью работает: net-snmp теряет канал в execвызове, поэтому это должно выглядеть так

extend-sh cpu_steal_time /usr/bin/iostat -c 1 1 | /usr/bin/awk '!/%user|Linux|^$/ {print $5}'

И результат будет виден под nsExtendOutput1Table:

# snmpwalk localhost NET-SNMP-EXTEND-MIB::nsExtendOutput1Table
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."cpu_steal_time" = STRING: 0.60
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."cpu_steal_time" = STRING: 0.60
NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."cpu_steal_time" = INTEGER: 1
NET-SNMP-EXTEND-MIB::nsExtendResult."cpu_steal_time" = INTEGER: 0

где nsExtendOutput1Lineoid равен .1.3.6.1.4.1.8072.1.3.2.3.1.1:

snmpwalk localhost .1.3.6.1.4.1.8072.1.3.2.3.1.1
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."cpu_steal_time" = STRING: 0.60

— drookie
источник