Nginx PHP не выполняет сам и прав никаких у него быть не должно .
Смысл вообще подобное по форумам спрашивать? Ни у кого кроме вас нет доступа к логам/конфигам, никто ни малейшего представления тут не имеет что там происходит.
Все ответы всегда в логах. Если в логах нет, значит не включено (не достаточно детально) включено логирование.
Failed to start the session - более-менее однозначно говорит о том что нету доступа на создание файла сессии... у кого? Нам-то откуда знать?
Видимо у пользователя под которым работает у вас PHP-FPM (или что другое, кто знает).
Скорей всего session.save_path указывает на /tmp и возможно (верней так лучше и делать всегда) на /tmp стоят права типа 000, т.е. никто кроме root'а не может туда ничего писать.
Задайте в php.ini session.save_path куда-то в доступности этого пользователя.
Верно что понижение частоты под нагрузкой - это нормально. Но тут еще важно понимать чем это частоту смотреть. Windows в диспетчере показывает одну какую-то общую частоту, неизвестно откуда взятую. Т.к. у каждого ядра она может быть своя и постоянно меняться. Под linux например можно так посмотреть в реальном времени: watch -n1 "more /proc/cpuinfo|grep MHz"
А вот аналог того что windows рисует: watch -n1 "lscpu | grep 'MHz' | awk '{print $1}'"
Т.е. не совсем точная картина, а что-то среднее.
Турбо частота обычно указывается для 1 активного ядра. Т.е. одно к примеру 4.1ггц, а остальные 4-3.9ггц. От конкретной модели процессора зависит, может быть что и на всех ядрах макс. турбо, а может наоборот только на 1-2х избранных ядрах изредка быть турбо, а на остальных ну ни в какую никогда выше all-core turbo не повысится.
Чем больше ядер нагружать, тем частота ниже вплоть до all-core turbo (которое еще попробуй найди в инете для нужного cpu, обычно только лично пробовать).
Самые новые процессоры имеют несколько "слоев" турбочастот, может даже чуть выше указанной основной турбо-частоты повышаться иногда:
https://www.anandtech.com/show/16564/intels-new-adaptive-boost-technology-floating-turbo-comes-to-rocket-lake
Короче это сложная тема. По-сути самое важное это all-core turbo, даже не базовая частота. Ну а все что свыше all-core можно рассматривать как приятный (но непостоянный) бонус.
В вашем же случае скорей всего что-то аппаратно не так, 80гр - это прилично много и действительно уже может не только турбо не быть, но и троттлинг.
Проверить тоже легко - скачать и установить aida64. Вот наглядные графики с красным троттлингом и без него: https://habr.com/ru/post/410741/
Надо смотреть во-первых обороты вентиляторов, должно ж идти с сервером какое-то управление, IPMI или аналог.
Но с другой стороны если сервер арендный, действительно проще всего попросить заменить на другой. Т.к. без физического доступа ничего с температурой особо не сделать (кроме как попробовать принудительно включить все вентиляторы на максимум).
80 это много.
есть ли доступ к ipmi или типа того? надо посмотреть для начала обороты вентилятора - в простое и под нагрузкой, меняются ли.
посмотреть "fan mode" или как оно там может называться. попробовать принудительно поставить на full speed.
но также не исключено, что програмно ничего не поделать. например может быть термопасты нет вообще или надо ее обновить. может радиатор блондинка ставила (я наблюдал случаи когда ребра радиатора стояли поперек потоку от вентиляторов). ну или просто вентилятор стоит неподходящей производительности.
Приложение ваше POST'ит что-то на xmlrpc.php скорей всего и точно так же делает множество ботов-брутфорсеров. Это и небезопасно и создает нагрузку на cpu когда они шлют десятки запросов в секунду.
Скорей всего защита у хостингов этих считает вас одним из подобных ботов. На форуме тут никто вам не поможет ничем, только в поддержку обращаться и спрашивать варианты либо отключения защиты для вашего сайта или занесения ip в белый список.
У меня аналогично по-умолчанию все сайты от подобного защищены и лишь изредка подобные проблемы возникают, когда чем-то сторонним пытаются с сайтоми работать. Но все решаемо , надо просто обратиться в поддержку и внятно описать проблему/задачу, а не скакать по хостингам. Эта защита (на уровне сервера) эффективней, чем через плагинчики в самом wp, которые еще и очень малый % пользователей ставит, да и вообще заморачивается какой-либо безопасностью.
Верно мыслите.
А с таким "огромным" траффиком скорей всего будет достаточно даже shared хостинга руб за 250, а не за 2500. Хотя надо видеть сами сайты конечно...
И вы впервые сюда заглядываете похоже... А сейчас еще раз покажите что там днем, ла 50+ небось. Я LA 50-70 видел лишь пару раз на beget'е, но там правда и процессоры с 50+ ядер.
Если LA (load average на вашем скрине вверху справа) больше количества ядер процессора, то это уже очень плохо.
Даже если он за 1 выходит, это уже повод начать разбираться что не так, что можно сделать чтоб облегчить нагрузку.
Видите же что mysql на 200% грузит процессор. Надо понять чем именно. Например почему при доступных 16гб памяти, mysql занимает только 2? Если базы небольшие и этого достаточно, то ладно, но подозреваю что это не так и надо что-то менять.
Потом, говорите при увеличении KeepAliveTimeout становится еще хуже, а на скрине вижу лишь 5 процессов apache. Если он еще и в prefork режиме работает, учитывая что он там один, без nginx'а... разрывается и статику отдавать и ждать ответа от скриптов. Возможно стоило бы повысить значение maxrequestworkers. Ну а в идеале поставить nginx на фронт.
Дальше, что еще за php процессы от root'а? Это точно нужно чтоб так было?
Короче все плохо и без ssl.
...ну или просто после правки конфига вы перегрузили апач и из-за этого проблема ушла (возможно временно), а вовсе не от смены 5 на 3 :)
Чтож, давайте тоже поиграю в гадалку.
У вас там в конфиге том фигурирует где-то что-то про ocsp stapling?
Есть опыт когда оно вызывало подобные тормоза при подключении. Верней не оно само, а временные проблемы со связью между сервером и указанными у него dns resolver'ами.
Т.е. на одном сервере тупило, а на другом в другом дц все нормально было в одно и то же время. И стоило закомментировать в конфиге (правда nginx, а не apache) строчки с ssl_stapling и все приходило в норму.
Решилось в итоге установкой локального кэширующего dnsmasq, чтоб все на сервере обращалось сперва к нему с dns запросами, а не сразу куда-то там по сети к "супер-быстрым" и "надежным" 8.8.8.8 да 1.1.1.1
Но конечно это все может быть мимо и совершенно не ваш случай... кто ж вас знает шифровальщиков.
А нельзя просто дать ссылку на сайт? Такие все стеснительные, куда там... и сидите все гадайте - а может то, а может сё.
Вас бьют за каждое такое обращение? Это самый правильный и действенный метод. Да и куда быстрей должно быть, чем по форумам ответы ждать.
