Назад | Перейти на главную страницу

mod_fcgid: ошибки тайм-аута чтения данных

Я перешел на неуправляемый сервер, который использует fcgid (до того, как я использовал mod_php), и в журналах ошибок я вижу множество таких ошибок:

[Пн 23 апр, 21:17:12 2012] [предупредить] [клиент 66.249.68.233] mod_fcgid: тайм-аут чтения данных через 31 секунду [Пн 23 апр, 21:17:12 2012] [ошибка] [клиент 66.249.68.233] Преждевременное завершение заголовков скрипта: index.php

[Пн 23 апр, 17:59:51 2012] [предупредить] [клиент 74.117.180.58] mod_fcgid: таймаут чтения данных через 31 секунду [Пн 23 апр, 17:59:51 2012] [предупредить] [клиент 74.117.180.58] (110 ) Тайм-аут соединения: mod_fcgid: ap_pass_brigade не удалось в функции handle_request_ipc

Кажется, их больше, когда нагрузка выше (2-3) во время резервного копирования, и мне даже удалось воспроизвести это во время загрузки 3, когда tar / mysqldump работал во время резервного копирования (пользователь видит сообщение об ошибке 500 после 30 секунд). Мог ли сервер быть перегружен? Этот вопрос кажется связанным PHP + Fcgid зависает, если загрузка прервана но не то же самое.

Это первоклассный сервер, и я удивлен, что этого будет слишком много. Вот некоторые характеристики: 6-7 сайтов Drupal с Webmin

Эти ошибки означают, что скрипты выполнялись дольше 31 секунды и, следовательно, они были прерваны, как говорит ваш fcgid.conf. Стандартный тайм-аут составляет 40 секунд, кстати.

Вы можете легко проверить это поведение, написав test.php:

<?php sleep(32); ?>

Это должно дать вам ошибку 500 и записать эту ошибку в ваши журналы.

У вас есть две возможности решить эту проблему:

  1. Пересоздайте свой index.php (или приложение, стоящее за ним) и решите потенциальные проблемы с циклом (где скрипт работает вечно и завершается через 31 секунду).
  2. Увеличьте время ожидания. Это необходимо сделать для каждого виртуального хоста (не забывайте SSL!), Поскольку этот параметр изменяется каждый раз, когда загружается другой виртуальный хост, и будет оставаться до тех пор, пока порожденный процесс не умрет.
    Самый простой способ - отредактировать /etc/apache2/mods-available/fcgid.conf. Вот что мы используем:

    IdleTimeout 3600
    ProcessLifeTime 7200
    IPCConnectTimeout 8
    IPCCommTimeout 600
    BusyTimeout 300

Изменить: о, вторая ошибка связана с слишком длинными строками запроса в URL-адресах. Чтобы разрешить более длинные строки запроса, также отредактируйте fcgid.conf и вставить

MaxRequestLen 15728640

Не забудьте перезапустить apache, чтобы убить все запущенные процессы, чтобы они получили новые конфигурации.

mysqldump по умолчанию блокирует запись базы данных во время ее работы, чтобы данные не изменялись во время резервного копирования, что может вызвать повреждение. Drupal записывает в базу данных при каждом запросе, поэтому запросы будут зависать во время работы mysqldump и, в конечном итоге, по истечении времени ожидания.

Если вы используете InnoDB (или можете конвертировать в него), вы можете использовать Percona XtraBackup делать горячие резервные копии. Если не считать этого, не передавайте mysqldump в tar или gzip; выгрузите файл .sql, а затем запустите на нем tar / gzip после завершения mysqldump (и снятия блокировки).

Также имейте в виду, что в некоторых версиях fcgid есть ошибка, из-за которой он применять настройки только в блоках VirtualHost и применять их в блоке последнего чтения глобально.