Я пытаюсь выяснить, привязан ли мой сервер к сети ввода-вывода или к процессору. Я посмотрел на вывод некоторых типичных инструментов для проверки текущего состояния системы (вывод iostat, sar и top ниже), но я не совсем уверен, верна ли моя интерпретация вывода.
Это моя установка:
Что делают серверы:
Для повышения пропускной способности мы только что установили 4 дополнительных экземпляра JBoss, поэтому теперь есть 5 экземпляров нашего приложения, выполняющих импорт (без кластеризации). К сожалению, производительность не улучшилась так сильно, как я надеялся.
Вот статистика, которую я собрал на сервере базы данных:
верхняя:
top - 14:09:28 up 27 days, 9:45, 1 user, load average: 0.65, 0.69, 0.83
Tasks: 92 total, 1 running, 91 sleeping, 0 stopped, 0 zombie
Cpu(s): 10.8% us, 1.1% sy, 0.0% ni, 85.5% id, 1.7% wa, 0.1% hi, 0.8% si
Mem: 65884336k total, 61751244k used, 4133092k free, 524752k buffers
Swap: 8388600k total, 1097864k used, 7290736k free, 32520508k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9187 mysql 16 0 26.8g 26g 4168 S 49.3 41.7 12455:36 mysqld
1 root 16 0 656 88 56 S 0.0 0.0 0:06.30 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.62 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0
Таким образом, сервер базы данных в значительной степени простаивает, и я больше не исследовал его.
Вот статистика, которую я собрал на сервере приложений:
верхняя:
top - 14:31:11 up 43 days, 23:25, 1 user, load average: 7.31, 7.13, 6.90
Tasks: 87 total, 2 running, 85 sleeping, 0 stopped, 0 zombie
Cpu(s): 58.0%us, 3.9%sy, 0.0%ni, 35.7%id, 0.0%wa, 0.1%hi, 2.2%si, 0.0%st
Mem: 16440520k total, 15894640k used, 545880k free, 79580k buffers
Swap: 8192616k total, 56k used, 8192560k free, 2968948k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8318 lvs 18 0 2773m 2.2g 13m S 101 14.0 1233:34 java
8367 lvs 18 0 2752m 2.2g 13m S 65 13.9 1217:41 java
8118 lvs 18 0 4731m 2.2g 13m S 58 14.2 1201:01 java
8278 lvs 18 0 2755m 1.9g 13m S 21 12.3 1212:48 java
8411 lvs 20 0 2743m 2.1g 13m S 8 13.4 1206:58 java
1 root 18 0 6124 676 560 S 0 0.0 0:04.10 init
2 root RT 0 0 0 0 S 0 0.0 0:01.18 migration/0
3 root 34 19 0 0 0 S 0 0.0 0:00.12 ksoftirqd/0
Здесь средняя нагрузка довольно высока, как и загрузка процессора. Что меня озадачивает, так это тот факт, что загрузка процессора не всегда высока. Вот что я получил, когда наблюдал за использованием процессора в течение 20 секунд с помощью iostat:
lvs@ftpslavedev:~$ iostat -c | head -3 ; iostat -c 1 20 | grep "^ *[0-9]"
Linux 2.6.18-6-amd64 (ftpslavedev) 10/07/09
avg-cpu: %user %nice %system %iowait %steal %idle
2.40 0.00 0.34 0.16 0.00 97.10
58.00 0.00 4.00 0.00 0.00 38.00
50.62 0.00 3.23 0.00 0.00 46.15
35.16 0.00 3.49 0.50 0.00 60.85
75.43 0.00 5.46 0.00 0.00 19.11
72.07 0.00 2.49 0.25 0.00 25.19
50.12 0.00 4.24 0.00 0.00 45.64
50.25 0.00 1.00 0.00 0.00 48.75
32.18 0.00 3.71 0.00 0.00 64.11
51.74 0.00 1.99 0.00 0.00 46.27
53.12 0.00 2.99 1.00 0.00 42.89
47.64 0.00 2.73 0.00 0.00 49.63
13.18 0.00 2.74 0.00 0.00 84.08
0.00 0.00 2.24 0.00 0.00 97.76
0.25 0.00 3.23 0.00 0.00 96.52
0.00 0.00 2.74 0.50 0.00 96.77
0.00 0.00 2.99 0.00 0.00 97.01
17.41 0.00 2.74 0.00 0.00 79.85
23.19 0.00 2.99 0.75 0.00 73.07
23.33 0.00 3.23 0.00 0.00 73.45
Поскольку загрузка ЦП не всегда была высокой, я задумался, может ли связь между сервером приложений и базой данных быть узким местом, и использовал sar:
lvs@ftpslavedev:~$ sar -n DEV | head -3 && sar -n DEV 1 20 | grep "eth0.*[1-9]"
Linux 2.6.18-6-amd64 (ftpslavedev) 10/07/09
00:00:01 IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s
16:55:30 eth0 22562.00 21297.00 9632456.00 5156549.00 0.00 0.00 0.00
16:55:32 eth0 19690.10 18800.00 8496563.37 4558991.09 0.00 0.00 0.00
16:55:34 eth0 22716.00 21214.00 10610874.00 5378377.00 0.00 0.00 0.00
16:55:36 eth0 17737.62 16509.90 9027099.01 4784231.68 0.00 0.00 0.00
16:55:38 eth0 10749.69 9625.79 6233610.69 2357184.91 0.00 0.00 0.00
16:55:39 eth0 20929.70 21002.97 5359857.43 4705525.74 0.00 0.00 0.00
16:55:41 eth0 17462.38 17476.24 6281078.22 5062188.12 0.00 0.00 0.00
16:55:44 eth0 19410.19 19368.52 4770402.78 3916590.74 0.00 0.00 0.00
16:55:46 eth0 13388.12 13277.23 3501303.96 2883294.06 0.00 0.00 0.00
16:55:48 eth0 25988.12 24862.38 10358798.02 5966493.07 0.00 0.00 0.00
Значения в rxbyt / s и txbyt / s - это байты в секунду. Если я конвертирую их в Мбит в секунду, я получаю что-то вроде
rxbyt/s r Mbits/s txbyt/s t Mbits/s
9632456 73,49 5156549 39,34
8496563 64,82 4558991 34,78
10610874 80,95 5378377 41,03
9027099 68,87 4784231 36,50
6233610 47,56 2357184 17,98
5359857 40,89 4705525 35,90
6281078 47,92 5062188 38,62
4770402 36,40 3916590 29,88
3501303 26,71 2883294 22,00
10358798 79,03 5966493 45,52
3694266 28,19 2192922 16,73
Так что здесь часто бывают значения> 60 Мбит. Учитывая, что наш второй сервер приложений делает то же самое, я думаю, что вполне может случиться так, что наш брандмауэр (как указывалось ранее, способный обрабатывать только 100 Мбит) мог быть реальной причиной высокой средней нагрузки на сервере и, следовательно, даже добавление дополнительных серверов нам не сильно поможет.
Я не знаю, действительно ли моя интерпретация данных разумна, и буду благодарен за ваши комментарии по этому поводу.
С уважением,
Стефан
Хм, сложная проблема: - /. Один пункт:
Я думаю, что вполне может быть так, что наш брандмауэр (как было сказано ранее, способный обрабатывать только 100 Мбит) мог быть реальной причиной высокой средней нагрузки на сервер, и поэтому даже добавление дополнительных серверов нам не сильно поможет.
Если брандмауэр ограничивал передачу данных, вы не увидели бы высокой загрузки ЦП (% user выше); скорее вы увидите более высокий% iowait (поскольку он включает сетевой ввод-вывод). Так что это кажется маловероятным (если приложение не выполняет какой-либо опрос).
Я думаю, что ваш лучший способ действий - более внимательно изучить пользователей с высоким процентом на серверах приложений; выполните какое-то профилирование, чтобы узнать, что именно делает приложение при загрузке ЦП. Это должно дать вам ключ к разгадке.
Также стоит обратить внимание на межсетевой экран, поскольку вы приближаетесь к его возможностям.
почему вы не посмотрели трафик со стороны сервера базы данных? Если ваш брандмауэр поддерживает snmp, вы должны увидеть его нагрузку и, если ничего больше, то, по крайней мере, разницу между входящим и исходящим интерфейсами. Это должно дать вам некоторые идеи. Кроме того, хотя вы заявляете, что он поддерживает 100 Мбит / с, все еще неясно, сколько пакетов в секунду он может обрабатывать. Об этом тоже нужно помнить.