Комментарии 63
Ура! Наконец-то дождались!
Ага, у меня первая реакция тоже была такая. :) А потом я потестировал новую версию с включенным AIO и без, и немного приуныл. Пользы от файлового AIO на большинстве реальных задач не очень много, реальный выигрыш заметен только при нагрузке, характерной для файл-хостеров, хранилищ фото, видео, и так далее. :)
Ну так мне для статики и надо
Фотохостинг на nginx самое оно
Фотохостинг на nginx самое оно
Я попытался потестировать AIO в разных сценариях нагрузки, и с разными настройками, под Linux. Я предположил, что если настроить nginx на отдачу файлов из каталога /usr и подготовить тестовый файл с url-ами для siege, можно получить достаточно похожую на файл-хостинг нагрузку. Включая по-очереди directio, sendfile и aio в разных комбинациях, можно было бы получить довольно интересную табличку результатов…
Но, дело в том, что тест я проводил на собственном десктопе, где одновременно была запущена целая KDE, так что воспроизводимость результатов теста оказалась… не на высоте. Я надеюсь, у меня когда-нибудь окажется достаточно свободного времени, чтобы провести это же тест в более подходящих условиях. :)
Но, дело в том, что тест я проводил на собственном десктопе, где одновременно была запущена целая KDE, так что воспроизводимость результатов теста оказалась… не на высоте. Я надеюсь, у меня когда-нибудь окажется достаточно свободного времени, чтобы провести это же тест в более подходящих условиях. :)
Отличная это штука — aio_*, роскошные даёт результаты :)
> Раньше, эта проблема решалась увеличением количества процессов-воркеров. Теперь есть альтернативное решение. :)
А многопоточности там нет что ли? Тогда AIO в конечном итоге все равно потребует увеличения к-ва процессов-воркеров.
А многопоточности там нет что ли? Тогда AIO в конечном итоге все равно потребует увеличения к-ва процессов-воркеров.
А вы предлагаете на каждый запрос поток создавать?
Нет. Вместо процессов-воркеров создавать потоки-воркеры (в Windows например спец-средства для этого есть).
Кстати, в создании потоков тоже ничего страшного нет. Только не на каждый запрос, а на каждый коннект. В HTTP/1.1 активно используется Keep-Alive (по умолчанию), в одном коннекте к одному сайту могут десятки/сотни http-запросов передаваться. Для небольших сайтов это наиболее экономный режим — если запросов мало, то никакие воркеры память не занимают.
Кстати, в создании потоков тоже ничего страшного нет. Только не на каждый запрос, а на каждый коннект. В HTTP/1.1 активно используется Keep-Alive (по умолчанию), в одном коннекте к одному сайту могут десятки/сотни http-запросов передаваться. Для небольших сайтов это наиболее экономный режим — если запросов мало, то никакие воркеры память не занимают.
Это концепции нгинкса противоречит. Да и ресурсы в случае ддоса или 5к онлайна беречь никто не будет
Как бы есть системы, где было около 1 тысячи рабочих процессов.
Для linux как-то пофигу, для системы, переключаться между тысячью тредов или тысячью процессов, ибо все есть task.
А концепция nginx простая, крути там, где ты думаешь что тормозит.
Для linux как-то пофигу, для системы, переключаться между тысячью тредов или тысячью процессов, ибо все есть task.
А концепция nginx простая, крути там, где ты думаешь что тормозит.
Я говорю о том, что уход от создания отдельного потока на каждое соединение — один из столпов нгинкса. А про то чем ворочить системе вопрос не ставлю.
Кстати, я сторонник мысли о том, что один поток на одно соеденение не так уж и плох. Но тут надо тестится :)
НЛО прилетело и опубликовало эту надпись здесь
Собственный шедулинг все равно должен как-то накладываться на ядерный (т.к. у ОС другого нет :). И не факт, что два шедулера лучше одного. В винде (начиная с Win2000) есть такая штука как IO completion port, который может использоваться как для асинхронного в/в, так и для создания пула рабочих потоков, т.е. эти вещи в общем случае взаимосвязаны и в системном планировщике.
Его еще надо правильно написать. И правильно развивать. Но ядерный шедулер не денется никуда. Он всегда может обидеть, так что ой. И что бы не обижал нужны честный rt системы.
Объясните, а почему aio вообще нужен одновременно с sendfile
Мне как-то админ объяснял, что sendfile() вообще не работает с чтением «в обычном» виде, это что то ближе к mmap(), но при этом все это происходит в адресном пространстве ядра, причем файл мапится сразу в TCP буфера. И при этом, используется механизм подкачки, а не чтения типа read().
Что тут не так/что я не понял?
Мне как-то админ объяснял, что sendfile() вообще не работает с чтением «в обычном» виде, это что то ближе к mmap(), но при этом все это происходит в адресном пространстве ядра, причем файл мапится сразу в TCP буфера. И при этом, используется механизм подкачки, а не чтения типа read().
Что тут не так/что я не понял?
Потому что sendfile — не асинхронный вызов. При «обычной» передаче данных вы копируете данные сначала из файла, к себе, в адресное пространство процесса, а потом ещё раз — в адресное пространство ядра, когда отправляете их «в сеть». sendfile позволяет избавиться от лишнего копирования в адресное пространство вашего процесса, но вам всё-равно придётся ждать, пока не закончится файловая операция.
В винде вместо sendfile есть аналогичная функция TransmitFile. Так вот она асинхронная, т.е. возвращает управление сразу после вызова, и далее работает где-то в системных воркерах. Т.е. ждать ничего не надо. Знаю точно, использую несколько лет. Для отдачи статических файлов хорошо подходит.
А sendfile в linux не может быть совмещена с aio ибо это самое aio там с боку.
Как давно ждал. Ну что ж, погоняем тесты сегодня :)
А можете потом результаты тестов опубликовать? Было бы очень интересно посмотреть.
Ну, это скорее не тест, а визуальная оценка, у меня как раз есть сервер, раздающий много больших файлов одновременно с маленькими файлами и проксированием на одном nginx. Запустил сейчас, буду смотреть, как жить будет :)
Технически вы должны будете убрать точку блокировки за syscall в work queue aio.
А не могли бы вы мне написать? Моя почта/xmpp: catap@catap.ru. У меня сейчас нет под рукой linux машинки на которой я могу провести что-то подобное. Я бы вопросы по задавал…
А не могли бы вы мне написать? Моя почта/xmpp: catap@catap.ru. У меня сейчас нет под рукой linux машинки на которой я могу провести что-то подобное. Я бы вопросы по задавал…
Визуально ничего почти не изменилось, меньше тормозов стало, но и появились баги 0.8.14, периодически стал получать 503 без причины, кроме того, nginx скушал всю оперативку (оно и не мудрено, порядка 600 клиентов в онлайне качают, многие в несколько потоков, да еще и 400 человек по сайту бродят), настройки остальные не трогал, оставил только:
sendfile on;
directio 1m;
aio on;
output_buffers 1 1m;
В итоге load average упал в среднем в 2 раза, iowait чуть меньше стал, сайт открывается резвее. На полную мощность пока проверить не могу, со вчерашнего дня в датацентре перебои с сетью, периодически линк падает :( Пока еще наблюдаю за ситуацией.
sendfile on;
directio 1m;
aio on;
output_buffers 1 1m;
В итоге load average упал в среднем в 2 раза, iowait чуть меньше стал, сайт открывается резвее. На полную мощность пока проверить не могу, со вчерашнего дня в датацентре перебои с сетью, периодически линк падает :( Пока еще наблюдаю за ситуацией.
Готов потестить на нагруженном сервере под linux или freebsd, только надо уточнить, что именно вы хотите получить в результатах?
Отрубил пока что aio. Один воркер стал жрать 100% проца, второй периодически падал.
Эх, сыровата еще 0.8.x…
Эх, сыровата еще 0.8.x…
«Во-вторых, файловый AIO работает только на FreeBSD 4.3 и выше, либо в Linux, с версии ядра 2.6.22 и выше.»
Не правда вообще-то. Он работает даже на древней SCO Unix v.5
Ну и у его деток. И особенно хорош aio на нормальных дисковых контролерах, а не на [I]diotic [D]isk [E]mulator ;)
Не правда вообще-то. Он работает даже на древней SCO Unix v.5
Ну и у его деток. И особенно хорош aio на нормальных дисковых контролерах, а не на [I]diotic [D]isk [E]mulator ;)
Замечание про:
output_buffers 128 512k;
Это какое-то странное и очень большое значение. Ведь это же настройка для одного клиента, зачем ему одному 128 буферов по полметра?
Для раздачи больших файлов, где от sendfile тормоза (есть у меня такие конфигурации) очень хорошо помогает много памяти на сервере и такая настройка с буферами для клиента:
output_buffers 1 2m;
output_buffers 128 512k;
Это какое-то странное и очень большое значение. Ведь это же настройка для одного клиента, зачем ему одному 128 буферов по полметра?
Для раздачи больших файлов, где от sendfile тормоза (есть у меня такие конфигурации) очень хорошо помогает много памяти на сервере и такая настройка с буферами для клиента:
output_buffers 1 2m;
Пока Nginx AIO не заработает на RHEL/CentOS в линуксе пользы от него мало.
Ну конечно, другие дистрибутивы вообще никто не использует=)
Скорее уж тогда «пока РедХат не слезет с замшелого ядра 2.6.18». Хотя, если вы ставите все пакеты только из репозитория CentOS, то откуда у вас, вообще Nginx? Тем более, новый… :)
Не «замшелое», а стабильное. Стабильное в понимании серьезных серверов, а не десктопов.
Да и собрать самому Nginx это не тоже самое что пересобрать ядро на боевом сервере, работающем годами без ребутов.
Да и собрать самому Nginx это не тоже самое что пересобрать ядро на боевом сервере, работающем годами без ребутов.
А одно другому не мешает. 2.6.18 вышло 20 сентября 2006 года, то есть, ему скоро исполнится три года. За это время столько всего произошло… :)
Хотя, я вас, в принципе, понимаю, я сам бы не стал бы трогать ядро на полностью рабочей системе без необходимости. Но это плата за стабильность — задержка в получении bleeding edge-технологий.
Хотя, я вас, в принципе, понимаю, я сам бы не стал бы трогать ядро на полностью рабочей системе без необходимости. Но это плата за стабильность — задержка в получении bleeding edge-технологий.
Сударь, 2.6.18 от kernel.org и 2.6.18 в RHEL это очень разные ядра. И, RedHat-у, как крупнейшему маинтейнеру ядра, я думаю всё-таки виднее какое ядру лучше подходит к их дистрибутиву.
Ну, кстати, возможно, имеет смысл попробовать собрать последний nginx на системе с ядром от РедХат. Они действительно накладывают довольно много патчей, так что всё может и завестись.
Единственное, лучше подождать nginx 0.8.15, потому что в 0.8.14 (последнем на сегодня) уже точно есть как минимум одна ошибка, приводящая в определённых обстоятельствах к сегфолту под линуксом.
Единственное, лучше подождать nginx 0.8.15, потому что в 0.8.14 (последнем на сегодня) уже точно есть как минимум одна ошибка, приводящая в определённых обстоятельствах к сегфолту под линуксом.
Вы бы добавили фразу из мануала: «Поскольку directio в Linux можно использовать только для чтения блоков, выравненных по 512 байт (или 4К для XFS), то невыравненный конец файла будет читаться блокировано.»
Ну… мне это не показалось уж очень критичным. Время блокировки на чтение одного сектора в 512 байт должно быть достаточно мало, чтобы этого никто не заметил. :)
Для XFS это уже 4КБ.
Туда же до кучи «То же относится к запросам части ответа byte-ranges и к запросам FLV не с начала файла: чтение невыровненных начала и конца ответа будет блокирующимся.»
Заметят. Всего-то нужно каждому воркеру уйти в блокирующее чтение пусть даже 512ти байт — запросы приниматься и обрабатываться в это время не будут.
Заметят. Всего-то нужно каждому воркеру уйти в блокирующее чтение пусть даже 512ти байт — запросы приниматься и обрабатываться в это время не будут.
Это черезвучайно итересная фича я думаю. А может кто ни будь ответить на наивный вопрос на пальцах?
для машины раздающей большие статические файлы какие _именно_ радости принесет эта фича? Можно будет ставить меньше воркеров? Уменьшиться нагрузка на CPU? И может быть даже можно надеяться на небольшое увеличении скорости отдачи файлов?
для машины раздающей большие статические файлы какие _именно_ радости принесет эта фича? Можно будет ставить меньше воркеров? Уменьшиться нагрузка на CPU? И может быть даже можно надеяться на небольшое увеличении скорости отдачи файлов?
Почти никаких радостей, кроме возможного уменьшения количества воркеров. Если производительность отдачи файлов nginx ограничена производительностью жёсткого диска, то, в любом случае, сколько-то заметного ускорения отдачи файлов не будет. Впрочем, я надеюсь ещё провести более тщательный тест. Если найдётся время, напишу об этом отдельный пост.
Спасибо за ответ. просто для лайти (судя по этому посту ) использование AIO дало просто какой то фантастический эффект. Не знаю даже как это объяснить :)
НЛО прилетело и опубликовало эту надпись здесь
Эта фича служит только для одного, вынести точки ожидания открытия файла за syscall
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Файловый AIO в nginx