Это загруженный веб-сервер под управлением Apache 2.4. Недавно мы заметили несколько кратковременных отключений, когда сервер отключает входящие запросы на короткий период времени (менее минуты). Глядя на журнал ошибок Apache, можно увидеть несколько случаев этой ошибки, связанных с каждым отключением:
[Thu Dec 19 12:37:21.104416 2019] [http2:info] [pid 10827:tid 46937350948608] [client <ip address>:62355] h2_stream(209-285,HALF_CLOSED_REMOTE): redo, added to q
Где всегда один и тот же адрес, не в нашей организации. В частности, мы сразу получаем этот пакет ошибок в журнале после серия таймаутов запроса.
Итак, каким-то образом этот IP-адрес попадает на наш сервер с серией запросов, которые вызывают эту ошибку, и это каким-то образом мешает серверу отвечать на другие, не связанные запросы с других IP-адресов. Сюда входят запросы curl, отправляемые от сервера к самому себе, и именно из-за сбоев мы это заметили. (Это вызовы API между нашими отдельными веб-сайтами, которые в настоящее время работают на одном сервере.)
Например, совсем недавно у нас было время ожидания ряда запросов API между 20:36:35 и 20:37:16 UTC. (Они находятся в 10-секундном тайм-ауте, так как обычно они возвращаются почти мгновенно, поэтому первые запросы с тайм-аутом начались в 20:36:25.) Затем мы получили 2 копии вышеуказанной ошибки в журнале ошибок в 20:37:06, и затем 76 копий с отметками времени от 20:37:16 до 20:37:29.
76 запросов недостаточно для использования любого известного мне ресурса, такого как потоки Apache или TCP-соединения. И, очевидно, ошибка каким-то образом связана с http2 - может быть, какой-то ресурс согласования SSL, который обычно используется очень кратковременно, и поэтому небольшое количество экземпляров может нормально обрабатывать наш уровень трафика? Но очевидно, что это обнажает уязвимость в нашей настройке, если один IP-адрес может эффективно DOS нашего сервера с таким небольшим трафиком.
Итак, у меня следующие вопросы: что означает эта ошибка, есть ли параметр конфигурации, который я могу увеличить, чтобы смягчить то, что кажется относительно низким пределом, и как мы можем предотвратить эффективную обработку IP-адресом нашего сервера с помощью таких запросов?
Оказывается, это произошло из-за создания динамического процесса PHP-FPM. Во время быстрых всплесков трафика на сервер, которые требовали запуска дополнительных процессов PHP-FPM, он тормозил, запуская новые процессы и отбрасывая запросы. Изменение конфигурации пула PHP-FPM с динамической на статическую решило проблему (за счет несколько более высокого использования памяти в режиме ожидания, поскольку каждый неактивный процесс PHP-FPM использует около 500 КБ). В качестве альтернативы мы могли бы решить проблему, значительно увеличив минимальное количество резервных серверов, но решили, что это того не стоит из-за небольшого объема сохраненной памяти.