Долгое ожидание первой страницы (не только главной)

Результаты теста без адреса сайта выложите (скриншотами хотя бы)

Я не знаю как это связано, но после изменения KeepAliveTimeout с 5 на 3 проблема ушла, и пока воспроизвести ее не удалось. Это по наставлениям с англ форумов, хотя там увеличили, а мне помогло уменьшение.

...ну или просто после правки конфига вы перегрузили апач и из-за этого проблема ушла (возможно временно), а вовсе не от смены 5 на 3 :)

Чтож, давайте тоже поиграю в гадалку.

У вас там в конфиге том фигурирует где-то что-то про ocsp stapling?

Есть опыт когда оно вызывало подобные тормоза при подключении. Верней не оно само, а временные проблемы со связью между сервером и указанными у него dns resolver'ами.

Т.е. на одном сервере тупило, а на другом в другом дц все нормально было в одно и то же время. И стоило закомментировать в конфиге (правда nginx, а не apache) строчки с ssl_stapling и все приходило в норму.

Решилось в итоге установкой локального кэширующего dnsmasq, чтоб все на сервере обращалось сперва к нему с dns запросами, а не сразу куда-то там по сети к "супер-быстрым" и "надежным" 8.8.8.8 да 1.1.1.1

Но конечно это все может быть мимо и совершенно не ваш случай... кто ж вас знает шифровальщиков.

Это не в тему но такой маленький параметр KeepAliveTimeout (что 3, что 5) ставится когда совсем мало ресурсов на сервере. Если с ресурсами всё в порядке (под типовой нагрузкой) то где-то в районе 60 самое оно. Или у Вас на сайте нет страниц на которых можно зависнуть больше чем на пару секунд :))) ?

Нет, одна перезагрузка апача ничего не решила, так как предпримал ее неоднократно в процессе поиска решения.  Про ocsp stapling в курсе, у меня его нет, при попытке впихнуть его отключение в конфиг апач ругнулся что хз что это такое.

По рекомендации с англ форума поставил 50 и проблема усугубилась на столько, что первого открытия я ждал по несколько  минут, в 2 из 3 попыток соединение вообще сбрасывал сервер по таймауту. Ну а вторая и следующие страницы после первого летали как и прежде.

Пошёл в обратную, поставил 3, и всё вернулось к адекватным показателям.

А LA какой ? Может и правда сервер просто по ресурсам тормозит, а сайт под мини-ддосом ? И если соединения быстро не рвутся то это приводит к тормозам ?

Что такое La?

На сервере больше 100 виртуальных хостов. Разные проекты, сетки, эксперименты. Почти все с SSL сертификатами. Около 70 уже не активны и не продлены. Я их поудалял, вычистил ненужные сертификаты. Но это всё никак не мешало до 17 марта и удаления ничем не помогли.

Ну и да, один сертификат старый был выписан на 100 доменов. Но отвалился и не использовался уже давно и его удаление ни на что не повлияло.

Если в терминале (Линукс) выполнить команду "top" то в выводе справа вверху будут три цифры под общим названием load average :)

Правда это ночь, нагрузка сильно ниже.

И вы впервые сюда заглядываете похоже... А сейчас еще раз покажите что там днем, ла 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.