Сайт изредка оказывается по наплывом посетителей и перестает справляться с нагрузкой. Больше всего проблем создает поиск SOLR. Вынести поиск на отдельный сервер пока возможности нет.
Вопрос такого плана. Как бы с наименьшим кровопролитием организовать отключение поиска при достижении в статусе Апач количества воркеров близким к максимальному. Затем обратно включать, при снижении количества активных воркеров.
Можно даже не поиск отключать, а начинать тупо перенаправлять при запросе search на страницу, где написано, что сайт перегружен запросами, приходите позже. Solr не хочется вообще трогать - нежный он.
Комментарии
Улучшить характеристики сервера тоже нет возможности?
На мой взгляд, выжато все до предела. Даже кэширование esi для авторизованных через varnish настроено. Проблема, что поиск реально сложный, внутри него много всяких обработок + нечеткий поиск и прочие плюшки сделаны. А записей на сайте более миллиона.
UPD Я не правильно понял вопрос. Нет, железяку помощнее не получается. Как медвед говорил - денег нет, но держитесь там.
Так может solr проще на отдельный сервер перекинуть?
Это точно дешевле разраба в вашем случае, если делать красиво.
Или апач выкинуть, вы вроде ресурсы экономите.
А если некрасиво, тупо сообщать, что поиск не работает, приходите позже, тогда да, малой кровью можно отделаться.
Ну написал же. Нет денег на еще сервер. Моя бы воля - я бы вообще все по серверам раскидал и балансировщик прикрутил.
Да. Надо тупо сообщать, что не работает. Но не могу же я сам сидеть и следить за статусом апач и сообщения слать?
Ну значит дёргайте инфу через server status или как там у вас сделано, может по крону, может прям в момент загрузки страницы поиска.
Можно сделать через access callback и в нем проверять полученное на шаге ранее.
Сервер свободен - окей, пускаем юзера.
Не свободен - гуляйте, ой, ошибку даём, или элементы формы скрываем, или ещё чего.
Возникала проблема с нехваткой ресурсов.
Решилась заменой apache2 на nginx + php-fpm.
Не смог найти, server status парсить надо, или есть какой-то способ что нибудь типа json получить?
Тут уже от того, что у вас есть зависит.
Может у вас заббикс или мунин стоят, можно оттуда данные взять, например.
Может ещё что-то.
И еще, кроме сервер статус, как нибудь можно получить количество "requests currently being processed" безвключения этого самого серверстатус модуля?
У меня проблема не в скорости обработки скриптов, а в скорости работы поискового сервера.
У вас проблема в нехватке ресурсов на сервере и апач там самое жрущее звено
Похоже, я косноязычен и не могу внятно объяснить свою проблему. На сервере работает поиск solr - перегруженный всякими фишками. Поиск тормозит работу всей системы. Бывает редко, но метко - поиск перестает справляться с количеством запросов. Его надо отключать в такие редкие счастливые моменты.
Что касаемо апача - ресурсов достаточно. Есть даже свободная неиспользуемая память. Но какой смысл добавлять дополнительные воркеры, если процессор не успевает работать с поиском. Эти воркеры так же будут забиты запросами.
Вам пытаются сказать, что если заменить apache на nginx, то вашему solr'у будет доставаться больше ресурсов сервера
Там процессор тупо не успевает. На сервере 64 ГБ оперативки, установлены твердотельники.
А что с БД?
Вот неплохое решение с переносом tmpdir в tmpfs - разгружает I/O, а проц может и туда упираться.
Все верно. Давно уже сделано. В общем-то весь tmp в tmpfs смонтирован.
удалено - плохо прочитал ответ...
Это один из вариантов решения проблемы.
Другой - добавить ресурсов солру, забрав их у вебсервера.
В моем случае картина была такой: израсходовано 32Gb памяти, несколько гиг в свопе, LA ~10+ на 4 физических ядрах.
После перенастройки - расход памяти уменьшился до 15-20Gb, своп не используется, LA =< 4.
Понятно всё. Но у меня на сервере памяти с избытком. Самое узкое место - процессор, так скажем, или алгоритм работы солр хромает, который я править не собираюсь естественно.
Кстати, раньше использовался сфинкс - вот он летал. Реально. Но по некоторым техническим причинам пришлось на солр перейти. А вообще - сфинкс всем рекомендую. Классный движок.
Теоретически, на примере nginx - создать под поиск новый location с низким таймаутом, по таймауту отправлять на специфичную страницу ошибки. Ну то есть, если страница поиска отрабатывает больше 5 секунд - солру нездоровится, попробуйте позднее.
Можно и так, но таймаут не лучшая идея на мой взгляд. Юзеров будет напрягать. Лучше не доводить до крайностей.
У вас на соларе только поиск или ещё и фасеты? Если фасеты, то нагрузку дают ещё и запросы к страницам каталога. Посмотрите в настройках джавы, может там лимиты маленькие.
В конфигах из коробки, солру выделено 512М, что на больших индексах, разумеется, мало.
Особенно, если с полями документов производится постпроцесс навроде full text поиска.
У меня solr в настройках 2Gb. Хватает с избытком
В жаву не совался. Буду смотреть. Если подскажете - буду признателен.
SOLR_JAVA_MEM
!!!! Спасибо нашел. /etc/default/solr.in.sh
Теоретически - срипт мониторинга, который тупо отслеживает сколько проца отожрал солр, если больше какого-то значения - создавать писать в какое-либо доступное для друпала место (файлик в tmp, redis, drush vset, абстрактную систему мониторинга), мол баста карапузики, солр на ресурсной диете. Далее, уже в друпале, непосредственно перед поиском, проверять досутпен ли поиск по этому значению, да - ищем, нет - показываем message, мол попробуйте позднее.
Да. Так, наверное, будет красивое решение.
UPD И да, я понимаю, что с большой долей вероятности, я джаву с солр неправильно настроил, но пока разберусь... много времени может уйти.