|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Igor Sysoev 2:5020/400 16 Nov 2005 17:16:03
To : Vadim Goncharov
Subject : Re: httpd в ядре
--------------------------------------------------------------------------------
Vadim Goncharov <vadimnuclight@tpu.ru> wrote:
> On Tue, 15 Nov 2005 14:45:20 +0000 (UTC); Igor Sysoev wrote about 'Re: httpd в
> ядре': В ядре есть одна полезная вещь - kqueue(2). Всё остальное меркнет перед
> ней. Есть цифры, насколько оно лучше? Цифры можно посмотреть
> здесь: http://people.freebsd.org/~jlemon/papers/kqueue.pdf а что касается
> практики, то select() и poll() съедают весь процессор на паре тысяч
> одновременных соединений, а kqueue спокойно работает на тридцати
> тысячах. Съедают в одном процессе или суммарно на всем сервере? Если один
> процесс работает с парой тысяч одновременных соединений в одном процессе, но
> на всём сервере кончается процессор. А если это будут скажем 4 процесса по 500
> соединений? Если будет 10 процессов по 200 соединений, то будет легче. Есть у
> меня одна машина 3.4 с nginx'ом, использует select, 20 рабочих процессов, по
> 100-300 соедиений на процесс. Хм. Интересно, сколько можно выжать из select()
> (пределы poll() тоже интересны) соедиений всего, если использовать небольшое
> число соединений на процесс, скажем по сотне?..
Hу вот переключил я сейчас на одной машине nginx на select и 100 рабочих
процессов. Машина на данный момент держит 10,000 keep-alive соединений и
обрабатывает 500 запросов в секунду. И что же ? 30-40% user time, 60-70%
system time, idle - 0%. Переключил обратно на kqueue и один рабочий
процесс - 15-20% user time, 15% system time.
> >> Hу а если бы он был в ядре - смог бы он это сделать еще лучше? :)
> IS> Hа самом деле, в nginx есть ещё куда расти - кэширование открытых
> IS> файлов и кэширование мелких файлов. А вынос в ядро добавит ещё 10%
> IS> производительности, а геморрою - на все 1000%.
>
> А как он их будет кэшировать, если он их сам не читает, а отправляет по
> sendfile() ? Делать mmap() и надеяться, что оно останется в кэше
> системы?
Файлы меньше страницы лучше считать в память (не mmap) и отдавать writev().
> IS>>> Вот их нужно уметь увеличивать так, чтобы машина не перегрузилась
> IS>>> во время работы (или даже загрузки).
> >>> Есть рекомендации по подбору оптимума?
> IS>> Hа одной машине 4.10 с 1G у меня стоит
> IS>> # 192M KVA
> IS>> kern.ipc.nmbclusters="65536"
> IS>> # 50M KVA
> IS>> kern.ipc.maxsockets="65536"
> IS>> # 120M KVA
> IS>> kern.ipc.nsfbufs="30720"
> >>
> IS>> В сумме под сеть отдано около 360M KVA. При KVA_PAGES=256 (default),
> IS>> это, насколько я понимаю, максимум. Можно что-то уменьшить, и что-то
> IS>> увеличить, но в пределах 360M, смотря чего не хватает.
> IS>> Чтобы отдать больше 360M, нужно увеличивать KVA_PAGES.
> >>
> >> Что такое KVA и почему при дефолте 256 их отдано 360 ?
> IS> Kernel Virtual Address space. 256 страниц по 4K, получается 1G.
>
> А откуда цифра 360 ?
Получено экспериментально. Скорее всего, его можно увеличить, если
уменьшить память под vfs и buffer cache.
--
Игорь Сысоев
http://sysoev.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
