Расскажу о вчерашних моих изысканиях.
Предыстория: На мудакторе есть один фронтэнд и куча бэкэндов. Все запросы идут на фронтэнд (где стоит nginx), там на сервере большой кэш картинок. То, что нет в кэше картинок и хтмл-страницы отправляются на один из бэкэндов.
Симптомы: время от времени весь nginx подвисает на 1-3 секунды.
Проблема: nginx читает с жёсткого диска данные и из-за сильной пиковой нагрузки на диск его блокирует на время чтения. Вот пример strace:
20:38:49.834933 open("/mnt/ssd/joyreactor/d4/9c/c2a4cb245d73e4c6b348ad8f73769cd4", O_RDONLY|O_NONBLOCK) = 2351
...snip...
20:38:51.883163 pread(2351, "E\244\232\241"..., 32768, 4194650) = 32768
20:39:05.764386 --- SIGALRM (Alarm clock) @ 0 (0) ---
Можно видеть,что файл открывается с флагом O_NONBLOCK - то есть, чтение должно быть не блокирующее. И при запуске этого неблокирующего чтения, тред блокируется на 15 секунд - с 20:38:51 до 20:39:05
Лезу в поиск. Нахожу, что "не блокирующий" в терминах линукса вполне может быть заблокирован на любое количество времени. Он не блокируется от всяких локов. А от сильной нагрузки на хард - вполне себе блокируется. Но есть асинхронное i/o (AIO). Это ахуенно продвинутая вещь и была реализована в линуксе пару лет назад! Позволяет делать запросы к диску полностью без блокировок. Но при этом не используются никакие дисковые кэши. То есть, надо в программе реализовывать всю дисковую подсистему, если хочешь работать с этим AIO. Заебись! Но нахуй такое нужно? Всё просто - эту систему реализовывали прогеры из IBM и Oracle. Они её делали для СУБД. А в СУБД итак дисковая подсистема своя написана и они на хард пишут напрямую.
А теперь самое интересное - во FreeBSD эта фича была реализована по-нормальному с кэшами в версии 4.3. Эта версия была выпущена 20 Апреля 2001 года... и нафиг я 7 лет назад с бзди пересаживался на линукс?!
сочувствую. но не думаю что 7 лет в пустую :D все в карму
Зато на линуксе ты можешь выполнять бесконечные циклы за пять секунд.
Это всего лишь один из плюсов фряхи) у линукса тоже есть плюсы. Видимо ты из взвесил, не все учел и пересел на линукс.
не, я их не взвешивал =). Просто устроился на работу, где был линукс - пришлось пересаживаться на линукс =)
AIO всё-таки включил? Есть результаты?
включал - там полный писец начинался. Без кэшей работает со скоростью полудохлой черепахи.
KDE2 уже давно устарело
а я его всё пропатчить не могу
Только избранные посвящены в древний секрет патча KDE под FreeBSD.
как попасть в эту секту Красноглазиков?
Получить пять звезд на ЛОРе троллингом в тех разделах же! Ну как дени, чес слово!
для начала надо перестать быть мудаком. Для тебя это самое сложное
я тебя по ойпи вычеслю. за мудака лох ответишь.
1. Не называть нас красноглазиками
2. Не привлекай к себе внимания
3. Установи линукс
4. Не брейся
5. Не мойся
6. Радуйся стиму на линуксе
7. (Самое важное) Найди одного из нас и устрой за ним слежку
2. Не привлекай к себе внимания
3. Установи линукс
4. Не брейся
5. Не мойся
6. Радуйся стиму на линуксе
7. (Самое важное) Найди одного из нас и устрой за ним слежку
есть ли реальный смысл хранить в дисковом кэше картинки?
я бы предложил cdn, но это наверняка выбивается за пределы бюджетов =)
я бы предложил cdn, но это наверняка выбивается за пределы бюджетов =)
Я вот наоборот на фрю с дебиана перенёс сервер, много лет уже никаких проблем.
Только Gentoo, только хардкор?
сейчас я на centos. А раньше gentoo любил - особенно с их системой компиляции как и у бсд
я бы добавил еще один уровень, если такие нагрузки. frontend - nginx, только балансировка, за ним 2+ nginx с кешами, за ними уже бекэнд
Первый вполне может выдавать статику - css, js, картинки из офрмления...
да, так и буду делать. Немного смущает, что нужно всё же писать логи на сата-диск и не будет ли это вешать первый фронтэнд.
пиши логи на RAMdisk чанками, и скидывай их потом на sata. Системный лог естественно сразу на диск, но тут никуда не денешся. хранить системные логи в памяти чревато долгим поиском проблем :)
да вот вломы все эти скрипты писать. Да и если какой-нибудь скрипт сглючит - то пиздец памяти настанет быстро...
Если ты пишешь логи обращения к диску, тогда нету смысла, на каждом nginx обращений будет меньше, может разрулят. по мере необходимости оно легко масштабируется в ширину. А если писать логи пользовательских запросов, то это нужно делать на самом первом серваке, и опять он станет узким местом
пишутся логи пользовательских запросов - чтобы защититься от спама одинаковых запросов.
логи запросов можно проксировать на на наименее загруженную машину, но писать скрипты нужно будет в любом случае
хуй знает в чём суть, но думаю что-тол умное, на всякий случай плюсанул)
А какого размера кеши? В память не влезает?
Описал бы полноценно, какие нагрузки, размеры кешей, что за железо. Всегда интересно было, как реактор устроен.
Описал бы полноценно, какие нагрузки, размеры кешей, что за железо. Всегда интересно было, как реактор устроен.
кэши размером с диски. Память тоже полностью используется через дисковый кэш.
Пиши письмо Сысоеву. Ну или выложи настройки, а то телепаты ты сам знаешь где.
Ну и задай себе вопрос зачем один сервер, задача которого просто роутить запросы еще и кешем занимается, ага.
Когда никакой сервак, за разумную цену, и это не будет выдерживать, будешь искать балансировщик на базе ДНС.
Ну и задай себе вопрос зачем один сервер, задача которого просто роутить запросы еще и кешем занимается, ага.
Когда никакой сервак, за разумную цену, и это не будет выдерживать, будешь искать балансировщик на базе ДНС.
а что Сысоеву писать? Он разве что скажет "линукс - говно, юзай бсд" =). Да и вообще я в нём разочаровался из-за того, что он не хочет ставить поддержку syslog в официальный дистриб.
про сислог не слышал, почитаю, что там за буча.
про бсд вполне может сказать, но у него бузинесс и данная проблема не думаю, что она одиночная.
У меня какое-то хреновое чувство, что что-то не так с настройкой.
При таких крешах, ОЗУ забита полностью?
про бсд вполне может сказать, но у него бузинесс и данная проблема не думаю, что она одиночная.
У меня какое-то хреновое чувство, что что-то не так с настройкой.
При таких крешах, ОЗУ забита полностью?
да всё это нормально =). просто диск пипец перегружен бывает. В этот самый момент диск читал директорию размером 60Мб (это размер директории, а не сумма размеров файлов =) ).
Ну и очевидное решение из этого - делим nginx на две части. Одна роутит всё без использования хардов. Вторая - отдаёт кэш с хардов. Вторая может подвисать - ну и фиг с ней, если картинки немного дольше будут загружаться никто не заметит =).
Ну и очевидное решение из этого - делим nginx на две части. Одна роутит всё без использования хардов. Вторая - отдаёт кэш с хардов. Вторая может подвисать - ну и фиг с ней, если картинки немного дольше будут загружаться никто не заметит =).
Ну диск ИО это всегда горлышко, для того и выдумали varnish/memcache/...
Ну и тюнинг ФС и ОС пора делать
Ну и тюнинг ФС и ОС пора делать
последний раз работал с бздёй в версии 5.1, затем перешёл на федору, а птом на дебиан, на дебиане уже лет 5, проблем нет.
проблем с чем нет? =)
Сэры, я конечно ни черта не понимаю в этих ваших никсах. Но как же RAIDы, ssd-гибриды, RAMдиски(хардовые, а не совтовые) и прочие ускорители обмена данных с ПЗУ?
bcache ftw
raid1 для sata-диска используется
ssd используется для кэша первого уровня.
ещё предложения, кэп? =)
ssd используется для кэша первого уровня.
ещё предложения, кэп? =)
RAID не для скорости, а для надежности, остальные вопросы, это если у тебя есть пачка зелени в кармане толщиной с хотя бы с палец.
ну почему же? RAID и для скорость вполне себе. raid1 увеличивает скорость чтения в 2 раза, что позволяет сглаживать пики.
А ssd уже сейчас стоят достаточно дёшево.
А ssd уже сейчас стоят достаточно дёшево.
RAID1 - дублирование, 0 это для скорости, 10 - для балланса между ними, тут дело в том, что это не панацея и такого хватит не на долго.
Про ссд поищи на хабере была статья амарао, где он поносил дешевые ссд (это те которые ставят обычно в хезнер :йоба:)
И вообще, если статики до 256 гб, то стоит вообще взять пару серваков с таким сумарным объемом ОЗУ и все в память положить.
Про ссд поищи на хабере была статья амарао, где он поносил дешевые ссд (это те которые ставят обычно в хезнер :йоба:)
И вообще, если статики до 256 гб, то стоит вообще взять пару серваков с таким сумарным объемом ОЗУ и все в память положить.
да, raid1 - дублирование. У тебя запись происходит на оба диска сразу, а чтение - с любого из двух. За счёт этого чтение в 2 раза быстрее, чем на одном диске. На raid0 будет и чтение и запись в 2 раза быстрее.
Статью амарао видел и общался с ним в комментах к другому посту. Его система оценки ссд меня немного удивила - он мерил скорость 4k random write и из-за плохих результатов говорил, что они говно. Возможно ему, как хостеру, правильно оценивать worst case, ибо конечные пользователи - вагинозрячие дурачки. Но я балансирую так, чтобы запись на ссд буфферизовалась. Зная как работает ссд можно легко понять, что 4k random write быстро убьют его.
У меня ссд замечательно работает. Хотя тюнил его достаточно долго - везде написанно, как делать элементарые вещи и очень сложно найти инфу по тонкой настройке. Сейчас по соотношению цена/скорость чтения ссд явно первый.
Всей статики сильно больше 256Гб. Да и сервера с 256Гб памяти будут очень не мало стоить. Я думаю хранить самые частоиспользуемые картинки в 1Гб кэша в памяти - туда попадёт то, что на главную вышло за день-два. А длинный хвост пусть дальше отдаётся с ссд+хдд
Статью амарао видел и общался с ним в комментах к другому посту. Его система оценки ссд меня немного удивила - он мерил скорость 4k random write и из-за плохих результатов говорил, что они говно. Возможно ему, как хостеру, правильно оценивать worst case, ибо конечные пользователи - вагинозрячие дурачки. Но я балансирую так, чтобы запись на ссд буфферизовалась. Зная как работает ссд можно легко понять, что 4k random write быстро убьют его.
У меня ссд замечательно работает. Хотя тюнил его достаточно долго - везде написанно, как делать элементарые вещи и очень сложно найти инфу по тонкой настройке. Сейчас по соотношению цена/скорость чтения ссд явно первый.
Всей статики сильно больше 256Гб. Да и сервера с 256Гб памяти будут очень не мало стоить. Я думаю хранить самые частоиспользуемые картинки в 1Гб кэша в памяти - туда попадёт то, что на главную вышло за день-два. А длинный хвост пусть дальше отдаётся с ссд+хдд
Ну, тобишь, я был недалек от пути решения проблемы?
ты был примерно так же близок к решению проблемы, как если бы сказал "надо больше серверных мощностей"
Я не понял честно говоря что даст тебе aio. Вот прилетел на воркер запрос, который обрабатывается. Допустим у тебя асинхронный доступ к диску. Что это тебе даст? Ты пока файл до конца не дочитаешь - отдать результат не можешь. Что будет делать воркер, пока файл читается? Асинхронка решает когда помимо чтения с диска есть чем заняться потоку, но я не представляю чем можно заниматься, когда тебе пришел запрос на картинку.
пусть в секунду приходит 10 запросов. Один запрос - отдать гифку, один запрос - отдать хтмл-страничку (то есть, переправить запрос на другой сервер), остальные - отдать аватарки, которые в файловом кэше и доступа к харду не требуют.
Первый запрос начинает читать диск и блочит нафиг весь тред. Остальные 9 запросов зависают, пока тред не разблочится.
Первый запрос начинает читать диск и блочит нафиг весь тред. Остальные 9 запросов зависают, пока тред не разблочится.
А воркеров сколько? И почему нельзя в отдельный тред вынести чтение с диска?
10 воркеров.
1) как ты в nginx вынесешь чтение диска в отдельный тред?
2) если каждое чтение выносить в тред - может случится пипец. Ибо чтений очень дофига и много чтений попадают в файловый кэш, который отдастся моментально из памяти.
Для этого и существует aio.
1) как ты в nginx вынесешь чтение диска в отдельный тред?
2) если каждое чтение выносить в тред - может случится пипец. Ибо чтений очень дофига и много чтений попадают в файловый кэш, который отдастся моментально из памяти.
Для этого и существует aio.
Воркеры на чем написаны?
Я с nginx мало работал. Если запрос перенаправляется на FCGI или на порт например апача, то воркер блокируется? Если нет - то можно бекендом отдавать тяжелые картинки, чтобы не вешать воркер, не?
Ухм, AIO в glibc по дефолту реализован через треды и не имеет проблем с кэшэм. О чём вайн-то?
aio в glibc сильно тормозить будет. в nginx используется aio в ядре. А он ебанутый, как я выше описал.
Вообще мне кажется, что проблема не в ядре, а в nginx'е. Т.е. open возвращается сразу, а nginx очень долго добирается до момента, когда он считает файл готовым к вводу. Нвпример:
1. open (xxx)
2. poll/select/epoll_wait
.... ждём....
3. -> readable
... м.б. опять ждём....
4. pread (xxx)
2. poll/select/epoll_wait
.... ждём....
3. -> readable
... м.б. опять ждём....
4. pread (xxx)
эти 15 секунд он находился внутри ядра. Нжынкс если ждёт - то ждёт внутри epoll
Он может не ждать, а обрабатывать события. strace этого не покажет
в таком случае он будет активно потреблять проц, чего не происходило
Верно. А ты пробовал strace -c, чтобы посмотреть, сколько именно и в каком мызове он проводил времени? Если бы на 15 минут тред зависал в ожидании диска, то он бы был в D и был бы большой iowait.
так и было =)
Чтобы написать коммент, необходимо залогиниться