Как в Linux мониторить непрерывность предоставления CPU виртуализатором изнутри VM?
Ситуация следующего плана: софт на Java бежит под Debian, который крутится в виртуалке (предположительно, под XEN-ом). Логика софта чувствительна к таймаутам порядка одной-двух секунд (управление железом через сокеты, большое количество соединений с watchdog). На стенде все пучком. В продакшене у одного клиента система периодически встает раком: многие (но не все!) соединения падают без видимых причин. Падение / восстановление соединений, в принципе, обрабатывается софтом корректно, но очень хочется докопаться до причины явления, т.к. для нормальной работы всей системы его нужно исключить совсем или хотя бы свести до контролируемого минимума.
Для этого уже длительное время мониторится все возможное, от пингов между компонентами, до нагрузки на свитчи, бесперебойность PoE и т.д. и т.п. По результатам сеть, как причину, уже, в принципе, можно исключить, и подозрение падает на виртуализатор. Это - единственная компонента, к которой нет вменяемого доступа (эксплуатируется клиентом - никого не подпускают ни под каким видом).
Рабочая гипотеза сводится к тому, что виртуализатор недокладывает тиграм мяса кратковременно перестает выделять нашей виртуалке CPU (bursting других VM?), что приводит к срабатыванию таймаутов watchdog-ов, и наш софт, "проснувшись", начинает восстанавливать соединения, которые, на самом деле, не упали. Гипотеза, конечно, очень смелая, но это - единственный способ, которым пока на стенде удается воспроизвести ситуацию. Разумеется, запросы к местным админам заканчиваются ответом: "Не, не знаем - у нас все в порядке".
Отсюда, собственно, вопрос: встречался ли кто-нибудь с тулзами, которыми в Linux можно логировать провалы в предоставлении системе CPU виртуализатором изнутри самой системы. Ясное дело, можно написать самому... Однако, если кто-то встречался с подобными штуками, буду крайне признателен за советы или, по крайней мере, пинки в нужном направлении.
Проблема решена, гипотеза подтвердилась. Непосредственно по вопросу: мониторить проще всего с помощью: iostat -c | awk 'NR==4 {print $5}'
Это же значение выдает и top (самое правое в строке %CPU, "0,0 st", что означает steal time), но оттуда его муторнее выдерать.
Большое спасибо всем за советы и высказанные предположения!
@Rostel: Спасибо за идею! Увы, доступа к XENу нет никакого. Тамошние админы, похоже, даже не знают, что это такое и за любым чихом обращаются к какому-то подрядчику, что стоит денег и мороки... короче, если их не тыкнуть носом в проблему, никаких телодвижений там не будет :( Уточняющий вопрос: если XPET выключен, значит ли это, что ядро будет при любом раскладе показывать (например, через iostat) stolen time = 0,00 ?
Возможно другой таймер доступен, но не факт что он не "плывет".
Как именно смотреть ищите в сети.
Как сейчас помню, FreeSWITCH как-то обнаруживает рассинхрон с внешним миром и ругается в консоль что подстраивает свой опорный программный таймер.
Просто говорите клиенту что проблема в его виртуализации и он со свими спецами решает её на свой стороне, это совершенно нормально, то что пытаетесь делать вы это не эффективный бред, каждой проблеме свой инструмент.
Самая частая проблема это к примеру бекап, когда делается на виртуализации бекап происходит такой сильный лаг на всех виртуалках, если скажем для сайтов которые загружены только днем , а бекап ночью все равно то для вашей системы это смерти подобно, вторая частая проблема прожорливый сосед, соседняя виртуалка выжрала все ресы и ваша система соснула таймаутов.
> предположительно, под XEN-ом
Для того, что бы проверить под чем именно используйте команду lscpu.
Если Xen, то вы увидите строчку
Hypervisor vendor: Xen
Если KVM, то
Hypervisor vendor: KVM
Вот если VirtualBox(бывает и такое в продакшене, сам видел), то не увидите про гипервизор, увы. Определив кто там мяса не докладывает будет легче уже.
