Я думаю, что версия Solaris, которую мы используем, слишком стара, чтобы отображать время кражи в топе. Есть ли способ получить эту информацию об этой старой версии 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, я подозреваю, что ЦП перегружен, но как я могу это измерить?
Обновить
Простите за терминологию Intelish. По сути, мы запускаем две виртуальные машины на одном блейд-сервере, одна из которых является сервером приложений, а другая обеспечивает поддержку SSO приложения. У нас бывают моменты, когда сервер приложений значительно замедляется, а также есть моменты, когда стороннее приложение SSO уходит в пропасть.
Здесь также есть разрозненность и политика, поэтому у меня нет видимости хоста SSO или фактического аппаратного уровня.
Моя текущая рабочая гипотеза состоит в том, что когда приложение SSO сходит с ума, оно настолько загружает ЦП, что сервер приложений не может получить достаточно реального времени вычислений, чтобы справиться с нагрузкой. Я проанализировал журналы сборки мусора из приложения и выделил одну вещь:
[Times: user=0.71 sys=1.36, real=1.47 secs]
То есть с 10 параллельными рабочими потоками GC, обычно user >> real >> sys и одна из причин нечетного времени - это виртуальная машина, на которой не хватает ЦП. (Мы не меняем местами, и все системы основаны на SSD, поэтому ожидания ввода-вывода не являются проблемой.)
На данный момент мне нужно получить данные, чтобы подтвердить эту теорию, и в моем понимании Linux я бы просто проверил st% вверху. Google также говорит, что в современной версии Solaris я мог бы сделать то же самое. Моя проблема в том, что мы не используем эту современную версию Solaris.
Ваша настоящая проблема здесь, похоже, заключается в снижении производительности. И время кражи, вероятно, бессмысленно на сервере 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 использует 4k страниц памяти, поэтому он фрагментирует память - и она будет фрагментирована. ВСЕ память на вашем сервере. Если ваш сервер попадает в это состояние и процессу требуется значительный объем больших страниц памяти, ядру приходится объединять кучу маленьких страниц в большие, что требует перемещения большого количества памяти. И все это делается в однопоточном режиме. И любой отдельный поток на сервере ранней серии 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 ГБ, чтобы предотвратить снижение производительности.