Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
Что-то в последнее время у меня слишком много админских событий, что не очень радует... не люблю я нервничать.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
28.03.2013, 14:10
После неудачных попыток с ceph, я не опустил руки. И сейчас пытаюсь собрать кластер на iscsi + lvm + gfs2. По сути, это рейд между серверами. Он уже сконфигурирован и я запустил его синхронизироваться. При этом просто оба диска на двух серверах заполняются одинаковыми нулями. Таким образом, после начальное синхронизации они будут полностью одинаковыми и дальше можно будет синхронизовать только изменения.
Запустил я синхронизацию где-то в 12-13 и пошёл спать (мама заставляет меня спать днём - говорит так расту быстрее). А через 2 часа вдруг начался какой-то пипец.
Пропущу, как я расследовал это и сразу перейду к результатам расследования:
1) на одном из серверов сервис iscsi начал радостно писать на диск изменённые данные. Ничего не предвещало беды.
2) писать надо было много, поэтому ядро начало активно использовать память для кэширования данных, которые надо записать на диск. Надо сказать, что памяти там было навалом. 16Гб всего. Из них 5Гб используются на мемкэш и 1Гб на всякие апачи.
3) ядро скушало оставшиеся 10Гб памяти под дисковые кэши и подумало что ему мало. Но памяти уже нет. Значит надо или умерить свои дисковые кэши, или начать свопить.
4) проведя беглый анализ, ядро решило, что мемкэш использует кучу памяти, но к части из неё обращается редко. И решило его засвопить.
5) мемкэш начинает потихоньку перекидываться в своп. Там и вправду есть элементы, к которым обращаются раз в неделю. Но так как этих элементов там дофига, то постепенно вероятность попадания запроса в своп всё росла и росла
6) установилась положительная обратная связь:
- апач с большой вероятностью "попадает" в своп при обращении к кэшу в мемкэше.
- из-за этого количество процессов апача начало расти (ибо каждый стал дольше ждать когда мемкэш ответи).
- из-за этого апач стал кушать больше памяти.
- из-за этого ядро стало с ещё большими усилиями свопить мемкэш.
- из-за этого апач с большое вероятностью попадает в своп.
Когда я проснулся и скушал полдник (стакан молока с печенькой), то обнаружил такую картину:
1) запросы выполняются по 15-30 секунд.
2) мемкэш на 3.5Гб засвоплен.
3) большая часть памяти отдана ядру под буферы ввода-вывода
Запустил я синхронизацию где-то в 12-13 и пошёл спать (мама заставляет меня спать днём - говорит так расту быстрее). А через 2 часа вдруг начался какой-то пипец.
Пропущу, как я расследовал это и сразу перейду к результатам расследования:
1) на одном из серверов сервис iscsi начал радостно писать на диск изменённые данные. Ничего не предвещало беды.
2) писать надо было много, поэтому ядро начало активно использовать память для кэширования данных, которые надо записать на диск. Надо сказать, что памяти там было навалом. 16Гб всего. Из них 5Гб используются на мемкэш и 1Гб на всякие апачи.
3) ядро скушало оставшиеся 10Гб памяти под дисковые кэши и подумало что ему мало. Но памяти уже нет. Значит надо или умерить свои дисковые кэши, или начать свопить.
4) проведя беглый анализ, ядро решило, что мемкэш использует кучу памяти, но к части из неё обращается редко. И решило его засвопить.
5) мемкэш начинает потихоньку перекидываться в своп. Там и вправду есть элементы, к которым обращаются раз в неделю. Но так как этих элементов там дофига, то постепенно вероятность попадания запроса в своп всё росла и росла
6) установилась положительная обратная связь:
- апач с большой вероятностью "попадает" в своп при обращении к кэшу в мемкэше.
- из-за этого количество процессов апача начало расти (ибо каждый стал дольше ждать когда мемкэш ответи).
- из-за этого апач стал кушать больше памяти.
- из-за этого ядро стало с ещё большими усилиями свопить мемкэш.
- из-за этого апач с большое вероятностью попадает в своп.
Когда я проснулся и скушал полдник (стакан молока с печенькой), то обнаружил такую картину:
1) запросы выполняются по 15-30 секунд.
2) мемкэш на 3.5Гб засвоплен.
3) большая часть памяти отдана ядру под буферы ввода-вывода
ну и решение было простое и быстрое:
1) перезагружаем мемкэш (регенерация кэша идёт достаточно быстро и производительность проседает в основном только в первые секунды)
2) устанавливаем vm.swappiness=10 вместо дефолтного vm.swappiness=60
3) ставим своп на мониторинг. Пока ничего не свопилось...
1) перезагружаем мемкэш (регенерация кэша идёт достаточно быстро и производительность проседает в основном только в первые секунды)
2) устанавливаем vm.swappiness=10 вместо дефолтного vm.swappiness=60
3) ставим своп на мониторинг. Пока ничего не свопилось...
Приятно почитать, как проблема действительно анализируется до конца.
А то у меня на работе обычно "ну я хуйнул этот патч, и вроде заебись, а чо, ёба?"
А то у меня на работе обычно "ну я хуйнул этот патч, и вроде заебись, а чо, ёба?"
А вапросик можна? php-fpm не пробовали вместо апача?
вот тут обсуждали - http://joyreactor.cc/post/701470#comment1958089 =)
В данном случае, php-fpm просто немного отсрочил бы падение. Но не думаю, что сильно =).
В данном случае, php-fpm просто немного отсрочил бы падение. Но не думаю, что сильно =).
Так там про cgi, а тут fpm. Бэкенд присоединяется через сокет.
php-fpm - это просто продвинутый fastcgi. Он работает на том же протоколе cgi.
По поводу скорости - то же самое. В гугле пишут, что чистая скорость в качестве бэкэнда у всех почти одинаковая.
Вот чувак не может настроить php-fpm быстрее апача:
http://stackoverflow.com/questions/12056861/configuring-haproxynginxphp-fpm-to-out-perform-apachemod-php
По памяти - сейчас специально зашёл на ресурс, который использует php-fpm. На один процесс php-fpm - 35-40Mb. На один процесс апача - 45-50Mb. Разница небольшая. Если запущено 30 процессов, то разница в 300Мб.
А 30 запущенных процессов - это уже какой-то пипец. Ну и апач намного гибче настраивается
По поводу скорости - то же самое. В гугле пишут, что чистая скорость в качестве бэкэнда у всех почти одинаковая.
Вот чувак не может настроить php-fpm быстрее апача:
http://stackoverflow.com/questions/12056861/configuring-haproxynginxphp-fpm-to-out-perform-apachemod-php
По памяти - сейчас специально зашёл на ресурс, который использует php-fpm. На один процесс php-fpm - 35-40Mb. На один процесс апача - 45-50Mb. Разница небольшая. Если запущено 30 процессов, то разница в 300Мб.
А 30 запущенных процессов - это уже какой-то пипец. Ну и апач намного гибче настраивается
Ну тут как бы "ХЗ", я не гуру и не буду ничего утверждать. Просто спросил. :)
У меня как-то на апаче было запущено более 100 процессов, и ничего - норм всё работало, но после перехода на php-fpm+nginx я вообще забыл про нагрузку на сервер...
p.s. http://tinyurl.com/d27m3kq
У меня как-то на апаче было запущено более 100 процессов, и ничего - норм всё работало, но после перехода на php-fpm+nginx я вообще забыл про нагрузку на сервер...
p.s. http://tinyurl.com/d27m3kq
Ок ок, без проблем. Один вопрос, что за рисовалка/сравнивалка "количества просмотров"?
профит от php-fpm это, в основном, уменьшение потребление памяти.
(как я помню) процесс апача включает все его модули, те если у тебя включены mod_php mod_python, то все это будет включено в процесс, даже если ты отдаешь 404.
Те это оптимизация по памяти, а не по быстродействию.
Как говорили парни из disqus - "не важно что ты юзаешь апач или нжинХ - горлышко это твой код"
(как я помню) процесс апача включает все его модули, те если у тебя включены mod_php mod_python, то все это будет включено в процесс, даже если ты отдаешь 404.
Те это оптимизация по памяти, а не по быстродействию.
Как говорили парни из disqus - "не важно что ты юзаешь апач или нжинХ - горлышко это твой код"
Собственно тесты в вакуууме такими и остаются. Для реальных тестов нужно реальное приложение, те тут нельзя опираться на "в интернете сказали, что так не выстрелит".
Это как придирка - в любом случае ты никого тут не послушаешь и сделаешь по-своему
xD
К списку своих экспериментов посмотри на https://code.google.com/p/leveldb/
Кроме шуток - попробуй похранить картинки в бд.
Ну и пора уже высматривать параметры ядра связанные с кешами.
ИМО играться с кластеризацией ФС не стоит - там все равно будет единая точка отказа и чем крече система, тем глебже в коде она будет.
Сконцентрируйся на разделении контента по разным серверам как это делают в вк/фб
Это как придирка - в любом случае ты никого тут не послушаешь и сделаешь по-своему
xD
К списку своих экспериментов посмотри на https://code.google.com/p/leveldb/
Кроме шуток - попробуй похранить картинки в бд.
Ну и пора уже высматривать параметры ядра связанные с кешами.
ИМО играться с кластеризацией ФС не стоит - там все равно будет единая точка отказа и чем крече система, тем глебже в коде она будет.
Сконцентрируйся на разделении контента по разным серверам как это делают в вк/фб
как раз кластерная фс на то и кластерная, что не будет иметь единой точки отказа.
leveldb написано "Only a single process (possibly multi-threaded) can access a particular database at a time." - а значит тоже есть единая точка отказа.
Я думал по поводу Cassandra - ещё попробую её потестить.
leveldb написано "Only a single process (possibly multi-threaded) can access a particular database at a time." - а значит тоже есть единая точка отказа.
Я думал по поводу Cassandra - ещё попробую её потестить.
Подписался на тег. Маме привет!
линуксоиды... веселые...))) дорогой слетаем в отпуск на гаваи? хорошо дорогая, только сначала изобретем самолет проведем испытания устраним все технические неисправности и вот тогда в путь, ах да дорогая так же необходимо изобрести и самим собрать двигатели, авионику и т.д. и т.п. ...
а да и еще дорогамя нам придется освоить професси пилотов борт инженеров мотористов электриков проэктировщиков и разработчиков и т.д. и т.п. ...
ну так а чо там с gfs2+lvm? неужели работает все хорошо?
Неа, всё плохо =). Оставил кластер на пару дней, пока с основной сервак бэкапился и старые картинки удалял. Сейчас зашёл - там процессор cmirrord жрёт 100% проца. В реальной конфигурации для решения этой проблемы надо перезагружать ноду, у которой это сглючило. Но мирится с тем, что серваки будут перегружаться постоянно из-за мелких багов не хочется.
Сейчас смотрю в сторону openstack swift
Сейчас смотрю в сторону openstack swift
а не ковырял elliptics?
давно хочу его запустить в продакшен, проект вроде бы достойный, но ссыкатно - саппорта нет, опыта реальной работы мало и документации кот наплакал
давно хочу его запустить в продакшен, проект вроде бы достойный, но ссыкатно - саппорта нет, опыта реальной работы мало и документации кот наплакал
