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. _______________________________________________ Sysadmins mailing list Sysadmins@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/sysadmins
