Диагностика использования памяти и пространства подкачки сервера Solaris 8

Диагностика использования памяти и пространства подкачки сервера Solaris 8

По сути, мой вопрос связан с распределением памяти для виртуальных машин Solaris.

Я запускаю пару старых веб-серверов Sun ONE 6 Java на двух виртуальных машинах Solaris 8. Я вижу, что используется разумный объем пространства подкачки, но я не совсем уверен, может ли это указывать на необходимость добавления дополнительной оперативной памяти на эти машины.

В часы пиковой нагрузки (обычно по утрам) время отклика веб-приложения, размещенного на этих серверах, увеличивается максимум до 11 секунд (что несколько пагубно для относительно простого действия по загрузке веб-страницы). Среднее время отклика в непиковые часы составляет около 5 секунд.

Что вы могли бы сделать относительно использования оперативной памяти для этих машин из вывода ниже? Достаточно ли этой информации? Или мне нужно будет выполнить какие-то другие команды, чтобы исключить нехватку памяти сервера?

Наконец, поскольку в основе установки лежит приложение Java, я также подумал о следующем:

1) Отследите распределение объектов в куче, чтобы обнаружить потенциальные утечки памяти.

2) Выполните профилирование производительности, чтобы увидеть, связано ли это с задержками в сети. Я упоминаю об этом, поскольку приложение взаимодействует с одной базой данных Oracle, но я сомневаюсь, что это так, поскольку они довольно близки с точки зрения сегментации сети.

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

Спасибо за ваше время и помощь.

Сервер 1:

40 processes:  38 sleeping, 1 zombie, 1 on cpu
CPU states: 99.1% idle,  0.4% user,  0.4% kernel,  0.0% iowait,  0.0% swap
Memory: 2048M real, 295M free, 865M swap in use, 3788M swap free

   PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
 12676 webservd 112  29   10  616M  242M sleep  103:37  0.48% webservd
 18317 root       1  59    0   23M   19M sleep   67:24  0.08% perl
  9479 support    1  59    0 6696K 2448K cpu/1    0:11  0.05% top
  8012 root      10  59    0   34M  704K sleep   80:54  0.04% java
  1881 root      33  29   10  110M   13M sleep   33:03  0.02% webservd
  7808 root       1  59    0   83M   67M sleep    7:59  0.00% perl
  1461 root      20  59    0 5328K 1392K sleep    6:49  0.00% syslogd
  1691 root       2  59    0   27M  680K sleep    4:22  0.00% webservd
 24386 root       1  59    0   15M   11M sleep    2:50  0.00% perl
 23259 root       1  59    0   11M 4240K sleep    2:42  0.00% perl
 24718 root       1  59    0   11M 5464K sleep    2:29  0.00% perl
 22810 root       1  59    0   19M   11M sleep    2:21  0.00% perl
 24451 root       1  53    2   11M 3800K sleep    2:18  0.00% perl
 18501 root       1  56    1   11M 3960K sleep    2:18  0.00% perl
 14450 root       1  56    1   15M 6920K sleep    1:49  0.00% perl

Сервер 2

 42 processes:  40 sleeping, 1 zombie, 1 on cpu
CPU states: 98.8% idle,  0.4% user,  0.8% kernel,  0.0% iowait,  0.0% swap
Memory: 1024M real, 31M free, 554M swap in use, 3696M swap free

   PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
  5607 webservd  74  29   10  284M  173M sleep   20:14  0.21% webservd
 15919 support    1  59    0 4056K 2520K cpu/1    0:08  0.09% top
 13138 root      10  59    0   34M 1952K sleep  210:51  0.08% java
 13753 root       1  59    0   22M   12M sleep  170:15  0.07% perl
 22979 root      33  29   10  112M 7864K sleep   85:07  0.04% webservd
 22930 root       1  59    0 3424K 1552K sleep   17:47  0.01% xntpd
 22978 root       2  59    0   27M 2296K sleep   10:49  0.00% webservd
 13571 root       1  59    0 9400K 5112K sleep    5:52  0.00% perl
  5606 root       2  29   10   29M 9056K sleep    0:36  0.00% webservd
 15910 support    1  59    0 9128K 2616K sleep    0:00  0.00% sshd
 13106 root       1  59    0   82M 3520K sleep    7:47  0.00% perl
 13547 root       1  59    0   12M 5528K sleep    6:38  0.00% perl
 13518 root       1  59    0 9336K 3792K sleep    6:24  0.00% perl
 13399 root       1  56    1 8072K 3616K sleep    5:18  0.00% perl
 13557 root       1  53    2 8248K 3624K sleep    5:12  0.00% perl

решение1

Чтобы выяснить, не хватает ли вашим серверам оперативной памяти, полезной метрикой будет столбец sr в выводе команды vmstat. Просто запустите что-нибудь вроде vmstat 10 10во время контрольных и пиковых периодов (10 выборок каждые 10 секунд) и опубликуйте вывод. swap -sтакже будет полезен вывод. В качестве альтернативы vmstat вы можете предпочесть запустить sar -g 5 5 В любом случае, похоже, что server2 не хватает оперативной памяти согласно выводу "top". Solaris поддерживает команду, похожую на top, которая также может помочь определить потребителей виртуальной и физической памяти:

prstat -s rss -n 5
prstat -s size -n 5

решение2

На этих снимках мне бросились в глаза следующие моменты:

  • Множество процессов perl
  • Несколько процессов webservd
  • Машины простаивают на 98% и 99%

Эти факты приводят к следующим вопросам...

  • Можно ли уменьшить количество процессов Perl?
  • Полагаю, нет возможности перейти на потоковую модель веб-сервера?
  • Как выглядит верхняя часть системы, когда машины находятся под нагрузкой?

Наконец, чтобы это отследить, я бы сделал следующее:

  • Используйте сетевой сниффер, например Wireshark, чтобы увидеть, какая часть процесса HTTP на самом деле задерживается. Это соединение? Это доставка страницы? Это доставка динамической части страницы?
  • Получите инструмент HTTP stress и нагрузите свои веб-серверы, чтобы увидеть, как они отреагируют. Посмотрите ответы с vmstat и top: Мне нравится использовать screen в терминале для этого.

Удачи!

решение3

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

Отредактируйте crontab "sys", и вы увидите несколько закомментированных запусков скрипта /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, за исключением кратковременных скачков.

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