Повлияет ли переключение Ubuntu clocksource с xen на tsc на php/Laravel приложение?

Question

Фон

Мы начали использовать новую реликвию на нашем сервере приложений laravel (размещенном на ubuntu ec2), но затем сразу заметили скачок задержки в наших облачных часах aws:

Новая служба поддержки реликвий немедленно предложила нам переключить наш источник синхронизации с xen на tsc:

Похоже, что источник синхронизации в вашей системе не поддерживает vDSO. Поскольку агент PHP сильно зависит от системного вызова gettimeofday() для определения продолжительности времени сегментов и транзакций, clocksource играет большую роль в предотвращении попадания системных вызовов в саму систему, что значительно ускоряет процесс.

В этом конкретном сценарии мы рекомендуем использовать tsc clocksource. Мы увидели большой прирост производительности при включенном tsc clocksource, и я хотел бы спросить, можно ли временно включить tsc clocksource, чтобы увидеть, уменьшаются ли накладные расходы.

Если New Relic является единственным приложением, для которого требуется точная синхронизация, или если вас интересует только точное измерение более коротких периодов времени, tsc - хороший выбор для часовых источников.

Я провел быстрый поиск различий между двумя источниками часов и не нашел никаких гигантских красных флажков (здесь были упомянуты следующие проблемы: TSC, однако, имеет свои проблемы, в том числе:

• Его частота неизвестна, и его необходимо измерять с помощью таймера PIT, CMOS или ACPI.
• Регистр доступен для записи, и чтение может отличаться на разных процессорах.
• TSC может останавливаться в некоторых состояниях C процессора с низким энергопотреблением. Обычно это не происходит на современном оборудовании.
• В прошлом наблюдалось нарушение синхронизации TSC в некоторых крупных системах NUMA. К счастью, количество таких систем было ограничено.
• Обработчики SMI могут сбросить счетчик.

Все это звучит для меня чуждо, но кажется, что они имеют отношение только к потребностям в хранении микро времени (таких как профилировщики и т. Д.), И я не думаю, что это действительно актуально для приложения php / laravel, где мы можем допустить неточность в время с порогом до 3 секунд (но не более, так как наше приложение полагается на уведомления пользователей в режиме реального времени).

Я прав с моим предположением?

Приложение I: инструкции от новой команды поддержки реликвий о том, как перейти с xen на tsc:

Чтобы установить текущий источник синхронизации на другое значение

Запустите bash от имени суперпользователя, чтобы переопределить current_clocksource:

sudo bash -c 'echo tsc> / sys / devices / system / clocksource / clocksource0 / current_clocksource' Запустите команду dmesg, чтобы просмотреть сообщения ядра:

Dmesg | less Если переопределение прошло успешно, появится следующее сообщение:

clocksource: переключен на clocksource tsc

Answer 1

Я провел много исследований на эту тему на этой неделе. Мой стек очень похож на ваш, с той лишь разницей, что я использую ECI Optimized AMI.

Если вашему приложению не нужна точность в мили-секунды, вам следует переключиться на TSC. Убедитесь, что вы работаете в новом поколении с обновленным ядром. Это воздействие, которое я видел, в основном половина случаев: https://imgur.com/TllxFXs

AWS рекомендует использовать собственный сервис для синхронизации времени: https://aws.amazon.com/blogs/aws/keeping-time-with-amazon-time-sync-service/

Я все еще организую свои ссылки, дайте мне знать, если вам нужно больше информации.