Диагностирование Соляриса 8 памятей сервера и использование области подкачки
Чтобы выяснить, испытывают ли Ваши серверы недостаток в RAM, полезная метрика была бы столбцом сэра в выводе команды vmstat. Просто выполните что-то как vmstat 10 10 в отчетные и пиковые периоды (10 образцов каждые 10 секунд) и сообщение вывод. swap -s выводы также были бы полезны. Кроме того, к vmstat, Вы могли бы предпочесть работать sar -g 5 5 В любом случае server2, кажется, испытывает недостаток в RAM согласно "главному" выводу. Солярис имеет поддерживаемую команду, подобную для положения во главе, который мог бы также помочь идентификации потребителей виртуальной памяти и физической памяти:
prstat -s rss -n 5
prstat -s size -n 5
Вещи, которые выделяются мне в этих снимках, следующие:
- Много процессов жемчуга
- Несколько процессов webservd
- Машины составляют 98% и неактивных 99%
Эти факты приводят к следующим вопросам...
- Можно ли сократить количество процессов жемчуга?
- Я предполагаю, что нет никакого способа переключиться на потоковую модель веб-сервера?
- На что похожа системная вершина, когда машины находятся в условиях стресса?
Наконец, я сделал бы следующее для разыскивания этого:
- Используйте сетевой анализатор как Wireshark для наблюдения, какая часть Процесса HTTP на самом деле держится. Действительно ли это - соединение? Действительно ли это - доставка страницы? Действительно ли это - доставка динамической части страницы?
- Получите инструмент напряжения HTTP и подчеркните свои веб-серверы, чтобы видеть, как они реагируют. Следите за ответами с vmstat и вершиной: Мне нравится использовать экран в терминале, чтобы сделать это.
Удачи!
Я всегда находил, что самым легким способом отследить использование памяти является учет системных ресурсов. Это может перейти вокруг много, таким образом, важно рассмотреть, по крайней мере, неделю для наблюдения шаблона использования.
Отредактируйте "sys" crontab, и Вы будете видеть, что некоторые прокомментировали выполнения сценария/usr/lib/sa/sa1. То, как часто это работает, определяет разрешение времени бухгалтерских сохраненных данных. Я обычно делаю что-то вроде этого для 24x7 система:
20,40 * * * * /usr/lib/sa/sa1
Это сохранит статистику в/var/adm/sa ко дню месяца. Теперь Вы используете SAR для дампа статистики памяти в течение любого изо дней, сохраненных там. Скажите, что 3-м был пиковый день для меня:
sar -f /var/adm/sa/sa03 -g
Столбец главного интереса является pgscan/s. Если то число - более чем 200 в течение долгих промежутков времени затем, система не имеет достаточной памяти. В 100 Вы, вероятно, извлечете выгоду из большей памяти, но неисправность не серьезна. В эти дни с дисковой подкачкой настолько медленнее, чем память, я пытаюсь сохранить его в 0 за исключением краткосрочных переходов.