В то же время в других виртуалках - такого не наблюдается.
После некоторого поиска нашел статью в базе знаний VMware. Оказывается, проблема наблюдается на многих linux'ах.
Руководствуясь статьей и некоторым здравым смыслом, можно предложить несколько рекомендаций.
Первое. Нужно добавить параметры ядру при загрузке. Для этого идем на сайт VMware по ссылке и находим в таблице свою версию дистрибутива (в списке не только RHEL, но и SLES, Ubuntu, Mandriva, Debian, CentOS и некоторые другие). Берем из таблицы параметры для ядра и прописываем в загрузчик.
Для RHEL 5.x 32bit это divider=10 clocksource=acpi_pm
Для RHEL 5.x 64bit - notsc divider=10
Для RHEL 5.4 добавлять уже ничего не надо - работает и так.
Далее, правим ntpd (дальнейшие рекомендации даны для RHEL 5). В /etc/ntpd/steptickers обязательно прописываем сервер синхронизации - по нему пройдет синк перед запуском собственно ntpd. В /etc/ntp.conf первой строчкой добавляем
tinker panic 0
. Эта строка разрешает ntpd синхронизацию даже при большом расхождении с образцовым источником времени. Основное назначение данного параметра - в случае suspend виртуальной машины и потом ее перезапуска не требуется рестарт ntpd.
И комментируем синхронизацию "по своим часам", вот эти строки:
server 127.127.1.0
fudge 127.127.1.0 stratum 10
Не забываем отключить cpuspeed - он пользы не приносит на нагруженных серверах :) - только снижает производительность.
Хочу заметить, что данная проблема присуща не только системам запущенным под VMware, а и всем использующих многоядерные процессоры и/или технологию изменения частоты "на лету".
ВідповістиВидалитиТипичное визуальное проявление, это переодические freeze системы на этапе загрузки и во время работы (продолжительность от 5 до 30 минут).
Проблема при использовании источника времени tsc (гугль дает подробную информацию о этом баге).
Для rhel текущий источник времени можно посмотреть в /sys/devices/system/clocksource/clocksource0/current_clocksource
В качестве решения и рекомендуется использовать clocksource=acpi_pm или clocksource=hpet (в транзакционных системах, первое предпочтительней).
Ну, для vmware я просто пошел по рекомендованному производителем пути. Хотя за информацию спасибо, полезно.
ВідповістиВидалитиБыла такая проблема, всегда убегало время, даже после ручной синхронизации ntpd неуспевал подводить разницу.
ВідповістиВидалитиВиртуалка ESXi /FreeBSD8.1
Решилось добавлением одной строчки
tinker panic 0
Спасибо :)