* [Sysadmins] Ограничение количества клиентов на хост для Apache ITK @ 2015-10-29 20:46 Vitaly Lipatov 2015-10-29 20:44 ` Anton Gorlov 2015-10-29 23:09 ` Konstantin Lepikhov 0 siblings, 2 replies; 11+ messages in thread From: Vitaly Lipatov @ 2015-10-29 20:46 UTC (permalink / raw) To: sysadmins Задача следующая: нужно ограничить количество процессов 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-10-29 20:46 [Sysadmins] Ограничение количества клиентов на хост для Apache ITK Vitaly Lipatov @ 2015-10-29 20:44 ` Anton Gorlov 2015-10-29 23:09 ` Konstantin Lepikhov 1 sibling, 0 replies; 11+ messages in thread From: Anton Gorlov @ 2015-10-29 20:44 UTC (permalink / raw) To: ALT Linux sysadmins' discussion 29.10.2015 23:46, Vitaly Lipatov пишет: > А ограничение по MaxClientsVhost сразу возвращает 503 при достижении > предела подключений. Что вовсе не желательно, потому > что для клиента выглядит как то, что сайт работает быстро, но иногда > вместо страницы — ошибка. > Может быть есть всем известное решение, которое я не знаю? Сам сейчас хожу по тем же граблям. Пока пришёл к выводу что лимитировать коннекты к сайту лучше средствами nginx через limit_req_zone $host и limit_req... ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-10-29 20:46 [Sysadmins] Ограничение количества клиентов на хост для Apache ITK Vitaly Lipatov 2015-10-29 20:44 ` Anton Gorlov @ 2015-10-29 23:09 ` Konstantin Lepikhov 2015-10-30 8:37 ` Vitaly Lipatov 2015-11-02 14:44 ` Michael Shigorin 1 sibling, 2 replies; 11+ messages in thread From: Konstantin Lepikhov @ 2015-10-29 23:09 UTC (permalink / raw) To: sysadmins 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-10-29 23:09 ` Konstantin Lepikhov @ 2015-10-30 8:37 ` Vitaly Lipatov 2015-10-30 11:54 ` Konstantin Lepikhov 2015-11-02 14:15 ` Sergey Alembekov 2015-11-02 14:44 ` Michael Shigorin 1 sibling, 2 replies; 11+ messages in thread From: Vitaly Lipatov @ 2015-10-30 8:37 UTC (permalink / raw) To: sysadmins 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-10-30 8:37 ` Vitaly Lipatov @ 2015-10-30 11:54 ` Konstantin Lepikhov 2015-10-31 8:20 ` Anton Gorlov 2015-11-02 17:41 ` Konstantin Lepikhov 2015-11-02 14:15 ` Sergey Alembekov 1 sibling, 2 replies; 11+ messages in thread From: Konstantin Lepikhov @ 2015-10-30 11:54 UTC (permalink / raw) To: sysadmins 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-10-30 11:54 ` Konstantin Lepikhov @ 2015-10-31 8:20 ` Anton Gorlov 2015-11-02 17:41 ` Konstantin Lepikhov 1 sibling, 0 replies; 11+ messages in thread From: Anton Gorlov @ 2015-10-31 8:20 UTC (permalink / raw) To: ALT Linux sysadmins' discussion Кстати вот ещё интересная вещь http://habrahabr.ru/post/269835/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-10-30 11:54 ` Konstantin Lepikhov 2015-10-31 8:20 ` Anton Gorlov @ 2015-11-02 17:41 ` Konstantin Lepikhov 1 sibling, 0 replies; 11+ messages in thread From: Konstantin Lepikhov @ 2015-11-02 17:41 UTC (permalink / raw) To: sysadmins 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-10-30 8:37 ` Vitaly Lipatov 2015-10-30 11:54 ` Konstantin Lepikhov @ 2015-11-02 14:15 ` Sergey Alembekov 2015-11-02 14:12 ` Anton Gorlov 1 sibling, 1 reply; 11+ messages in thread From: Sergey Alembekov @ 2015-11-02 14:15 UTC (permalink / raw) To: sysadmins 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-11-02 14:15 ` Sergey Alembekov @ 2015-11-02 14:12 ` Anton Gorlov 0 siblings, 0 replies; 11+ messages in thread From: Anton Gorlov @ 2015-11-02 14:12 UTC (permalink / raw) To: ALT Linux sysadmins' discussion 02.11.2015 17:15, Sergey Alembekov пишет: > от этого может помоч ограничение nproc в /etc/security/limits.conf Если только в мечтах. apache-itk воркеры работают от рута и потом делают переключение на нужного юзера и наследуют лимиты от исходного юзера Как вариант https://github.com/MatthewIfe/mod_cgroup ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-10-29 23:09 ` Konstantin Lepikhov 2015-10-30 8:37 ` Vitaly Lipatov @ 2015-11-02 14:44 ` Michael Shigorin 2015-11-02 14:49 ` Anton Gorlov 1 sibling, 1 reply; 11+ messages in thread From: Michael Shigorin @ 2015-11-02 14:44 UTC (permalink / raw) To: sysadmins 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Sysadmins] Ограничение количества клиентов на хост для Apache ITK 2015-11-02 14:44 ` Michael Shigorin @ 2015-11-02 14:49 ` Anton Gorlov 0 siblings, 0 replies; 11+ messages in thread From: Anton Gorlov @ 2015-11-02 14:49 UTC (permalink / raw) To: ALT Linux sysadmins' discussion 02.11.2015 17:44, Michael Shigorin пишет: > Или вообще ulimit (см. тж. limited(8) и /etc/sysconfig/limits.d). В случае апача не поможет, per user тем более ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-11-02 17:41 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-29 20:46 [Sysadmins] Ограничение количества клиентов на хост для Apache ITK Vitaly Lipatov 2015-10-29 20:44 ` Anton Gorlov 2015-10-29 23:09 ` Konstantin Lepikhov 2015-10-30 8:37 ` Vitaly Lipatov 2015-10-30 11:54 ` Konstantin Lepikhov 2015-10-31 8:20 ` Anton Gorlov 2015-11-02 17:41 ` Konstantin Lepikhov 2015-11-02 14:15 ` Sergey Alembekov 2015-11-02 14:12 ` Anton Gorlov 2015-11-02 14:44 ` Michael Shigorin 2015-11-02 14:49 ` Anton Gorlov
ALT Linux sysadmins discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sysadmins/0 sysadmins/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 sysadmins sysadmins/ http://lore.altlinux.org/sysadmins \ sysadmins@lists.altlinux.org sysadmins@lists.altlinux.ru sysadmins@lists.altlinux.com public-inbox-index sysadmins Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sysadmins AGPL code for this site: git clone https://public-inbox.org/public-inbox.git