Регистрация Войти
Рейтинг:0
avatar Server

Медленное время отклика, когда сервер простаивает, быстрое время отклика, когда сервер загружен?

флаг dk
Kalvin Klien

Я использую сервер с 40 потоками / 125 ГБ ОЗУ.

Сервер основан на CentOS 7.

Я заметил, что время отклика сервера выше, когда сервер простаивает:

введите описание изображения здесь

На скриншоте здесь видно, что ответ сервера между 16:00 и 22:00 был ниже, чем в другое время.

Я просмотрел логи и обнаружил, что в тот момент GoogleBot выдавал нам 4 запроса в секунду, что нагружало сервер. Большинство запросов от GoogleBot были 302 редиректами (большой каталог электронной коммерции с ежедневными изменениями в живых продуктах).

введите описание изображения здесь

Здесь вы можете увидеть пропускную способность сервера - в то время, когда сервер был занят, время отклика было низким.

Как я могу отладить это?

Что вызывает это?

Может ли 302 редиректа быть дешевле, чем 200 ответов, искажающих данные?

Может ли кеш (Redis / Opcache / APCu) очищаться слишком рано, что приводит к воссозданию кеша во время простоя?

В настоящее время мы работаем: Апач 2.4 Nginx-прокси MySQL Редис Opcache APCu Эластичный поиск

ОБНОВИТЬ:

Глядя на отдельные процессы, PHP занимает больше всего времени:

введите описание изображения здесь

MySQL несколько коррелирует с PHP, но не полностью:

введите описание изображения здесь

34
0 + 0
djdomi avatar
флаг za
djdomi
Отвечает ли это на ваш вопрос? [Можете ли вы помочь мне с планированием емкости?](https://serverfault.com/questions/384686/can-you-help-me-with-my-capacity-planning)
0
Ответить
флаг dk
Kalvin Klien
@djdomi На самом деле это не вопрос мощности - это вопрос о том, почему, когда сервер простаивает, время отклика выше, чем когда сервер загружен. Могут ли быть какие-то особые настройки, которые я должен использовать для уменьшения времени отклика, когда сервер простаивает? Я поговорил со своим серверщиком, и он сказал, что это может быть из-за того, что 302 запроса дешевле, чем 200, поэтому данные могут неправильно интерпретироваться из-за дешевых 302 запросов.
0
Ответить
Hagen von Eitzen avatar
флаг cn
Hagen von Eitzen
Причина, вероятно, примерно такая: в состоянии занятости наиболее важные части уже кэшированы в ОЗУ из предыдущего запроса (каталоги, статические файлы, php-скрипты, возможно, даже байт-код PHP и даже запросы SQL), тогда как во время простоя каждый запрос возможно, придется загрузить почти все с диска.Если весь ваш *сервер* представляет собой виртуальную машину, может даже случиться так, что для получения ресурсов также потребуется немного времени.
1
Ответить
флаг dk
Kalvin Klien
@HagenvonEitzen хммм, но из графиков видно, что между странными состояниями низкого и высокого времени отклика проходит не так уж много времени. Я думаю, что графики между переходами будут более плавными. Сервер оснащен дисками NVME и на самом деле не тормозится ими (3500 МБ/с). Большая часть данных уже находится в оперативной памяти, и мы используем только около 70 ГБ из 125 ГБ.
0
Ответить
флаг dk
Kalvin Klien
К вашему сведению, это голая система с дисками NVME, 125 ГБ ОЗУ, 2xCPU / 40 потоков.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.