Итак, в последнее время у меня возникли некоторые проблемы с производительностью сервера. В настоящее время мы используем сервер Fedora с 4 ГБ и 160 ГБ дискового пространства. Мы практически исчерпываем диск со всеми файлами, которые у нас есть на борту. Мы запускаем несколько веб-сайтов с несколькими резервными копиями для каждого веб-сайта. Однако только один сайт на самом деле получает трафик. Это сайт электронной коммерции с хорошим количеством посетителей.
В последнее время загрузка стала медленной, и я заметил, что свободной памяти стало совсем мало (меньше ГБ). Я перезапущу сервер (сейчас мне приходится делать это 3 раза в день), и все будет в порядке. Мы начинаем с 2,2 ГБ освобожденной памяти, но через 3 или 4 часа вы замечаете, что память начинает заполняться, и время загрузки ползет. Я не могу понять, откуда это берется или просто пора обновиться до лучшего сервера. Я просто не хочу обновляться, а потом понимаю, что где-то у меня узкое место с запросами MySQL.
Будем признательны за любые идеи и предложения.
РЕДАКТИРОВАТЬ-
Также имеется 3 виртуальных хоста и более 60 000 файлов.
total used free shared buffers cached
Mem: 4003 3372 630 0 398 1717
-/+ buffers/cache: 1256 2746
Swap: 8189 0 8189
21:21:49 up 46 min, 1 user, load average: 3.75, 4.20, 4.03
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 2 0 592728 409640 1838360 0 0 165 411 953 473 9 8 47 36 0
А вот и верхний снимок.
1356 mysql 20 0 1374m 219m 5320 S 5.6 5.5 14:06.21 mysqld
15796 root 20 0 103m 20m 440 D 1.0 0.5 0:04.42 sendmail
1081 root 20 0 103m 20m 440 D 0.7 0.5 0:21.73 sendmail
24013 root 20 0 97416 22m 2648 D 0.7 0.6 0:15.15 mailq
1525 root 20 0 247m 7980 3472 S 0.3 0.2 0:06.88 vlogger (access
1530 apache 20 0 539m 13m 3008 S 0.3 0.3 0:03.56 httpd
2399 apache 20 0 539m 12m 2748 S 0.3 0.3 0:00.85 httpd
5763 root 20 0 121m 4932 3868 S 0.3 0.1 0:00.07 sshd
12326 apache 20 0 539m 12m 2992 S 0.3 0.3 0:00.38 httpd
12421 apache 20 0 539m 12m 2988 S 0.3 0.3 0:00.45 httpd
16396 apache 20 0 538m 12m 2284 S 0.3 0.3 0:00.09 httpd
17050 root 20 0 15368 1256 868 R 0.3 0.0 0:00.09 top
1 root 20 0 37336 4104 1908 S 0.0 0.1 0:02.82 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0
7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H
8 root RT 0 0 0 0 S 0.0 0.0 0:00.11 migration/0
9 root RT 0 0 0 0 S 0.0 0.0 0:00.01 watchdog/0
10 root RT 0 0 0 0 S 0.0 0.0 0:00.14 migration/1
12 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
13 root 20 0 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/1
14 root RT 0 0 0 0 S 0.0 0.0 0:00.01 watchdog/1
15 root RT 0 0 0 0 S 0.0 0.0 0:00.15 migration/2
17 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/2:0H
18 root 20 0 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/2
19 root RT 0 0 0 0 S 0.0 0.0 0:00.01 watchdog/2
20 root RT 0 0 0 0 S 0.0 0.0 0:00.11 migration/3
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/3:0H
23 root 20 0 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/3
24 root RT 0 0 0 0 S 0.0 0.0 0:00.01 watchdog/3
25 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset
26 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
27 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
28 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
29 root 20 0 0 0 0 S 0.0 0.0 0:00.00 xenwatch
решение1
Увеличьте sar и выводите таблицу ps каждую минуту. Смотрите мой подробный ответздесь.
В следующий раз, когда сервер взорвется, используйте sar -r, чтобы помочь отследитькогдаэто произошло. Теперь используйте вывод из ps-cronjob или из моегоperl-обертка для ps на github, чтобы выяснить, какой процесс мог быть виновником.
Допустим, сервер взорвался между 12:00:00 и 13:00:00. Используйте sar -r -s 12:00:00 -e 13:00:00. Из этого вы должны увидеть всплеск в данных. (Если это проще, есть утилита на основе Java для построения графиков, но обычно это не стоит усилий.) Допустим, вы видите всплеск (или провал) в 12:15. Теперь просмотрите столбчатый вывод ps на предмет временного диапазона между, скажем, 12:00 и 12:15, отсортируйте его по pid, а затем по времени и посмотрите на столбцы памяти:
awk '/^=== .* 12:00:/,/^=== .* 12:16:/' /var/log/sa/ps/today |
sort -k 1n -k 16
(Параметры сортировки предполагают, что время находится в столбце 16, что может быть, а может и не быть правдой). Теперь вы можете снова отфильтровать этот вывод через awk, чтобы найти различия между строками вывода:
... | awk 'lastpid && lastpid==$1 && last != $0 { print} /^[0-9]/ { lastpid=$1;last=$0; }'
Это довольно грубый фильтр. Для некоторых процессов (чьи командные строки постоянно меняются, например, с mysql, postgresql и snmpd) это не очень поможет, но, надеюсь, вы сможете настроить awk, чтобы помочь вам найти виновника(ов).