Приветствую.
Есть следующая проблема:
Есть двухпроцессорный i386 сервер с солярисом:
$ psrinfo -v
Status of processor 0 as of: 02/13/03 16:33:52
Processor has been on-line since 02/13/03 15:38:37.
The i386 processor operates at 1341 MHz,
and has an i387 compatible floating point processor.
Status of processor 1 as of: 02/13/03 16:33:52
Processor has been on-line since 02/13/03 15:38:39.
The i386 processor operates at 1341 MHz,
and has an i387 compatible floating point processor.
$ uname -a
SunOS ******.ru 5.8 Generic_108529-18 i86pc i386 i86pc
рута от этой машины у меня нет, админ говорит, что все рекомедованные патчи
установлены
Также выполнены рекомедации по тюнингу сетевой подсистемы.
Стоит апач, который по его статистике обрабатывает около 130 запросов в
секунду:
$ /usr/local/apache/bin/apachectl status
Apache Server Status for localhost
Server Version: Apache/1.3.26 (Unix) rus/PL30.15
Server Built: Oct 14 2002 17:21:46
_________________________________________________________________
Current Time: Thursday, 13-Feb-2003 16:25:44 MSK
Restart Time: Thursday, 13-Feb-2003 16:24:03 MSK
Parent Server Generation: 13
Server uptime: 1 minute 41 seconds
Total accesses: 12973 - Total Traffic: 77.0 MB
CPU Usage: u1.07 s1.42 cu.07 cs.1 - 2.63% CPU load
128 requests/sec - 0.8 MB/second - 6.1 kB/request
13 requests currently being processed, 12 idle servers
В апач для ускорения вкомплилрован самодельный модуль, который при каждом
запросе открывает локальное tcp-соединение к постоянно запущенному демону.
Для предотвращения возможных зависаний на обработку запроса установлен
таймаут через alarm(). апач и демон занайсены в 19.
В нормальных условиях la на сервере порядка 0.5,
CPU states: 75.5% idle, 5.9% user, 18.6% kernel, 0.0% iowait, 0.0% swap
Испытывался также вариант с cgi-скриптом вместо модуля и стандартным апачем
(за счет постоянного дерганья скрипта с диска нагрузка больше, но жить
можно) с такими же результатами.
Регулярно (от 1 до 10 раз в день) нагрузка на cpu резко возрастает. top при
этом показывает, что 99% cpu ест ядро, из процессов основным потребителем
cpu явдяется один или два httpd, которые не хотят убиваться даже через kill
-9. Если прицепиться к ним gdb, то это выглядит примерно так:
0xdfa2b0be in _write () from /usr/lib/libc.so.1
#0 0xdfa2b0be in _write () from /usr/lib/libc.so.1
#1 0xdf9a7b50 in write () from /usr/lib/libthread.so.1
#2 0x80699a7 in buff_write ()
#3 0x8068e08 in write_with_errors ()
#4 0x806949a in bflush_core ()
#5 0x8069583 in ap_bflush ()
#6 0x8068436 in ap_bhalfduplex ()
#7 0x808186f in ap_process_request ()
#8 0x8076ba3 in child_main ()
#9 0x8076e30 in make_child ()
#10 0x80771b8 in perform_idle_server_maintenance ()
#11 0x8077745 in standalone_main ()
#12 0x8077d98 in main ()
#13 0x805bb97 in _start ()
Т.е. апач вызвал write() с ответом клиенту.
Если не принимать никаких мер, то система довольно быстро впадает в ступор и
перестает отвечать на внешние раздражители. Для предотвращения повисания
был написан скрипт, которые пытается прибить апач и если ситуация не
выправляется, то прегружает сервер (что как правило происходит успешно).
Проблема заметно усугубляется, если повысить число запросов (есть еще второй
такой с такими же проблемами и с него можно забрать нагрузку). Интенсивные
тесты через ab проблему не вызывают (по крайней мере мне не удалось).
Иногда проблема возникает сразу же после загрузки сервера (лицезрел при
uptime 1 min).
Нашел в архиве чем-то схожую ситуацию (многопроцессорная машина, проблема
пропадала при выключении всех процессоров кроме одного), но там был старый
солярис (2.5.1) и рекомедовалось его проапгрейдить по причине глюков в
реализации tcp-стека в солярисе, который позднее были вылечены.
Хотелось бы получить практических советов что делать и как понять в чем
проблема. Я бы давно поменял solaris на freebsd, но такова воля заказчика.
--
Vladimir Eltchinov
__________________________________________________________________________
Senior Developer, RotaBanner | elik@rotabanner.com |
