Приложение My Flask регулярно возвращает ошибку 503. Я не могу сказать причину. Может быть связано с нагрузкой. Это не систематически, так что это не проблема с правами доступа к файлам. Это больше похоже на 5 раз на 10 последующих запросов. Легко воспроизвести с помощью F5 в браузере.
Я хотел бы отладить это, но я ничего не могу найти в журналах.
Я проверил основные файлы журнала apache (доступ/ошибка) и файлы журнала доступа/ошибки VirtualHost. Я пытался установить LogLevel для отладки, но безрезультатно.
Когда приложение возвращает 503 (например, используя abort(503) с Flask), ошибка регистрируется в журнале доступа к виртуальному хосту (это не ошибка apache, поэтому она заносится в журнал доступа). Он также регистрируется в моем журнале приложений, потому что моя структура регистрирует все ошибки http.
В прошлом у меня были проблемы с загрузкой, когда ни один поток не был доступен. Это привело к 503 ошибкам, возвращенным самим apache, и я почти уверен, что они были зарегистрированы либо в журнале доступа, либо в журнале ошибок (скорее всего, ошибка).
Как это возможно, что клиент получает ошибку 503, а в журналах нет никаких следов?
Выдержка из конфигурации виртуального хоста:
ErrorLog ${APACHE_LOG_DIR}/my-app-error.log
CustomLog ${APACHE_LOG_DIR}/my-app-access.log combined
WSGIDaemonProcess my-app threads=5
WSGIScriptAlias /api /srv/my-app/application.wsgi process-group=my-app application-group=%{GLOBAL}
WSGIPassAuthorization On
<Location /api>
WSGIProcessGroup my-app
</Location>
<Directory /srv/my-app/>
Options FollowSymLinks
AllowOverride All
</Directory>
Debian Stretch, апач 2.4.25, mod_wsgi 4.5.11.
Редактировать 1: затронуты все приложения WSGi
Мы заметили ошибку 503 в другом приложении wsgi на другом виртуальном хосте в том же экземпляре apache. Это приложение находится под небольшой (близкой к нулю) нагрузкой, поэтому оно не должно 503. Однако я не получаю 503 при загрузке страницы VHost по умолчанию (страница «Apache2 Debian по умолчанию» «Это работает!» Страница) . Например, если бы существовало какое-то ограничение mod_wsgi, которое было бы общим для всех приложений WSGI, но не было бы глобальным ограничением Apache, поскольку оно затрагивает только приложения WSGI.
Изменить 2: перезапуск apache
systemctl reload apache2 ничего не меняет. Тем не менее, systemctl restart apache2 решил это на данный момент. До скорого.
Перед перезапуском
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-12-04 11:13:23 CET; 2 weeks 0 days ago
Process: 10023 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
Process: 536 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
Main PID: 977 (apache2)
Tasks: 133 (limit: 4915)
Memory: 1.7G
CPU: 6d 6h 3min 51.105s
CGroup: /system.slice/apache2.service
├─ 977 /usr/sbin/apache2 -k start
├─10066 /usr/sbin/apache2 -k start
├─10067 /usr/sbin/apache2 -k start
├─10068 /usr/sbin/apache2 -k start
├─10069 /usr/sbin/apache2 -k start
├─16834 /usr/sbin/apache2 -k start
└─16836 /usr/sbin/apache2 -k start
После перезагрузки
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2018-12-19 12:32:02 CET; 3s ago
Process: 11840 ExecStop=/usr/sbin/apachectl stop (code=exited, status=0/SUCCESS)
Process: 11735 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
Process: 11850 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
Main PID: 11854 (apache2)
Tasks: 79 (limit: 4915)
Memory: 125.3M
CPU: 4.080s
CGroup: /system.slice/apache2.service
├─11854 /usr/sbin/apache2 -k start
├─11855 /usr/sbin/apache2 -k start
├─11856 /usr/sbin/apache2 -k start
├─11857 /usr/sbin/apache2 -k start
└─11858 /usr/sbin/apache2 -k start
Различия, которые я вижу здесь, - это количество процессов (не знаю, что об этом сказать) и использование памяти. Хорошо, приложение немного жадничает с памятью, но я думаю, что сервер справится с этим.
