Мы начали использовать новую реликвию на нашем сервере приложений laravel (размещенном на ubuntu ec2), но затем сразу заметили скачок задержки в нашем облачном хранилище aws:
Новая техническая поддержка реликвий сразу же предложила переключить наш источник синхронизации с xen на tsc:
Похоже, что источник синхронизации в вашей системе не поддерживает vDSO.
Поскольку агент PHP сильно зависит от системного вызова gettimeofday ()
определить продолжительность отрезков и транзакций,
Clocksource играет большую роль в предотвращении попадания системных вызовов
сама система, которая значительно ускоряет процесс.В этом конкретном сценарии мы рекомендуем использовать tsc clocksource. Мы
видел большой прирост производительности с включенным TSC Clocksource и я
хотел бы спросить, можно ли временно включить
тактовый источник tsc, чтобы увидеть, уменьшаются ли накладные расходы.Если New Relic — единственное приложение, для которого
требуется, или если вас интересует только точное измерение
Более короткая длительность — хороший выбор для часовых источников.
Я сделал быстрый поиск на разницу между двумя источниками часов, и не нашли никаких гигантских красных флагов (были эти проблемы, которые были упомянуты здесь:
TSC, однако, имеет свои проблемы, в том числе:
- Его частота неизвестна, и его нужно измерять с помощью PIT, CMOS,
или таймер ACPI.- Регистр доступен для записи, и чтение может отличаться
разные процессоры.- TSC может остановиться в некоторых состояниях C с низким энергопотреблением
процессор. Обычно это не происходит на современном оборудовании.- TSC получение
несинхронизация в некоторых больших системах NUMA наблюдалась в прошлом.
К счастью, количество таких систем было ограничено.- Обработчики SMI могут сбросить счетчик.
Все это звучит для меня чуждо, но кажется, что они имеют отношение только к потребностям в хранении микро времени (таких как профилировщики и т. Д.), И я не думаю, что это действительно актуально для приложения php / laravel, где мы можем допустить неточность в время с порогом до 3 секунд (но не более, так как наше приложение полагается на уведомления пользователей в режиме реального времени).
Я прав с моим предположением?
Чтобы установить текущий источник синхронизации на другое значение
Запустите bash от имени суперпользователя, чтобы переопределить current_clocksource:
sudo bash -c ‘echo tsc>
/ sys / devices / system / clocksource / clocksource0 / current_clocksource ‘Выполнить
команда dmesg для просмотра сообщений ядра:Dmesg | less Если переопределение прошло успешно, появится следующее сообщение
появляется:clocksource: переключен на clocksource tsc
Я провел много исследований на эту тему на этой неделе. Мой стек очень похож на ваш, с той лишь разницей, что я использую ECI Optimized AMI.
Если вашему приложению не нужна точность в мили-секунды, вам следует переключиться на TSC. Убедитесь, что вы работаете в новом поколении с обновленным ядром. Это влияние, которое я видел, в основном половина случаев: https://imgur.com/TllxFXs
AWS рекомендует использовать собственный сервис для синхронизации времени: https://aws.amazon.com/blogs/aws/keeping-time-with-amazon-time-sync-service/
Я все еще организую свои ссылки, дайте мне знать, если вам нужно больше информации.
Других решений пока нет …