☰

Как получить доступ к данным времени кражи в Solaris SunOS 5.10

tag-icon • tag-icon performance virtual-machines solaris performance-monitoring
Как получить доступ к данным времени кражи в Solaris SunOS 5.10

Я думаю, что версия Solaris, которую мы используем, слишком старая, чтобы сообщать о времени кражи в top. Есть ли способ получить эту информацию в этой старой версии Solaris? Вот основная информация о версии:

-bash-3.2$  uname -aX
SunOS sekritname 5.10 Generic_150400-59 sun4v sparc sun4vSystem = SunOS
Node = sekritname
Release = 5.10
KernelID = Generic_150400-59
Machine = sun4v
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 32

У меня нет настоящего опыта в этих системах Sun VM, поэтому я могу что-то не понимать, и, возможно, есть лучший способ сделать то, что мне нужно в этой ситуации. Применяя мою ментальную модель Intel, я подозреваю, что мы вытесняемся из ЦП, но как я могу это измерить?

Обновлять

Простите за терминологию Intel. По сути, мы запускаем две виртуальные машины на одном blade-сервере, где одна из них является сервером приложений, а другая обеспечивает поддержку SSO приложения. У нас бывают моменты, когда сервер приложений значительно замедляется, а также бывают моменты, когда стороннее приложение SSO уходит в труху.

Здесь также задействованы разрозненные хранилища и политика, поэтому у меня нет возможности видеть хост SSO или фактический аппаратный уровень.

Моя текущая рабочая гипотеза заключается в том, что когда приложение SSO сходит с ума, оно занимает процессор так сильно, что сервер приложений не может получить достаточно реального вычислительного времени, чтобы справиться с нагрузкой. Я проанализировал журналы GC из приложения, и одной из вещей, которая выделялась, были записи вроде этой:

[Times: user=0.71 sys=1.36, real=1.47 secs]

Это происходит при 10 параллельных рабочих потоках GC, как правило, user >> real >> sysи одной из причин странного временного шаблона является виртуальная машина, в которой не хватает ресурсов ЦП. (Мы не занимаемся подкачкой, и все системы основаны на SSD, поэтому ожидания ввода-вывода не являются проблемой.)

На этом этапе мне нужно получить данные, чтобы помочь доказать эту теорию, и в моем Linux-мышлении я бы просто проверил st% в top. Google также говорит, что в современной версии Solaris я мог бы сделать то же самое. Моя проблема в том, что мы не используем эту современную версию Solaris.

решение1

Ваша реальная проблема здесь, похоже, заключается в замедлении производительности. И steal-time, вероятно, бессмыслен на сервере Solaris 10 T1000/T2000.

Чтобы узнать, работаете ли вы в зоне, используйте /usr/bin/zonenameкоманду (расположение может отличаться в разных версиях Solaris — также проверьте /bin, /sbin/, и /usr/sbin.) Если zonenameвозвращается что-либо, отличное от global, вы работаете в зоне.

Если по какой-то причине у вас нет доступа к команде zonename, есть несколько psкоманд, которые вы можете использовать, чтобы узнать, находитесь ли вы в зоне. Сначала найдите init:

ps -ef | grep init

Если это не находит initпроцесс с PID 1, вы находитесь в зоне. Вы также можете поискать zsched(IIRC):

ps -ef | grep zsched

Если это возвращает один процесс, который является его собственным родительским процессом (PID и PPID одинаковы и больше 1), то вы работаете в зоне.

Если вы в зоне, вы можете столкнуться с ограничениями ресурсов, которые вас замедляют. Но это вряд ли так.

Чтоещеработает на сервере, хотя? Включая другие зоны. Я видел действительно неприятные проблемы с производительностью на серверах Sun T-серии, похожие на те, что вы описываете, вызванные взаимодействием между ZFS ARC и приложениями, которые используют огромные страницы памяти, такими как база данных Oracle.

ZFS ARC использует страницы памяти размером 4 КБ, поэтому она фрагментирует память — и она будет фрагментироватьВСЕпамять на вашем сервере. Если ваш сервер попадает в это состояние и процесс требует значительного количества больших страниц памяти, ядро ​​должно объединить кучу маленьких страниц в большие, что подразумевает перемещение большого количества памяти. И все это делается в однопоточном режиме. И любой отдельный поток на раннем сервере серии TМЕДЛЕННЫЙпоскольку серверы были спроектированы для обработки огромного количества потоков с большими задержками — например, веб-сервер или сервер баз данных, который обрабатывает множество подключений по сети.

Поэтому ядро ​​переходит в длительные периоды, в течение которых оно по сути только и делает, что объединяет маленькие страницы памяти в большие.

Затем ZFS ARC возвращает страницы после того, как процесс использования больших страниц завершен, и они фрагментируются.

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

Чтобы узнать, запустите

echo ::memstat | mdb -k

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

Чтобы выяснить это, запустите следующий скрипт dTrace, снова как root из глобальной зоны, чтобы определить, где ядро ​​тратит все свое время:

#!/usr/sbin/dtrace -s

profile:::profile-1001hz
/arg0/
{
    @[ stack() ] = count();
}

Скопируйте это в файл, скажем hot.d, сделайте его исполняемым ( chmod 755 hot.d) и запустите его как root из глобальной зоны:

./hot.d

Запустите его, когда вы испытываете замедление. Дайте ему поработать 10-20 секунд, если не дольше, после того, как он выдаст matched 1 probe, затем прервите его с помощью CTRL-C. Затем он выдастмноговывода, большинство из которых вам неинтересны. Однако последняя горстка вывода трассировок стека будет наиболее часто используемой выборкой, которая скажет вам, где ядро ​​тратит все свое время.

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

Если вы видите много трассировок стека с idleили waitв нем, у вас проблема с пользовательским пространством. Вы можете определить это, заменив stack()в приведенном выше скрипте dTrace на , ustack()чтобы получить пользовательский стек.

И если вы видите много трассировок стека coalesceв именах функций, ядро ​​тратит все свое время на создание больших страниц памяти. Исправление этого — освобождение памяти, скорее всего, ограничением размера ZFS ARC, возможно, даже серьезным. Мне пришлоськоленная чашечкаZFS ARC на нескольких серверах, до размера менее 1 ГБ, чтобы не допустить снижения производительности.

Связанный контент