Форум русскоязычного сообщества Ubuntu


Получить помощь и пообщаться с другими пользователями Ubuntu можно
на irc канале #ubuntu-ru в сети Freenode
и в Jabber конференции ubuntu@conference.jabber.ru

Автор Тема: Апач неожиданно перестаёт отвечать на запросы  (Прочитано 2014 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн @enchanter

  • Автор темы
  • Новичок
  • *
  • Сообщений: 41
    • Просмотр профиля
Доброго дня!
Имеется такой VirtualHost:
Код: XML
  1. <VirtualHost ${HOST}:443>
  2.     ServerName mysite.ru
  3.     WSGIDaemonProcess myproc user=www-data group=www-data threads=15 processes=10 shutdown-timeout=30
  4.     WSGIProcessGroup myproc
  5.     WSGIApplicationGroup %{GLOBAL}
  6.     WSGIScriptAlias / /var/www/site/data/site.wsgi
  7.     WSGICallableObject app
  8.     WSGIScriptReloading On
  9.     <Directory /var/www/site/data>
  10.         Order deny,allow
  11.         Allow from all
  12.     </Directory>
  13.  
  14.  
  15.     ErrorLog /var/log/apache2/site_error.log
  16.     LogLevel info
  17.     CustomLog /var/log/apache2/site_access.log combined
  18.  
  19.     SSLEngine on
  20.     SSLCertificateFile    /etc/apache2/ssl/site.crt
  21.     SSLCertificateKeyFile /etc/apache2/ssl/site.key
  22.  
  23.     BrowserMatch ".*MSIE.*" \
  24.         nokeepalive ssl-unclean-shutdown \
  25.         downgrade-1.0 force-response-1.0
  26.  
  27. </VirtualHost>
  28.  

Всё работает, но..
В процессе работы Апач вдруг перестаёт отвечать на запросы на этот виртуалхост. У пользователя в браузере это выглядит зависанием (Ожидание ответа от site.ru...), причём продолжительным, потом - ошибка.
При этом другие сайты на этом сервере работают, им апач отвечает, не отвечает только wsgi-приложению (python, mod_wsgi)
Приходится делать рестарт апача.

Никак не могу понять, в чём причина. Сообщения в логах апача не наводят ни на какие мысли. Из всего, что там есть незаконного, могу выделить только сообщения типа:
Код: XML
  1. Script timed out before returning headers: site.wsgi
  2. SSL library error 1 in handshake (server mysite.ru:443)
  3. SSL Library Error: 336027900 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol speaking not SSL to HTTPS port!?
  4.  
Причём эти сообщения по времени не совпадают с временем отказа.
Похожая тема  - не новость, например одна из ссылок http://stackoverflow.com/questions/21468345/apache-suddenly-stopped-serving-requests-mod-wsgi
Где копать?

Оффлайн vboxer

  • Активист
  • *
  • Сообщений: 656
  • Release: 14.10 Codename: utopic
    • Просмотр профиля
@enchanter,
Цитировать
Сообщения в логах апача не наводят ни на какие мысли.
если сервер на ващем локальном компе, то логи апача рыть ну совсем мало. Есть смысл обратить внимания на логи системы.Есть есть роутер, на логи роутера, если задействованы базы, то логи мускула или что у вас там? Думаю самое элементарное - инет валится. Не самое элементарное утечки от какого нибудь скрипта.

Оффлайн @enchanter

  • Автор темы
  • Новичок
  • *
  • Сообщений: 41
    • Просмотр профиля
@enchanter
если сервер на ващем локальном компе, то логи апача рыть ну совсем мало. Есть смысл обратить внимания на логи системы.Есть есть роутер, на логи роутера, если задействованы базы, то логи мускула или что у вас там? Думаю самое элементарное - инет валится. Не самое элементарное утечки от какого нибудь скрипта.
Сервер стоит в датацентре. В syslog нет ничего, связанного с этой проблемой. В логах postgresql тоже не нашёл никаких зацепок. Инет не может валиться по очевидной причине: как я отметил выше, во время зависания wsgi-приложения другие виртуалхосты апач обслуживает, и выдаёт на запросы ответы. Т.е. именно site.ru не отвечает.
С клиента:
nslookup site.ru
tracepath site.ru
wget -O- site.ru
Это вряд ли покажет что-то пригодное для анализа, но попробую.. уже готов по стеклу пинать и колёса протирать..

Оффлайн .ubuntufan

  • Активист
  • *
  • Сообщений: 638
    • Просмотр профиля
« Последнее редактирование: 13 Ноябрь 2014, 02:38:04 от .ubuntufan »

Оффлайн @enchanter

  • Автор темы
  • Новичок
  • *
  • Сообщений: 41
    • Просмотр профиля
modwsgi Debugging Techniques
Tracing a Program As It Runs
Я к этому материалу уже обращался, только не могу себе представить, как с помощью предложенных методик провести поиск причины такого поведения апача. Одно дело, когда программа совсем не работает - включил строки отладки и иди до глюка. Другое дело, когда это случается неожиданно, может пройти пару недель между такими висяками. И где именно ставить точки отладки - объём кода огромный! И судя по всему, это вообще не ошибка как таковая, потому что обычно ошибки порождают сообщения в логах. А в логах ошибок нет. Была мысль про deadlock, но подтверждения не нашёл. И да - эта проблема случается не только у меня, я нашел в сети несколько абсолютно аналогичных случаев, и нигде не нашёл решений.

Оффлайн .ubuntufan

  • Активист
  • *
  • Сообщений: 638
    • Просмотр профиля
Цитировать
Была мысль про deadlock, но подтверждения не нашёл.

А каким образом проверял?
Возможно и дедлок, параметр deadlock-timeout даже позволяет это время контролировать:

Цитировать
deadlock-timeout=sss (2.0+)

Defines the maximum number of seconds allowed to pass before the daemon process is shutdown and restarted after a potential deadlock on the Python GIL has been detected. The default is 300 seconds.
This option exists to combat the problem of a daemon process freezing as the result of a rouge Python C extension module which doesn't properly release the Python GIL when entering into a blocking or long running operation.

https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess

Еще ссылка полезная:
http://code.activestate.com/recipes/577334-how-to-debug-deadlocked-multi-threaded-programs/
« Последнее редактирование: 13 Ноябрь 2014, 09:58:33 от .ubuntufan »

Оффлайн @enchanter

  • Автор темы
  • Новичок
  • *
  • Сообщений: 41
    • Просмотр профиля
Цитировать
Была мысль про deadlock, но подтверждения не нашёл.

А каким образом проверял?
Возможно и дедлок, параметр deadlock-timeout даже позволяет это время контролировать:
Проверял просто - искал знакомое слово в логах ))) Другого способа не знаю..
А мысль здравая, спасибо! Попробую установить это параметр и понаблюдаю.
Кстати, сказано в указанном писании "... after a potential deadlock on the Python GIL has been detected..." По логике, если апач обнаружил potential deadlock, он и в логах должен сообщить об этом. А в логах ни слова. Возможно, он и не будет реагировать на deadlock-timeout.
« Последнее редактирование: 13 Ноябрь 2014, 13:58:59 от @enchanter »

 

Страница сгенерирована за 0.13 секунд. Запросов: 24.