ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[apache-talk] apache & solaris@i386 hangs




Приветствую.

Есть следующая проблема:

Есть двухпроцессорный 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 | http://rotabanner.com



 




Copyright © Lexa Software, 1996-2009.