Вот уже около 5 дней, и, казалось бы, совершенно неожиданно, мой Linux-сервер время от времени начал блокироваться.
Шаблон всегда один и тот же, насколько я могу судить по командам top и iotop примерно в то время, когда это начинается:
Один или несколько процессов httpd (обычно один) зависают и начинают использовать 100% мощности ЦП,% wa приближается к 100%, а в iotop я вижу несколько процессов httpd с 99,99% в столбце ввода-вывода.
Я также запускаю сервер SVN на этом компьютере через apache, и единственный способ, которым я постоянно мог воспроизвести это, - это сделать SVN-фиксацию новых файлов или обновление SVN из репозитория на этом сервере (я только один, использующий этот репозиторий SVN). Это всегда будет успешно воспроизводить этот сценарий, но до недавнего времени у меня не было никаких проблем с проверкой входа / выхода из SVN.
Но иногда это происходит просто так, кажется, без видимой причины.
Итак, похоже, что с моим Apache есть проблема, из-за которой процессы используют много операций чтения / записи при определенных триггерах.
Мне было интересно, может ли кто-нибудь помочь мне раскрыть эту проблему.
РЕДАКТИРОВАТЬ: Хорошо, теперь это происходит снова:
Это топ:
[root@server ~]# top
top - 10:56:54 up 2:59, 5 users, load average: 171.46, 70.35, 27.01
Tasks: 328 total, 2 running, 326 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.9%us, 2.0%sy, 0.0%ni, 0.0%id, 96.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2021144k total, 1968192k used, 52952k free, 2500k buffers
Swap: 4194288k total, 2938584k used, 1255704k free, 39008k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10390 apache 20 0 2774m 936m 6200 D 2.0 47.4 1:52.27 httpd
2149 root 20 0 927m 13m 1040 S 0.7 0.7 1:50.46 namecoind
11 root 20 0 0 0 0 R 0.3 0.0 0:30.10 events/0
23 root 20 0 0 0 0 S 0.3 0.0 0:17.88 kblockd/1
2049 root 20 0 382m 4932 2880 D 0.3 0.2 0:03.67 httpd
2144 root 20 0 1702m 69m 1164 S 0.3 3.5 5:19.68 bitcoind
6325 root 20 0 15164 1100 656 R 0.3 0.1 0:11.09 top
10311 apache 20 0 387m 9496 7320 D 0.3 0.5 0:01.89 httpd
10313 apache 20 0 391m 10m 7364 D 0.3 0.5 0:02.40 httpd
10466 apache 20 0 399m 12m 7392 D 0.3 0.7 0:02.41 httpd
10599 apache 20 0 391m 9324 7340 D 0.3 0.5 0:00.15 httpd
10628 apache 20 0 384m 7620 4052 D 0.3 0.4 0:00.01 httpd
10633 apache 20 0 384m 7048 3504 D 0.3 0.3 0:00.01 httpd
10634 apache 20 0 384m 8012 4048 D 0.3 0.4 0:00.02 httpd
10638 apache 20 0 400m 22m 9.8m D 0.3 1.1 0:01.93 httpd
10640 apache 20 0 385m 8288 4028 D 0.3 0.4 0:00.03 httpd
10641 apache 20 0 401m 21m 6376 D 0.3 1.1 0:01.45 httpd
10759 apache 20 0 385m 8816 3480 D 0.3 0.4 0:01.45 httpd
10773 apache 20 0 384m 8044 3464 D 0.3 0.4 0:00.02 httpd
Это снимок iotop:
Total DISK READ: 5.93 M/s | Total DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
10732 be/4 apache 3.76 K/s 0.00 B/s 0.00 % 58.48 % httpd
876 be/3 root 0.00 B/s 52.68 K/s 0.00 % 52.98 % [jbd2/dm-1-8]
10906 be/4 root 124.17 K/s 0.00 B/s 0.00 % 23.03 % sh -c [ -x /usr/local/psa/admin/sbin/backupmng ] && /usr/local/psa/admin/sbin/backupmng >/dev/null 2>&1
2156 be/4 root 206.94 K/s 0.00 B/s 0.00 % 21.15 % bitcoind
10904 be/4 mysql 0.00 B/s 0.00 B/s 0.00 % 18.94 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
10773 be/4 apache 7.53 K/s 0.00 B/s 0.00 % 14.77 % httpd
10641 be/4 apache 15.05 K/s 0.00 B/s 0.00 % 11.57 % httpd
10399 be/4 apache 1057.29 K/s 0.00 B/s 43.16 % 10.56 % httpd
10682 be/4 sw-cp-se 158.03 K/s 0.00 B/s 0.00 % 7.45 % sw-engine-cgi -c /usr/local/psa/admin/conf/php.ini -d auto_prepend_file=auth.php3 -u psaadm
10774 be/4 apache 3.76 K/s 0.00 B/s 0.00 % 6.53 % httpd
10624 be/4 apache 0.00 B/s 0.00 B/s 0.00 % 5.53 % httpd
10356 be/4 apache 899.26 K/s 0.00 B/s 35.52 % 4.01 % httpd
10795 be/4 apache 0.00 B/s 0.00 B/s 0.00 % 3.93 % httpd
10804 be/4 apache 7.53 K/s 0.00 B/s 0.00 % 3.08 % httpd
4379 be/4 root 2.89 M/s 0.00 B/s 99.99 % 0.00 % namecoind
10619 be/4 apache 462.80 K/s 0.00 B/s 7.80 % 0.00 % httpd
10636 be/4 apache 3.76 K/s 0.00 B/s 0.00 % 0.00 % httpd
10716 be/4 mysql 105.35 K/s 0.00 B/s 5.92 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
1988 be/4 root 18.81 K/s 0.00 B/s 0.00 % 0.00 % spamd_full.sock
Я также запустил lsof -p для pid 10390, который находился наверху под командой top, и это нижняя строка, где я могу увидеть, какой это был запрос, и там написано CLOSE_WAIT:
httpd 10390 apache 34u IPv6 315879 0t0 TCP default-domain.com:https->crawl-66-249-65-91.googlebot.com:42907 (CLOSE_WAIT)
Я все еще не уверен, что именно является причиной всего этого?
Я отключил эту службу, но% wa и средняя загрузка остаются высокими, я также остановил mysqld и другие службы. Он действительно отключается только после того, как я полностью останавливаю httpd, и даже тогда я не могу запустить его, не обнаружив оставшиеся зависшие процессы httpd через "netstat -tulpn", убивая их или выполняя "killall -9 httpd" и после некоторого ожидания для этого чтобы перебрать все, что делает /etc/init.d/httpd start
Во-первых, у вас закончилась память.
Ваш VPS имеет 2 ГБ ОЗУ и 4 ГБ подкачки. 2 ГБ ОЗУ полностью израсходованы, а своп заполнен на 3/4. В этот момент в любой системе, которой я управляю, есть повторяющийся сигнал тревоги. каждые пять минут пока кто-то не признает проблему, она настолько серьезна.
Итак, вам нужно выяснить, что использует всю память. К сожалению, это может быть сложно.
Я вижу, что один процесс Apache в одиночестве использует почти 1 ГБ памяти. Это, очевидно, выброс, так как большинство других используют менее 22 МБ каждый.
Причина, по которой это сложно, заключается в том, что Apache позволяет вам встраивать такие языки, как Perl или PHP, непосредственно в процесс, и почти наверняка именно такой сценарий сбежал и съел всю вашу оперативную память.
Все, что ваша система может делать на этом этапе, - это загружать и прекращать свопинг (что именно iotop показывает это действие), пока кто-нибудь не проявит к нему милосердие с хорошо поставленным kill -9.
Итак, ваш следующий шаг - попытаться выяснить, какой сценарий вышел из строя и съел всю вашу оперативную память.
10390 apache 20 0 2774m 936m 6200 D 2.0 47.4 1:52.27 httpd
2049 root 20 0 382m 4932 2880 D 0.3 0.2 0:03.67 httpd
10311 apache 20 0 387m 9496 7320 D 0.3 0.5 0:01.89 httpd
10313 apache 20 0 391m 10m 7364 D 0.3 0.5 0:02.40 httpd
10466 apache 20 0 399m 12m 7392 D 0.3 0.7 0:02.41 httpd
10599 apache 20 0 391m 9324 7340 D 0.3 0.5 0:00.15 httpd
10628 apache 20 0 384m 7620 4052 D 0.3 0.4 0:00.01 httpd
10633 apache 20 0 384m 7048 3504 D 0.3 0.3 0:00.01 httpd
10634 apache 20 0 384m 8012 4048 D 0.3 0.4 0:00.02 httpd
10638 apache 20 0 400m 22m 9.8m D 0.3 1.1 0:01.93 httpd
10640 apache 20 0 385m 8288 4028 D 0.3 0.4 0:00.03 httpd
10641 apache 20 0 401m 21m 6376 D 0.3 1.1 0:01.45 httpd
10759 apache 20 0 385m 8816 3480 D 0.3 0.4 0:01.45 httpd
10773 apache 20 0 384m 8044 3464 D 0.3 0.4 0:00.02 httpd
Это показывает много процессов apache в состоянии D. Способ вычисления средней нагрузки linux представляет собой сумму запущенного процесса (R) + процесса в непрерывном состоянии (D)
Вы можете легко узнать об этом процессе с помощью команды top или с помощью
ps auwx | awk '$8 ~ "D"'
Итак, глядя на результат, ваша основная проблема - это ввод-вывод. Пожалуйста, выполните следующую команду во время проблемы, а затем вставьте результат для анализа
sar -u 1 10 --> look for iowait
sar -q 1 10 --> look for load avg
iowait -x 1 10 --> to get a real picture of I/O
iotop --> to see what process causing I/O and its avilable >=5.8
echo t > /proc/sysrq-trigger
blktrace --> if you want to dig more about I/O and use to see per I/O basis,I created a video related to that,hope that is helpful
https://www.youtube.com/watch?v=s0XSWbIF84I&list=PLckUzKjgYDgajJVYOjNztS6Q4SOho0RKY&index=7
Чтобы добавить, вы не можете убить процесс состояния D, состояние D 'не будет реагировать на сигналы в случае процессов в непрерывном сне, любые сигналы, отправленные, когда задача заблокирована, будут доставлены процессу, как только он вернется в любой из Состояние «R» или «S» (обычно после завершения ввода-вывода или другой активности ядра).
Эксперт из вики
An uninterruptible sleep state is a sleep state that won't handle a signal right away. It
will wake only as a result of a waited-upon resource becoming available or after a time-
out occurs during that wait (if specified when put to sleep). It is mostly used by device
drivers waiting for disk or network IO (input/output). When the process is sleeping
uninterruptibly, signals accumulated during the sleep will be noticed when the process
returns from the system call or trap.