Украина в основном. Но и вижу у конкурентов тоже падение неплохое.. при чем только вчера в обед началось
Ставлю на пасху. По опыту прошлых лет в пасху воронка провала больше чем в новый год. Кроме того в этом году она поздняя, вместе с майскими, плюс погода, плюс локдаун. Народ еще с той недели разбегается по дачам. Провала по позициям, как в полноценный ап, я так же не вижу.
Какое гео? В православных странах траф падает еще с той недели, позиции +- на месте. Списываю на приближение пасхи и других праздников. А вот в мусульманских азиатских странах всё ровно, даже рост.
Видите же что mysql на 200% грузит процессор. Надо понять чем именно. Например почему при доступных 16гб памяти, mysql занимает только 2? Если базы небольшие и этого достаточно, то ладно, но подозреваю что это не так и надо что-то менять.
Все базы на myisam-таблицах. Они выбраны ради быстрых SELECT в сравнении с InnoDB. На них нежелательно выделять более 25% памяти сервера, так как в ней только ключи, данные файловая система ОС кеширует сама. Та память что под них отдана используеться на 70%. Соотношение чтения ключей с запросами на чтение хорошее, тут всё норм. Запросы летают.
Дальше, что еще за php процессы от root'а? Это точно нужно чтоб так было?
Есть скрипты работающие с файловой системой сервера и требующие много времени, их лучше запускать под рутом с большими правами, чем те что работают на юзера.
Всем добрый день.
Так выглядит top днём при:
KeepAliveTimeout 20
<IfModule mpm_prefork_module>
StartServers 100
MinSpareServers 100
MaxSpareServers 200
MaxClients 256
MaxRequestsPerChild 0
</IfModule>
Это параметры подобранные опытным путём для прежнего быстродействия при KeepAliveTimeout 20
KeepAliveTimeout 3 выручил при:
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
На VPS 6 ядер. При нынешних параметрах выросло количество тасков, но визуально на производительность не повлияло, посмотрю как это оценят роботы гугла.
Изначально ОС ставилась давно на сервер с 1 ядром и 512 мб оперативы, далее ядра и оператива наращивались без внесения изменений в конфиг апача.
Правда это ночь, нагрузка сильно ниже.
Что такое La?
На сервере больше 100 виртуальных хостов. Разные проекты, сетки, эксперименты. Почти все с SSL сертификатами. Около 70 уже не активны и не продлены. Я их поудалял, вычистил ненужные сертификаты. Но это всё никак не мешало до 17 марта и удаления ничем не помогли.
Ну и да, один сертификат старый был выписан на 100 доменов. Но отвалился и не использовался уже давно и его удаление ни на что не повлияло.
...ну или просто после правки конфига вы перегрузили апач и из-за этого проблема ушла (возможно временно), а вовсе не от смены 5 на 3 :)
Чтож, давайте тоже поиграю в гадалку.
У вас там в конфиге том фигурирует где-то что-то про ocsp stapling?
Есть опыт когда оно вызывало подобные тормоза при подключении. Верней не оно само, а временные проблемы со связью между сервером и указанными у него dns resolver'ами.
Т.е. на одном сервере тупило, а на другом в другом дц все нормально было в одно и то же время. И стоило закомментировать в конфиге (правда nginx, а не apache) строчки с ssl_stapling и все приходило в норму.
Решилось в итоге установкой локального кэширующего dnsmasq, чтоб все на сервере обращалось сперва к нему с dns запросами, а не сразу куда-то там по сети к "супер-быстрым" и "надежным" 8.8.8.8 да 1.1.1.1
Но конечно это все может быть мимо и совершенно не ваш случай... кто ж вас знает шифровальщиков.
Нет, одна перезагрузка апача ничего не решила, так как предпримал ее неоднократно в процессе поиска решения. Про ocsp stapling в курсе, у меня его нет, при попытке впихнуть его отключение в конфиг апач ругнулся что хз что это такое.
По рекомендации с англ форума поставил 50 и проблема усугубилась на столько, что первого открытия я ждал по несколько минут, в 2 из 3 попыток соединение вообще сбрасывал сервер по таймауту. Ну а вторая и следующие страницы после первого летали как и прежде.
Пошёл в обратную, поставил 3, и всё вернулось к адекватным показателям.
