ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Несколько непонят ностей по nginx



Igor Sysoev пишет:

0.5.18.2 откатить, 0.5.18.3 накатить.

Чистое ядро 64bit, nginx 0.5.19 + патч 0.5.18.3, limit_rate выключен.
Нужный эффект неблокируемости достигнут, но наблюдаю родившийся негативный. Однопотоковая закачка идёт в скорость диска - >50Мбайт/сек. Закачка в 2 и больше потоков через 1 воркер с диска приводит к падению суммарной скорости отдачи местами и меньше 10Мбайт/сек. Запустив 2 воркера и 2 закачки, убедившись через lsof -p каждого воркера, что идёт по 1 закачке на воркер - получил желаемую суммарную скорость отдачи >50Мбайт.

Пересобрал nginx с ngx_linux_sendfile_limit = 512 * 1024;
28Мбайт/сек в 2 потока с 1 воркера, утилизация диска 100%
~60 Мбайт 2 потока с 2-х воркеров, утилизация диска 100%
~65Мб 1 поток, утилизация диска 100%

lighttpd рядом с aio-sendfile показывает до 40мбайт на 2-х закачках с диска, но скорость падает до ещё меньшего значения чем у nginx - 6-7Мбайт/сек суммарно, утилизация диска 15% :). При убивании одной из закачек вторая оживает до 50Мбайт в сек, при возобновлении 2-й закачки о5 всё возвращается на 7Мбайт суммарно.

i386 ядро с патчем на sendfile(не в 128000,а в текущий размер буфера сокета), nginx 0.5.19 + патч 0.5.18.3, отдача 5G файла
Один поток - ~47Мбайт, утилизация диска 60-80% по iostat
2 потока 1 воркер - суммарная 20-25Мбайт, утилизация диска 90% по iostat

lighttpd sendfile
Один поток - ~50Мбайт, утилизация диска 99-100% по iostat
2 потока суммарная 30-40Мбайт, утилизация диска 99-100% по iostat

Можно в nginx сделать размер равным текущему размеру буфера сокета, вроде того, как я присылал патч и спрашивал почему он не работает :) ? Мне кажется, это положительно скажется на производительности. Хотя лишний системный вызов перед каждым sendfile ...

Пытаюсь разшевелить lkml'щиков http://lkml.org/lkml/2007/4/23/289, но особо много не добился. Проскочила разве что идея про новый системный вызов splice(2.6.17+)




 




Copyright © Lexa Software, 1996-2009.