После неудачной попытки с ceph и советов забить на это, как от гуру-школьников на реакторе, так и на хабре, я уже почти опустил руки.
В это время тестировался gfs2. Но он оказался: во-первых, плохо масштабируемым; во-вторых, достаточно медленным; в-третьих, ооочень сложным и глючным. Явно не расчитан на "commodity hardware".
Я пустился в размышления - почему же это так сложно и тормознуто. Ведь задача простая - хранить файл в нескольких копиях на разных серверах + как-нибудь сохранить где именно он хранится. При желании, это реализуется достаточно просто и быстро даже вручную.
И тут я понял основную ошибку - я искал файловую систему. А в ней не просто хранение, но ещё и система прав и лок файлов. Они мне не были нужны, поэтому я отказался от понятия файловой системы. И тут же обнаружил Openstack Swift. Это простое хранилище данных.
- Работает через REST-интерфейс (обычный http).
- В случае падения одной из нод, работает без проблем дальше.
- Используется в wikimedia для хранения всяких картинок.
В общем, проект достаточно зрелый. Хотя информации о нём достаточно мало - возможно из-за того, что для работы с ним надо менять код и вместо файловых методов использовать сетевые. Развернул, обнаружил несколько особенностей, которые не сильно повлияли на дальнейшие действия:
1) при большом количестве файлов, он может добавлять порядка 50 файлов в секунду. Для больших скоростей нужен ссд. Ну в обычное время у меня добавляется несколько файлов в минуту. Поэтому до этого предела ещё далеко.
2) полностью рабочая нода - это 15 разных демонов. Вначале немного охреневаешь от такого изобилия. Но со временем понимаешь, что всё чётко и стройно. Просто они, следуя философии unix, разделили разные функции на разные демоны. Во время первоначальной синхронизации, я отключил некоторые демоны и скорость возросла раза в два.
3) первоначальная заливка всего контента заняла порядка 2 недель неспешного копирования. Днём копирование отрубалось, чтобы не мешать реактору работать.
Итак, результаты:
1) уже 3 недели все новые картинки заливались в свифт. При чтении иногда они брались с диска, иногда - из свифта.
2) с начала этой недели картинки читались только из свифта. Они ещё писались на диск на всякий случай, но не читались
3) с сегодняшнего утра всё полностью перешло на свифт. На диск больше не пишется и не читается. В последний раз забэкаплю и на след.неделе удалю с боевых серверов.
Таким образом, я избавился от одной из трёх точек отказа. Ура!
Ну и всякие дополнительные мелочи:
1) во время переноса свифта обнаружил, что картиночный сервер упирается в канал 100Мбит в часы пик. Вовремя я начал чесаться по поводу его переноса... =)
2) следующая точка отказа, которую надо будет устранять, - mysql. Раньше думал, что придётся переходить на postgresql, ибо в мускуле всё плохо с репликацией, failover и вообще версия 5.5 (которая появилась после покупки ораклом) у них очень плохая вышла. Коммуна была расстроена и считала, что оракл убьёт мускуль. Но в феврале этого года вышла версия 5.6, которая удивительно хорошо работает - быстрее 5.5, добавлены фичи для репликации из коробки, для php выпустили плагин с load-balancing и failover. В общем, похоже мускуль воскрес из мёртвых и мне это нравится, ибо не хочется переучиваться на постгрю.
3) написал хостеру, что наблюдаю днём пакетлост 0.1%, а по вечерам наблюдаю пакет-лост 0.5%. На удивление, не послали нахрен, а начали разбираться. Хоть и достаточно вяло.
4) после того, как перешёл на swift, на серверах стало нехватать памяти (всего 16Гб). Пришлось перейти с apache на nginx+php-fpm. Из-за того, что фротэнд держал с бэкэндами keel-alive соединения, получил выигрыш в памяти в 3 раза - 300 Мб вместо 1Гб.
5) настроил себе в заббиксе красивые картинки. Теперь если что-то торимозит - я не бегаю по серверам, а запускаю один экран и всё сразу видно:
Результаты поиска потегуадминские истории
Дополнительные фильтры
Теги:
админские историиновый тег
Автор поста
Рейтинг поста:
-∞050100150200300400+
Найдено: 21
Сортировка:
- Сколько будет стоить аренда канала 1Гбит для выделенного сервера (без учёта стоимость аренды сервера)?
- Месячная аренда канала в 1 Гбит/с для выделенного сервера составляет 90000 рублей.
- Судя по новости http://selectel.ru/news/increasing-network-connection-speed-to-100mbits/ - если я закажу 9 самых дешёвых серверов и не буду использовать их, то получу 1Гбит за 13500 руб. Так?
- Если на Вашем аккаунте есть 10 заказанных серверов, то Вы можете запросить смену учета трафика. После чего да, Вы сможете использовать 1 Гбит/c на все 10 серверов или 1 в отдельности.
- Месячная аренда канала в 1 Гбит/с для выделенного сервера составляет 90000 рублей.
- Судя по новости http://selectel.ru/news/increasing-network-connection-speed-to-100mbits/ - если я закажу 9 самых дешёвых серверов и не буду использовать их, то получу 1Гбит за 13500 руб. Так?
- Если на Вашем аккаунте есть 10 заказанных серверов, то Вы можете запросить смену учета трафика. После чего да, Вы сможете использовать 1 Гбит/c на все 10 серверов или 1 в отдельности.
Что-то в последнее время у меня слишком много админских событий, что не очень радует... не люблю я нервничать.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
узнал тут, что двач уже три дня лежит (и будет ещё лежать до утра как минимум). Причина:
храните бэкапы на выделенных серверах, тащемта. новехонькие 2 из 4х 300-гиговых SAS дисков, по предварительной информации могли пиздануться.
Да ещё и дальше пишет "макаки из Лизвеба заменили 4 из 4 дисков в рейде 5. разворачиваем бэкапы".
Бггг. То есть, он использует крутые SAS, но не хватает денег даже raid1 собрать =)
храните бэкапы на выделенных серверах, тащемта. новехонькие 2 из 4х 300-гиговых SAS дисков, по предварительной информации могли пиздануться.
Да ещё и дальше пишет "макаки из Лизвеба заменили 4 из 4 дисков в рейде 5. разворачиваем бэкапы".
Бггг. То есть, он использует крутые SAS, но не хватает денег даже raid1 собрать =)
Картиночный сервер, где хранятся и обрабатываются все картинки, начал глючить. Раз-два в неделю зависает так, что даже автоматический резет не помогал. Похоже проблема хардварная. В хетцнере это решается просто - отдаёшь сервер им на диагностику на 12 часов. Делать неработающими картинки на 12 часов не очень хотелось. Поэтому надо было перенести его на другой сервер.
Но тут я подумал - у меня, включая картиночный, уже есть 4. На трёх диски не загружены почти. Память есть. В основном используется процессор для отдачи php. Почему бы не сделать какую-нибудь кластерную фс и убрать одну из точек отказа? Тогда все сервера с апачем будут равноправными, все вместе писать/читать с этой фс и всё будет збс.
Посмотрел какие есть кластерные фс. Самая крутая - ceph. Уже год как вышли из беты. Пишут, что офигенно быстрая и надёжная. Самовосстанавливается, нет одной точки отказа. В будущем можно просто подключать к ней жёсткие диски и она всё будут перебалансировать.
Придумано - сделано. Код на php быстро подправил: ломать - не строить. По сути надо было сломать весь код, который отвечал за перенаправление картиночных запросов на картиночный сервер.
Поставил ceph. Во время установки удивило, что они полностью тестируют только на убунте с дефолтным ядром 3.2, но рекомендуют обязательно обновляться до ядра 3.4/3.6, ибо на более ранних версиях у них не работают серверные модули о_О. Ядро 3.6 и "стабильность" у меня в глове не укладывались, но можно было всё сделать и без модулей ядра. Поэтому ceph был успешно установлен и подмонтирован.
С первого взгляда, всё было хорошо. Есть на одном сервере создать файл, то он появлялся на другом сервере.
И тут я совершил роковую ошибку. Я доверился их заявлениям о скорости/стабильности и переключил сервера на использование ceph.
продолжение следует...
Но тут я подумал - у меня, включая картиночный, уже есть 4. На трёх диски не загружены почти. Память есть. В основном используется процессор для отдачи php. Почему бы не сделать какую-нибудь кластерную фс и убрать одну из точек отказа? Тогда все сервера с апачем будут равноправными, все вместе писать/читать с этой фс и всё будет збс.
Посмотрел какие есть кластерные фс. Самая крутая - ceph. Уже год как вышли из беты. Пишут, что офигенно быстрая и надёжная. Самовосстанавливается, нет одной точки отказа. В будущем можно просто подключать к ней жёсткие диски и она всё будут перебалансировать.
Придумано - сделано. Код на php быстро подправил: ломать - не строить. По сути надо было сломать весь код, который отвечал за перенаправление картиночных запросов на картиночный сервер.
Поставил ceph. Во время установки удивило, что они полностью тестируют только на убунте с дефолтным ядром 3.2, но рекомендуют обязательно обновляться до ядра 3.4/3.6, ибо на более ранних версиях у них не работают серверные модули о_О. Ядро 3.6 и "стабильность" у меня в глове не укладывались, но можно было всё сделать и без модулей ядра. Поэтому ceph был успешно установлен и подмонтирован.
С первого взгляда, всё было хорошо. Есть на одном сервере создать файл, то он появлялся на другом сервере.
И тут я совершил роковую ошибку. Я доверился их заявлениям о скорости/стабильности и переключил сервера на использование ceph.
продолжение следует...
итак, в пятницу я начал разносить nginx на две части, как я писал в предыдущем топике. После разнесения стало заметно меньше лагов. И вдруг сильно подскочило количество просмотров на посетителя. В картинке ниже - пример того, что было в воскресение по сравнению с субботой.
продолжение под катом
продолжение под катом
Расскажу о вчерашних моих изысканиях.
Предыстория: На мудакторе есть один фронтэнд и куча бэкэндов. Все запросы идут на фронтэнд (где стоит 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 лет назад с бзди пересаживался на линукс?!
Предыстория: На мудакторе есть один фронтэнд и куча бэкэндов. Все запросы идут на фронтэнд (где стоит 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 лет назад с бзди пересаживался на линукс?!
Следующая история про работу с cloudflare.
Как-то раз hetzner заблокировал основной ip реактора из-за того, что на него идёт ddos. Причём сделал это в пятницу вечером, а разблокировать собирался в лучшем случае в понедельник утром. Я повозмущался немного, но потом вычитал, что стандартные хостеры просто не расчитаны на такие сетевые нагрузки. Поэтому было решено фронтенд вынести куда-нибудь на специализированный хостинг.
Есть куча анти-ддос хостеров. Но они дороговато стоят. И тут я вспомнил про cloudflare. Про них раньше писали много отрицательных отзывов, но с тех пор прошло много времени. Да и всякие двачи на них сидят. Решили сразу платный аккаунт брать за 200$ - там есть priority support и защита от ddos.
1) где-то в 19:00 меняю dns на них
2) в 21:00 начинаю наблюдать, что количество пользователей уменьшается.
3) тут связывается со мной Zubo и говорит, что реактор открывается только через тор. Говорю ему какие команды запускать. Выясняем, что с его провайдера (а у него какой-то московский крупный) не резолвятся их ns-сервера.
4) в 21:30 пишу им о том, что наблюдаем проблемы и прикладываю все трейсы, из которых видно, что Zubo не может подключиться к их ns-серверам.
5) в 23:30 падение трафика более 20%. От них - ни весточки. Я меняю ns-сервера обратно.
6) в 3:00 трафик возвращается.
7) в 11:00 от них приходит письмо "ой, а вы уже сменили ns-ы у себя? ну тогда мы не можем ничем помочь. Теперь уже не понять, в чём проблема"
При более внимательном прочтении их планов оплаты обнаруживаю, что саппорт 24/7 они дают только для самого крутого варианта - который от 3000$/месяц. За такие деньги можно купить профессиональный анти-ддос хостинг.
вот замечательный топик по тому же поводу - http://blog.kuzmitch.ru/2012/07/cdn-cloudflare.html
Там в комментах спрашивают - почему же автор через 3 месяца уже ушёл от cloudflare. И он отвечает - что есть куча проблем, но если бы платные были, то наверное этих проблем бы небыло. Так вот - эти проблемы у них независимо от того, сколько им платишь =)
Как-то раз hetzner заблокировал основной ip реактора из-за того, что на него идёт ddos. Причём сделал это в пятницу вечером, а разблокировать собирался в лучшем случае в понедельник утром. Я повозмущался немного, но потом вычитал, что стандартные хостеры просто не расчитаны на такие сетевые нагрузки. Поэтому было решено фронтенд вынести куда-нибудь на специализированный хостинг.
Есть куча анти-ддос хостеров. Но они дороговато стоят. И тут я вспомнил про cloudflare. Про них раньше писали много отрицательных отзывов, но с тех пор прошло много времени. Да и всякие двачи на них сидят. Решили сразу платный аккаунт брать за 200$ - там есть priority support и защита от ddos.
1) где-то в 19:00 меняю dns на них
2) в 21:00 начинаю наблюдать, что количество пользователей уменьшается.
3) тут связывается со мной Zubo и говорит, что реактор открывается только через тор. Говорю ему какие команды запускать. Выясняем, что с его провайдера (а у него какой-то московский крупный) не резолвятся их ns-сервера.
4) в 21:30 пишу им о том, что наблюдаем проблемы и прикладываю все трейсы, из которых видно, что Zubo не может подключиться к их ns-серверам.
5) в 23:30 падение трафика более 20%. От них - ни весточки. Я меняю ns-сервера обратно.
6) в 3:00 трафик возвращается.
7) в 11:00 от них приходит письмо "ой, а вы уже сменили ns-ы у себя? ну тогда мы не можем ничем помочь. Теперь уже не понять, в чём проблема"
При более внимательном прочтении их планов оплаты обнаруживаю, что саппорт 24/7 они дают только для самого крутого варианта - который от 3000$/месяц. За такие деньги можно купить профессиональный анти-ддос хостинг.
вот замечательный топик по тому же поводу - http://blog.kuzmitch.ru/2012/07/cdn-cloudflare.html
Там в комментах спрашивают - почему же автор через 3 месяца уже ушёл от cloudflare. И он отвечает - что есть куча проблем, но если бы платные были, то наверное этих проблем бы небыло. Так вот - эти проблемы у них независимо от того, сколько им платишь =)
следующая история про неудавшийся ддос.
В рамках подготовки к задаче по переносу обработки картинок на другой сервер (см предыдущий пост), надо было стереть кэш memcached. Раньше это было достаточно болезненно, ибо mysql захлёбывался от количества запросов. Но сейчас мемкэшов стало два и можно было перегружать их по одному - удаляя по половине кэша. Таким образом нагрузка была меньше.
Ну встал пораньше и в 10 утра перегрузил по очереди кэши. Вроде всё хорошо с первым пиком сервера успешно справились. Дальше нагрузка всё равно немного больше - процентов на 20%. Они пару дней будут наполняться менее популярными страницами, куда заходят, но не часто.
Через пару часов проверяю нагрузку. Обнаруживаю что она выше, чем должна быть. Первая мысть - где-то напортачил с кэшами и они не подцепились. Тогда ещё через час сервера умрут по естественной нагрузкой. Смотрю запросы в мускуле - и вправду, идёт много запросов, которые должны быть жёстко закэшированны. И тут же понимаю, что если бы кэши полностью не подцепились, то сервера бы уже умерли. А тут скоро уже пиковая нагрузка, а им вполне нормально, хоть и выше нормы.
Долго размышляю и изучаю данную проблему. На всякий случай, перегружаю апачи. Ничего не меняется. Иду мыться в душ и там меня осеняет. Симфони (да и большниство серверов) не кэшируют POST-запросы. Наверное где-то есть страница, которая грузится через POST. Возвращаюсь и обнаруживаю в логах примерно такое:
85.26.241.3 - - [30/Jan/2013:05:09:14 +0100] "POST /tag/mass%2Beffect/new/11?count=&1359518948806.76 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
85.26.241.3 - - [30/Jan/2013:05:13:38 +0100] "POST /post/204783?count=&1359519213127.96 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
В гугле находит, что heias - это какая-то адвара. Похоже ещё и система управление ддосом. Они слали специально запросы, которые пробиывают кэш. Проверка на тип запроса у меня не везде проводилась и в некоторых местах оно пробивалось. Правда результат был всё равно плачевный для них - если бы я не мониторил специально нагрузку, то никто бы и не заметил этого ддоса. Им надо было создать хотя бы 20% от естественной посещалки реактора, чтобы пробивка кэша дала результаты.
Сейчас погрепал в логах - они нашли ещё пару мест, где не проверяется GET/POST. Надо будет поправить для чистоты кода.
В рамках подготовки к задаче по переносу обработки картинок на другой сервер (см предыдущий пост), надо было стереть кэш memcached. Раньше это было достаточно болезненно, ибо mysql захлёбывался от количества запросов. Но сейчас мемкэшов стало два и можно было перегружать их по одному - удаляя по половине кэша. Таким образом нагрузка была меньше.
Ну встал пораньше и в 10 утра перегрузил по очереди кэши. Вроде всё хорошо с первым пиком сервера успешно справились. Дальше нагрузка всё равно немного больше - процентов на 20%. Они пару дней будут наполняться менее популярными страницами, куда заходят, но не часто.
Через пару часов проверяю нагрузку. Обнаруживаю что она выше, чем должна быть. Первая мысть - где-то напортачил с кэшами и они не подцепились. Тогда ещё через час сервера умрут по естественной нагрузкой. Смотрю запросы в мускуле - и вправду, идёт много запросов, которые должны быть жёстко закэшированны. И тут же понимаю, что если бы кэши полностью не подцепились, то сервера бы уже умерли. А тут скоро уже пиковая нагрузка, а им вполне нормально, хоть и выше нормы.
Долго размышляю и изучаю данную проблему. На всякий случай, перегружаю апачи. Ничего не меняется. Иду мыться в душ и там меня осеняет. Симфони (да и большниство серверов) не кэшируют POST-запросы. Наверное где-то есть страница, которая грузится через POST. Возвращаюсь и обнаруживаю в логах примерно такое:
85.26.241.3 - - [30/Jan/2013:05:09:14 +0100] "POST /tag/mass%2Beffect/new/11?count=&1359518948806.76 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
85.26.241.3 - - [30/Jan/2013:05:13:38 +0100] "POST /post/204783?count=&1359519213127.96 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
В гугле находит, что heias - это какая-то адвара. Похоже ещё и система управление ддосом. Они слали специально запросы, которые пробиывают кэш. Проверка на тип запроса у меня не везде проводилась и в некоторых местах оно пробивалось. Правда результат был всё равно плачевный для них - если бы я не мониторил специально нагрузку, то никто бы и не заметил этого ддоса. Им надо было создать хотя бы 20% от естественной посещалки реактора, чтобы пробивка кэша дала результаты.
Сейчас погрепал в логах - они нашли ещё пару мест, где не проверяется GET/POST. Надо будет поправить для чистоты кода.
Буду писать тут интересные случае из работы.
Для начала - почему вчера весь день тормозил реактор. Уже давно основной фронтэнд сдыхал. На нём же обрабатывались картинок и он не справлялся с отдачей картинок на скорости 2Гбит и обработкой их. Поэтому я начал потихоньку обработку картинок переносить в другое место.
И вдруг произошло что-то. Симптомы:
1) на сата дисках чтение 5Mb/s
2) на ссд диске запись только 0.5Mb/s. Хотя должна быть те же 5Mb/s, ибо всё что читается с сата потом сразу кладётся в кэш ссд.
3) запросы время от времени подвисают на 5-10-15 секунд. Причём в них нет никакого криминала - обычная отдача малоиспользующейся картинки размеров в 500Кб.
Начал грешить на nginx - что он почему-то не записывает в кэш то, что отдаёт бэкэнд. Долго мучался - ничего не смог выяснить. Решил раньше времени переносить на новый сервер бэкэнд - должно хотя бы распределить нагрузку.
Во время rsync понял в чём проблема была - все картинки у меня складываются в одну директорию. И теперь она выглядит так:
drwxrwxrwx 2 root root 59M Jan 30 19:58 pics
Можно заметить, что размер директории - 59Мб. Похоже из-за возросшей нагрузки она вытеснялась из файлового кэша и очередной запрос на 500Кб хотел открыть эту директорию, что заставляло его читать все 59Мб и тормозить всю систему.
Для начала - почему вчера весь день тормозил реактор. Уже давно основной фронтэнд сдыхал. На нём же обрабатывались картинок и он не справлялся с отдачей картинок на скорости 2Гбит и обработкой их. Поэтому я начал потихоньку обработку картинок переносить в другое место.
И вдруг произошло что-то. Симптомы:
1) на сата дисках чтение 5Mb/s
2) на ссд диске запись только 0.5Mb/s. Хотя должна быть те же 5Mb/s, ибо всё что читается с сата потом сразу кладётся в кэш ссд.
3) запросы время от времени подвисают на 5-10-15 секунд. Причём в них нет никакого криминала - обычная отдача малоиспользующейся картинки размеров в 500Кб.
Начал грешить на nginx - что он почему-то не записывает в кэш то, что отдаёт бэкэнд. Долго мучался - ничего не смог выяснить. Решил раньше времени переносить на новый сервер бэкэнд - должно хотя бы распределить нагрузку.
Во время rsync понял в чём проблема была - все картинки у меня складываются в одну директорию. И теперь она выглядит так:
drwxrwxrwx 2 root root 59M Jan 30 19:58 pics
Можно заметить, что размер директории - 59Мб. Похоже из-за возросшей нагрузки она вытеснялась из файлового кэша и очередной запрос на 500Кб хотел открыть эту директорию, что заставляло его читать все 59Мб и тормозить всю систему.
Здесь мы собираем самые интересные картинки, арты, комиксы, мемасики по теме (+21 постов - )
Наши любимые теги
Wapaper
artist
Подземелье Мраморных Врат
Комиксы
kurokimoko
Anime Artist
EGS халява
Epic Games Store
VanRipper
artist
BasedBinkie
artist
Топ комментов
А бывает, комменты лучше постов. Смотрим топ тредов и вникаем!