Вопросы Теги

Дрейф времени и неправильный часовой пояс внутри Конфигурация NTP

Предположим, что вы воспроизводите музыку в сжатом формате (MP3, OGG или аналогичном), это не может быть проблемой с диском. Типичный OGG файл имеет битрейт 128-196 кбит/с, т.е. 16-24 КБ/с, что составляет менее 0,5% от типичной пропускной способности жесткого диска. Кроме того, многие проигрыватели кэшируют около 1 Мб файла, который они проигрывают, что означает, что после начала проигрывания музыки ее можно прерывать только примерно раз в минуту из-за плохой производительности жесткого диска.

С другой стороны, декодирование сжатой музыки требует некоторого процессорного времени, так же как и взаимодействие с блютузным донглом и передача звука по импульсному каналу. Я предлагаю проверить использование процессора с помощью top во время заикания звука. Если частота использования процессора достигает 100%, то решением будет запуск загрузчика с помощью nice.

Бонус: И - автоматический славный демон

1
26.03.2018, 17:33
2 ответа

Если ваш /etc/localtimeуказывает на /usr/share/zoneinfo/EET, это определение часового пояса включает европейское летнее время (= европейское летнее время )и между последним воскресеньем марта и последним воскресеньем октября этот часовой пояс будет указан как EEST, а не EET. И на момент написания этой статьи день перехода был только вчера...

Вам следует прочитать Рекомендации VMware по учету времени для виртуальных машин Linux . Короче:

  • Убедитесь, что хост VMware использует правильное время и часовой пояс.
  • если вы используете NTP для гостей :
    • убедитесь, что синхронизация времени с VMware Tools отключена
    • добавить tinker panic 0в качестве первой строки /etc/ntp.conf
    • если есть определение локальных часов, подобное server 127.127.1.0в ntp.conf, , закомментируйте его .
    • поместите имена хостов или IP-адреса ваших NTP-серверов также в файл /etc/ntp/step-tickers, чтобы ваши системы переводили свои часы на правильное время при загрузке, как только активируются сетевые интерфейсы и что-либо, -зависящее от времени, например, базы данных. еще не начато.

Некоторые подводные камни, с которыми я столкнулся:

  • /etc/adjtimeуказывает, какие аппаратные часы должны использовать :либо UTC, либо LOCAL. Изменение только переменной в /etc/sysconfig/clockне обязательно приведет к желаемому результату. Убедитесь, что оба места согласованы, просто на всякий случай.
  • убедитесь, что ваши NTP-серверы обслуживают правильное время UTC .
  • , если системное время отличается от точного количества часов, сначала используйте date -u, чтобы убедиться, что представление системы о времени UTC верное. NTP всегда имеет дело только с UTC; любая ошибка преобразования в местное время является ошибкой настроек часового пояса.
3
27.01.2020, 23:23

Итак, после борьбы с этими серверами проблема была решена. Вот подробности:

  1. Для сервера CentOS 7.X я отключил ntpdи вместо этого использовал chronyd, сохранив ntpdна клиентах. Похоже, что chronydбудет поддерживаемым демоном NTP, начиная с CentOS 7.X. Для конфигурации chronydтребуются только server xx.xx.xx.xx prefer iburstи allow yy.yy.yy.yy/ZZв/etc/chrony.conf
  2. Для сервера CentOS 6.4 мне пришлось установить новую версиюtzdataздесь , а затем связать /etc/localtimeс соответствующим часовым поясом, в моем случаеAsia/Amman

Некоторые подводные камни, с которыми я столкнулся:

  • Кошмарная ошибка no server suitable for synchronization foundна клиентах CentOS 6.4 была устранена путем остановки ntpd, запуска ntpdate, а затем запуска ntpd.
  • По какой-то причине не помню, в CentOS 6.4 пришлось заменить restrict 127.0.0.1наrestrict localhost
0
27.01.2020, 23:23

Теги

Похожие вопросы