Что-то в последнее время у меня слишком много админских событий, что не очень радует... не люблю я нервничать.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
Сегодня в комментах я расскажу про проблему, что была сегодня. Прилагаю график просмотров. Видно, что количество просмотров упало в 2 раза.
Еще на тему
Запустил я синхронизацию где-то в 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) ставим своп на мониторинг. Пока ничего не свопилось...
А то у меня на работе обычно "ну я хуйнул этот патч, и вроде заебись, а чо, ёба?"
В данном случае, php-fpm просто немного отсрочил бы падение. Но не думаю, что сильно =).
По поводу скорости - то же самое. В гугле пишут, что чистая скорость в качестве бэкэнда у всех почти одинаковая.
Вот чувак не может настроить 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
В качестве фротэнда апач нельзя использовать, это да. А вот что использовать в качестве бэкэнда - это по сути всё равно.
То есть,
apache << nginx + any
nginx + apache =~= nginx + php-fpm
http://www.liveinternet.ru/stat/joyreactor.ru/mins.html
(как я помню) процесс апача включает все его модули, те если у тебя включены mod_php mod_python, то все это будет включено в процесс, даже если ты отдаешь 404.
Те это оптимизация по памяти, а не по быстродействию.
Как говорили парни из disqus - "не важно что ты юзаешь апач или нжинХ - горлышко это твой код"
Это как придирка - в любом случае ты никого тут не послушаешь и сделаешь по-своему
xD
К списку своих экспериментов посмотри на https://code.google.com/p/leveldb/
Кроме шуток - попробуй похранить картинки в бд.
Ну и пора уже высматривать параметры ядра связанные с кешами.
ИМО играться с кластеризацией ФС не стоит - там все равно будет единая точка отказа и чем крече система, тем глебже в коде она будет.
Сконцентрируйся на разделении контента по разным серверам как это делают в вк/фб
leveldb написано "Only a single process (possibly multi-threaded) can access a particular database at a time." - а значит тоже есть единая точка отказа.
Я думал по поводу Cassandra - ещё попробую её потестить.
тема такая: когда открываю на реакторе любой пост с большим количеством комментов и картинок в них, страница начинает скролиться с дикими тормозами, на других сайтах не наблюдай. браузер хром.
2) стоят какие-то плагины?
если проблема появится снова - отпишусь. плагина стоит 2: addblock и gismeteo.
С этим вообще интересно поэксперементировать, как фронтендщику.
:3
Сейчас смотрю в сторону openstack swift
давно хочу его запустить в продакшен, проект вроде бы достойный, но ссыкатно - саппорта нет, опыта реальной работы мало и документации кот наплакал