Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Anton Gorlov]

29.10.2015 23:46, Vitaly Lipatov пишет:

> А ограничение по MaxClientsVhost сразу возвращает 503 при достижении
> предела подключений. Что вовсе не желательно, потому
> что для клиента выглядит как то, что сайт работает быстро, но иногда
> вместо страницы — ошибка.
> Может быть есть всем известное решение, которое я не знаю?

Сам сейчас хожу по тем же граблям. Пока пришёл к выводу что лимитировать
коннекты к сайту лучше средствами nginx через
limit_req_zone $host и limit_req...

[Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Vitaly Lipatov]

Задача следующая: нужно ограничить количество процессов Apache, которые 
запускаются для каждого
пользователя (ITK позволяет разных пользователей, под которыми 
запускается процесс Apache), а ещё лучше —
для каждого виртуального хоста.

Базовая настройка к примеру такая:
<IfModule itk.c>
<------>StartServers          1
<------>MinSpareServers       4
<------>MaxSpareServers       20
<------>MaxClients            20
<------>MaxRequestsPerChild   15000

Но MaxClients задаёт ограничение на количество процессов, общее для 
всех пользователей и хостов.

Есть параметр MaxClientsVhost, который можно указывать в конфиге сайта. 
Но между ними большое отличие в поведении:
При превышении MaxClients Apache просто не реагирует на коннекты к 
нему, таким образом накапливается очередь подключений,
и пользователи при перегрузке испытывают замедление реакции сайта.

А ограничение по MaxClientsVhost сразу возвращает 503 при достижении 
предела подключений. Что вовсе не желательно, потому
что для клиента выглядит как то, что сайт работает быстро, но иногда 
вместо страницы — ошибка.

Может быть есть всем известное решение, которое я не знаю?

Другой вариант — это научить nginx ошибку 503 не передавать клиенту, а 
ждать и пытаться получить от бэкенда более корректный ответ.

-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Konstantin Lepikhov]

Hi Vitaly!

On 10/29/15, at 11:46:00 PM you wrote:

> Задача следующая: нужно ограничить количество процессов Apache, которые 
> запускаются для каждого
> пользователя (ITK позволяет разных пользователей, под которыми 
> запускается процесс Apache), а ещё лучше —
> для каждого виртуального хоста.
> 
> Базовая настройка к примеру такая:
> <IfModule itk.c>
> <------>StartServers          1
> <------>MinSpareServers       4
> <------>MaxSpareServers       20
> <------>MaxClients            20
> <------>MaxRequestsPerChild   15000
> 
> Но MaxClients задаёт ограничение на количество процессов, общее для 
> всех пользователей и хостов.
> 
> Есть параметр MaxClientsVhost, который можно указывать в конфиге сайта. 
> Но между ними большое отличие в поведении:
> При превышении MaxClients Apache просто не реагирует на коннекты к 
> нему, таким образом накапливается очередь подключений,
> и пользователи при перегрузке испытывают замедление реакции сайта.
А цель какая? Ограничить кол-во подключений или кол-во процессов? Если
подключения, то да, limit_req в nginx для каждого vhost'а, если процессы,
то крутить cgroups.

> 
> А ограничение по MaxClientsVhost сразу возвращает 503 при достижении 
> предела подключений. Что вовсе не желательно, потому
> что для клиента выглядит как то, что сайт работает быстро, но иногда 
> вместо страницы — ошибка.
> 
> Может быть есть всем известное решение, которое я не знаю?
> 
> Другой вариант — это научить nginx ошибку 503 не передавать клиенту, а 
> ждать и пытаться получить от бэкенда более корректный ответ.
в этом случае nginx должен что-то ответить клиенту вместо 503 (поскольку
"ждать" он не умеет), что тоже не есть гуд.

-- 
WBR et al.

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Vitaly Lipatov]

Konstantin Lepikhov писал 2015-10-30 2:09:
...
>> Но MaxClients задаёт ограничение на количество процессов, общее для
>> всех пользователей и хостов.
>>
>> Есть параметр MaxClientsVhost, который можно указывать в конфиге 
>> сайта.
>> Но между ними большое отличие в поведении:
>> При превышении MaxClients Apache просто не реагирует на коннекты к
>> нему, таким образом накапливается очередь подключений,
>> и пользователи при перегрузке испытывают замедление реакции сайта.
> А цель какая? Ограничить кол-во подключений или кол-во процессов? 
> Если
> подключения, то да, limit_req в nginx для каждого vhost'а, если 
> процессы,
> то крутить cgroups.
Цель — ограничить количество одновременных процессов, обрабатывающих 
запросы к конкретному сайту.
limit_req даёт возможность ограничить количество обращений в секунду, и 
таким образом
может защитить от внешнего врага. Мне же нужно защититься от врага 
внутреннего.
Если сайт вместо 200мс начнёт отвечать за 10с (не важно по каким 
причинам), всё не должно рухнуть от
количества процессов апача и не должны пострадать соседи по апачу 
(другие сайты).
А cgroups будет давать ошибку при форке? И помешает другим процессам 
под этим же UID.

>> А ограничение по MaxClientsVhost сразу возвращает 503 при достижении
>> предела подключений. Что вовсе не желательно, потому
>> что для клиента выглядит как то, что сайт работает быстро, но иногда
>> вместо страницы — ошибка.
>>
>> Может быть есть всем известное решение, которое я не знаю?
>>
>> Другой вариант — это научить nginx ошибку 503 не передавать клиенту, 
>> а
>> ждать и пытаться получить от бэкенда более корректный ответ.
> в этом случае nginx должен что-то ответить клиенту вместо 503 
> (поскольку
> "ждать" он не умеет), что тоже не есть гуд.
Ну умеет же nginx proxy_next_upstream, и ждать он может, если ему не 
отвечать (при достижении ограничения через MaxClients).

Я для себя пока сделал вывод, что либо MaxClientsVHost должен уметь 
переводить запрос в очередь, как это делается при достижении MaxClients,
либо nginx должен уметь ждать и делать повторы. Он умеет это при 
нескольких upstream (там есть и timeout и количество попыток и код 
ошибки 503 понимает).
Видимо, это либо платная функциональность (в nginx Plus есть слово 
queue), либо достижима через расширение.


-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Konstantin Lepikhov]

Hi Vitaly!

On 10/30/15, at 11:37:49 AM you wrote:

> Konstantin Lepikhov писал 2015-10-30 2:09:
> ...
> >> Но MaxClients задаёт ограничение на количество процессов, общее для
> >> всех пользователей и хостов.
> >>
> >> Есть параметр MaxClientsVhost, который можно указывать в конфиге 
> >> сайта.
> >> Но между ними большое отличие в поведении:
> >> При превышении MaxClients Apache просто не реагирует на коннекты к
> >> нему, таким образом накапливается очередь подключений,
> >> и пользователи при перегрузке испытывают замедление реакции сайта.
> > А цель какая? Ограничить кол-во подключений или кол-во процессов? 
> > Если
> > подключения, то да, limit_req в nginx для каждого vhost'а, если 
> > процессы,
> > то крутить cgroups.
> Цель — ограничить количество одновременных процессов, обрабатывающих 
> запросы к конкретному сайту.
> limit_req даёт возможность ограничить количество обращений в секунду, и 
> таким образом
> может защитить от внешнего врага. Мне же нужно защититься от врага 
> внутреннего.
> Если сайт вместо 200мс начнёт отвечать за 10с (не важно по каким 
> причинам), всё не должно рухнуть от
> количества процессов апача и не должны пострадать соседи по апачу 
> (другие сайты).
> А cgroups будет давать ошибку при форке? И помешает другим процессам 
> под этим же UID.
Был какой-то патч для cgroups, который как раз ограничивал кол-во форков,
но его надо допиливать под текущие ядра, мне предлагали это сделать под
wks ядра, но у меня нет времени и желания этим заниматься.

https://lists.unsafe.ru/pipermail/kernels/2013-September/000382.html

> 
> >> А ограничение по MaxClientsVhost сразу возвращает 503 при достижении
> >> предела подключений. Что вовсе не желательно, потому
> >> что для клиента выглядит как то, что сайт работает быстро, но иногда
> >> вместо страницы — ошибка.
> >>
> >> Может быть есть всем известное решение, которое я не знаю?
> >>
> >> Другой вариант — это научить nginx ошибку 503 не передавать клиенту, 
> >> а
> >> ждать и пытаться получить от бэкенда более корректный ответ.
> > в этом случае nginx должен что-то ответить клиенту вместо 503 
> > (поскольку
> > "ждать" он не умеет), что тоже не есть гуд.
> Ну умеет же nginx proxy_next_upstream, и ждать он может, если ему не 
> отвечать (при достижении ограничения через MaxClients).
> 
> Я для себя пока сделал вывод, что либо MaxClientsVHost должен уметь 
> переводить запрос в очередь, как это делается при достижении MaxClients,
> либо nginx должен уметь ждать и делать повторы. Он умеет это при 
> нескольких upstream (там есть и timeout и количество попыток и код 
> ошибки 503 понимает).
> Видимо, это либо платная функциональность (в nginx Plus есть слово 
> queue), либо достижима через расширение.
у nginx есть proxy_limit_rate и встроенный perl, через который
можно сделать обработку 503 и таймаутов. _limit_rate поможет не отдавать
данные быстро, что позволит не понижать время ответа.

-- 
WBR et al.

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Anton Gorlov]

Кстати вот ещё интересная вещь
http://habrahabr.ru/post/269835/

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Anton Gorlov]

02.11.2015 17:15, Sergey Alembekov пишет:
> от этого может помоч ограничение nproc в  /etc/security/limits.conf 
Если только в мечтах.

apache-itk воркеры работают от рута и потом делают переключение на
нужного юзера и наследуют лимиты от исходного юзера

Как вариант https://github.com/MatthewIfe/mod_cgroup

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Sergey Alembekov]

On 30.10.2015 11:37, Vitaly Lipatov wrote:
> Konstantin Lepikhov писал 2015-10-30 2:09:
> ...
>>> Но MaxClients задаёт ограничение на количество процессов, общее для
>>> всех пользователей и хостов.
>>>
>>> Есть параметр MaxClientsVhost, который можно указывать в конфиге сайта.
>>> Но между ними большое отличие в поведении:
>>> При превышении MaxClients Apache просто не реагирует на коннекты к
>>> нему, таким образом накапливается очередь подключений,
>>> и пользователи при перегрузке испытывают замедление реакции сайта.
>> А цель какая? Ограничить кол-во подключений или кол-во процессов? Если
>> подключения, то да, limit_req в nginx для каждого vhost'а, если процессы,
>> то крутить cgroups.
> Цель — ограничить количество одновременных процессов, обрабатывающих
> запросы к конкретному сайту.
> limit_req даёт возможность ограничить количество обращений в секунду, и
> таким образом
> может защитить от внешнего врага. Мне же нужно защититься от врага
> внутреннего.
> Если сайт вместо 200мс начнёт отвечать за 10с (не важно по каким
> причинам), всё не должно рухнуть от
> количества процессов апача и не должны пострадать соседи по апачу
> (другие сайты).
от этого может помоч ограничение nproc в  /etc/security/limits.conf


-- 
Regards, Sergey Alembekov
jid: rt@jabber.ru

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Michael Shigorin]

On Thu, Oct 29, 2015 at 11:09:14PM +0000, Konstantin Lepikhov wrote:
> если процессы, то крутить cgroups

Или вообще ulimit (см. тж. limited(8) и /etc/sysconfig/limits.d).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Anton Gorlov]

02.11.2015 17:44, Michael Shigorin пишет:
> Или вообще ulimit (см. тж. limited(8) и /etc/sysconfig/limits.d).
В случае апача не поможет, per user тем более

Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK

[Konstantin Lepikhov]

On 10/30/15, at 11:54:05 AM you wrote:

<skip>
> Был какой-то патч для cgroups, который как раз ограничивал кол-во форков,
> но его надо допиливать под текущие ядра, мне предлагали это сделать под
> wks ядра, но у меня нет времени и желания этим заниматься.
> 
> https://lists.unsafe.ru/pipermail/kernels/2013-September/000382.html
> 
PID controller появился в 4.3:
https://www.kernel.org/doc/Documentation/cgroups/pids.txt

-- 
WBR et al.