По сути, мой вопрос связан с выделением памяти для виртуальных машин 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
Чтобы выяснить, не хватает ли на ваших серверах ОЗУ, полезной метрикой будет столбец sr в выходных данных команды vmstat. Просто запустите что-нибудь вроде vmstat 10 10 во время эталонного и пикового периодов (10 выборок каждые 10 секунд) и опубликовать выходные данные. swap -s результаты также были бы полезны. В качестве альтернативы vmstat вы можете предпочесть запустить sar -g 5 5 В любом случае server2, судя по «верхнему» выводу, испытывает недостаток ОЗУ. Solaris имеет поддерживаемую команду, аналогичную команде top, которая также может помочь идентифицировать потребителей виртуальной и физической памяти:
prstat -s rss -n 5
prstat -s size -n 5
Я всегда находил, что самый простой способ отслеживать использование памяти - это системный учет. Он может много прыгать, поэтому важно рассмотреть как минимум неделю, чтобы увидеть схему использования.
Отредактируйте 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, за исключением кратковременных скачков.
На этих снимках я выделяю следующее:
Эти факты приводят к следующим вопросам ...
Наконец, чтобы отследить это, я бы сделал следующее:
Удачи!