У нас есть КУЧА распределенных клиентов, которые, помимо прочего, загружают файлы журналов на наш сервер Apache.
Мы испортили ротацию журналов в некоторых журналах, поэтому теперь мы загружаем относительно большие файлы с этих клиентов много раз в день. Очевидно, исправление состоит в том, чтобы заставить работать ротацию журналов и дать клиентам больше информации, чтобы они перестали это делать. Доставка ЛЮБОГО изменения к клиентам займет дни, возможно, неделю или две.
Тем временем наши 3 T1 на 100% загружены этими загрузками, и время ожидания многих жизненно важных соединений (гораздо более важных, чем загрузка журналов) истекло.
Выгрузка журнала обрабатывается скриптом Python, работающим под управлением mod-wsgi, и мы попытались заставить его (через скрипт Python) немедленно отправить 200 успехов. Это не работает - curl (то, что мы используем для загрузки) сообщит 200 и сломанный канал через 30 секунд, но он все еще загружается в течение этих 30 секунд.
Есть предложения, что мы можем с этим сделать? На самом деле нам все равно, если мы потеряем файлы журналов, но мы действительно хотим, чтобы жизненно важный трафик проходил через них.
Почему бы вам не попробовать другой способ без apache, например iptables. если это соответствует вашим потребностям.
вот хорошее начало.
Резак: http://www.lowth.com/cutter/
Apache или клиент не остановят точную секунду. Потому что связи уже установлены. даже если вы перезапустите apache. или заблокируйте порт 80 для мест загрузки. он будет ждать до конца тайм-аута.
но с резаком вы можете убить соединение в определенную секунду. что даст вам достаточную пропускную способность / ресурсы в течение необходимого вам времени. сократите свой конн. таймауты в конфигурации apache для экономии памяти и мертвых / зомби-потомков apache. затем используйте резак, чтобы убить ненужные загрузки.
Можно ли изменить свой DNS так, чтобы он указывал на сервер (или ферму серверов с балансировкой нагрузки), который может справиться с нагрузкой, и / или сервер с улучшенным сетевым подключением, чтобы у вас не было узких мест в 3 T-1?
Если клиенты подключаются к IP-адресу, а не к DNS-имени, говорили ли вы со своим вышестоящим провайдером (-ами) об изменении вашей маршрутизации, чтобы рассматриваемый IP-адрес направлялся на серверное пространство на месте у вашего провайдера или поблизости в коло объект?
Отправка HTTP-ответа - это хорошо, но на самом деле вам нужно закрыть соединение. Я не знаю mod_wsgi близко, но в mod_php, например, простой:
exit(0);
вверху скрипт работает как шарм. Вы по-прежнему (потенциально) читаете байты размером входного буфера перед вызовом скрипта, но обычно это не проблема.
Другая альтернатива, поскольку вы используете Apache, - это блокировать вещи на более высоком уровне; добавьте новую строку GET для обновленных клиентов, а затем добавьте конфигурацию, например:
RewriteEngine on
RewriteCond %{QUERY_STRING} !.*isNotBraindead=1.*
RewriteRule path/to/python/script.py - [F,L]
В конфигурации Apache временно добавьте:
<Location /some/url/to/upload/handler>
Deny from all
</Location>
По сути, запретить доступ к URL-адресу, используемому для обработчика загрузки.
Это предполагает, что полный URL-путь для обработчика загрузки не используется ни для чего другого.
Поскольку возвращается ошибка, то есть статус не 200, Apache немедленно разрывает соединение.
В соответствии с другим предложением, существует ли конкретное имя DNS, которое разрешается для загрузки данных? Вы можете попробовать просто выдернуть запись A, если она не используется ни для чего другого.
Не уверен, каковы ваши сетевые возможности, но вы также могли бы подумать, можете ли вы развернуть ACL вверх по течению от вас, чтобы заблокировать клиентский трафик (при условии, что передача этих данных журнала - единственное, для чего они обращаются к вам). Вы также можете использовать что-то вроде NBAR, чтобы отбросить трафик, направленный на URL-адрес загрузки. Эти методы могут сохранить ограниченную полосу пропускания на ваших линиях T, но неясно, есть ли у вас такой уровень доступа к сети.
Я немного удивлен вашим комментарием о том, что клиенты загружают несколько раз в день, но вы все равно получаете наводнение после того, как вы немедленно выходите / возвращаете 200 из-за ~ 30 секунд передачи.
Я бы посмотрел на замедление трафика на маршрутизаторе и позволил протоколу TCP / IP снизить скорость. Например, вы можете использовать tc установить ограничение на скорость подключений ваших клиентских серверов к порту 80 сервера журналов. Если вы ограничите общую скорость, доступную для всех этих клиентов, скажем, половиной вашей доступной полосы пропускания, вы все равно сможете использовать соединения для остального трафика.
Если tc недоступен или не подходит, посмотрите на любой другой инструмент для обеспечения качества обслуживания (QoS), который должен предоставлять возможность ограничивать полосу пропускания, доступную для определенных вопросов.
Я согласен с другими, что дросселирование полосы пропускания - это ответ (НЕ QoS-маршрутизация - потому что служба всегда HTTP - вы просто хотите, чтобы некоторые клиенты работали медленнее).
Потенциально вы могли бы это сделать с помощью обратного прокси (описана настройка squid Вот), с помощью iptables или с одним из множества модулей регулирования для Apache (поиск Вот для пропускной способности и версии вашего веб-сервера).
Вероятно, вы можете выполнить iptables без каких-либо перезагрузок / аппаратных / программных изменений, но модуль apache даст вам очень точный контроль над тем, какие клинеты / URL-адреса применять дросселирование - хотя я не уверен, сколько из них действительно работает с загрузками.
HTH
С.