Comments 74
А с мускулом ни у кого проблем не наблюдалось? В первый раз видел, что процесс мускула нельзя убить.
В том же треде говорят, что в приложениях на Java наблюдались схожие проблемы.
проблемы были другие — начиная с 00:00:00 01.07.2012 GMT java-процесс сразу после старта начинал жрать cpu, но при этом работал. аналогичный эффект наблюдался с ruby. лечится перезагрузкой системы.
в каких случаях возникала эта проблема мне так установить и не удалось — на RHEL5 такого не наблюдалось, RHEL6 повально вели себя как описано выше, но при этом нашлась одна система с RHEL6 которая вела себя нормально.
Та же самая хрень наблюдалась с mysql
Наблюдаю ту же самую проблему с java-процессами.
Удивительно. Мы голову сломали, что произошло с сервером на Java, когда там нет совершенно никого (4 ночи-то...) и он ест абсолютно 100% CPU, хотя профилировщик говорит обратное… Ребут машины помог, ничего посреди ночи лучшего не придумали.
Подтверждаю, такая же хрень, Jenkins жрёт проц.
— Томас, ты рад, что у нас появилось 32 мая?
— Вообще-то не очень, господин барон. Первого июня мне платят жалование.
— Вообще-то не очень, господин барон. Первого июня мне платят жалование.
RHEL5/6 стоят спокойно. Ubuntu тоже не подвис.
Хотя странно — RHEL5 + mysql slave — LA 6.72…
Хотя странно — RHEL5 + mysql slave — LA 6.72…
Подтверждаю проблему. На двух из 1000 серверов (примечательно что оба с явой) вылетела проблема.
Один помер сразу, второй достаточно популярный ресурс информационного СМИ и не можем его перегружать.
Живет под Load Average 40.
Один помер сразу, второй достаточно популярный ресурс информационного СМИ и не можем его перегружать.
Живет под Load Average 40.
Похоже тоже самое, вот только 2 из 8 повисли на ровном месте, один бегал как виртуалка под ESX, оба Debian Squeeze после рестарта работают как ни в чём не бывало!
UPDATE!
Вылечили без перезагрузки, ребята!
Вылечили без перезагрузки, ребята!
root@srv37.vpsville.ru# /etc/init.d/ntp stop
root@srv37.vpsville.ru# date
Sun Jul 1 13:09:45 MSK 2012
root@srv37vpsville.ru# date `date +"%m%d%H%M%C%y.%S"`
root@srv37vpsville.ru# date
Sun Jul 1 13:09:51 MSK 2012
После этого стартуем ntp обратно и… вуаля!
THE WORKAROUND
Ok people, here's how I worked around it.
disabled ntp: /etc/init.d/ntp stop
created linux.brong.fastmail.fm/2012-06-30/fixtime.pl (code stolen from Marco, see blog posts in comments)
ran fixtime.pl without an argument to see that there was a leap second set
ran fixtime.pl with an argument to remove the leap second
NOTE: depends on adjtimex. I've put a copy of the squeeze adjtimex binary at linux.brong.fastmail.fm/2012-06-30/adjtimex — it will run without dependencies on a squeeze 64 bit system. If you put it in the same directory as fixtime.pl, it will be used if the system one isn't present. Obviously if you don't have squeeze 64 bit… find your own.
Ok people, here's how I worked around it.
disabled ntp: /etc/init.d/ntp stop
created linux.brong.fastmail.fm/2012-06-30/fixtime.pl (code stolen from Marco, see blog posts in comments)
ran fixtime.pl without an argument to see that there was a leap second set
ran fixtime.pl with an argument to remove the leap second
NOTE: depends on adjtimex. I've put a copy of the squeeze adjtimex binary at linux.brong.fastmail.fm/2012-06-30/adjtimex — it will run without dependencies on a squeeze 64 bit system. If you put it in the same directory as fixtime.pl, it will be used if the system one isn't present. Obviously if you don't have squeeze 64 bit… find your own.
UFO just landed and posted this here
date -s "`date -u`" && service ntp restartОтсюда blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/
Проверено на MySQL и Java. Помогает без рестартов сервисов/серверов.
Так получается с виндовсом все в порядке?
Подозреваю, что Windows вообще не вставляла секунду.
support.microsoft.com/kb/909614
Особо позабавило «No method exists to include a leap second explicitly for the Windows Time service when the service is working as an NTP server.»
support.microsoft.com/kb/909614
Особо позабавило «No method exists to include a leap second explicitly for the Windows Time service when the service is working as an NTP server.»
UFO just landed and posted this here
Решил и БСД-сервер на работе пингануть. Все хорошо, тоже видеть ничего не вставлял.
Ну вообще-то оно и логично при правильной схеме организации времени.
Есть некоторый компьютер с выходом в интернет, который синхронизируется с точным источником в интернете. На него в свою очередь нацелен контроллер домена с ролью PDC. У него уже берут время остальные контроллеры и потом финальным аккордом отдают клиентам.
При такой схеме — надо только убедиться что те точные часы в интернете знают о leap second. Остальные системы сами синхронизируются.
Есть некоторый компьютер с выходом в интернет, который синхронизируется с точным источником в интернете. На него в свою очередь нацелен контроллер домена с ролью PDC. У него уже берут время остальные контроллеры и потом финальным аккордом отдают клиентам.
При такой схеме — надо только убедиться что те точные часы в интернете знают о leap second. Остальные системы сами синхронизируются.
При такой схеме точно известно, что в промежуток между двумя синхронизациями после добавления секунды время на всех хостах будет спешить на 1 секунду.
UFO just landed and posted this here
Обычному пользователю, конечно, пофигу. Но некоторые сервисы, бывает, критично относятся к таким большим погрешностям.
UFO just landed and posted this here
UFO just landed and posted this here
При таком подходе нельзя гарантировать, что внутри сети в пределах этих 15 минут время будет синхронизировано. Спешить на секунду все начнут в 00:00, но вот синхронизируются все в разное время, в итоге (далее идет образный пример, цифры с потолка) в 00:05 на 50% машин внутри сети время будет спешить, а на других 50% время будет точным.
Пример сервиса под носом — NTP сервер. Простите, но NTP сервер, который в течение 15 минут врет на 1 секунду — не нужен. Другой пример — распределенные вычислительные системы, где важна синхронизация и недопустимы большие скачки при ее выполнении. Различное ПО для низкоуровневой работы с GPS. Обсерватории.
Пример сервиса под носом — NTP сервер. Простите, но NTP сервер, который в течение 15 минут врет на 1 секунду — не нужен. Другой пример — распределенные вычислительные системы, где важна синхронизация и недопустимы большие скачки при ее выполнении. Различное ПО для низкоуровневой работы с GPS. Обсерватории.
Или вот вам 2 примера из моей практики:
1) wiki2.dovecot.org/TimeMovedBackwards/
2) Веб-сервис с генерацией токена и проверкой времени. При такой резкой синхронизации в течение секунды все запросы с только-что сгенерированными токенами не будут обработаны из-за ошибки авторизации.
1) wiki2.dovecot.org/TimeMovedBackwards/
2) Веб-сервис с генерацией токена и проверкой времени. При такой резкой синхронизации в течение секунды все запросы с только-что сгенерированными токенами не будут обработаны из-за ошибки авторизации.
UFO just landed and posted this here
У меня проблем не наблюдалось.
Несколько серверов на Debian Squeeze. Java отсутствует как класс, зато mysql крутится на всех.
Правда служба ntp отсутствует посему проблем быть и не могёт, как я понял — время раз в час рывком offset'ится через cron и ntpdate.
Несколько серверов на Debian Squeeze. Java отсутствует как класс, зато mysql крутится на всех.
Правда служба ntp отсутствует посему проблем быть и не могёт, как я понял — время раз в час рывком offset'ится через cron и ntpdate.
Java наиболее подвержена.
А без ntp Вы зря, время надо подкручивать.
А без ntp Вы зря, время надо подкручивать.
Подкручивать можно и утилитой ntpdate по cron.
В данном случае это оказалось стабильнее, хотя сам метод не без проблем.
В данном случае это оказалось стабильнее, хотя сам метод не без проблем.
Ну проблема только одна, раз в неделю, примерно, одно из 24 суточных заданий по синхронизации не дожидается ответа от ntp-сервера и мне на почту сваливается соответствующее письмо от cron'а. Других «проблем» не наблюдаю.
У меня нету приложений которым настолько необходимо точное время что бы не хватало раз в час или даже 2 offset'нуться.
У меня нету приложений которым настолько необходимо точное время что бы не хватало раз в час или даже 2 offset'нуться.
Проблема может быть с кривым генератором тиков.
У меня есть пара серверов в парке, на которых время за час начинает спешить на 3-4 секунды.
Если делать синхронизацию раз в час, то скачки на 3-4 секунды сильно мешают.
К тому же у нас есть задачи с требуемой точность до 50мс.
Тут обновление по cron не подойдет.
А вообще вариант более экономный к ресурсам и прозрачный для понимания.
У меня есть пара серверов в парке, на которых время за час начинает спешить на 3-4 секунды.
Если делать синхронизацию раз в час, то скачки на 3-4 секунды сильно мешают.
К тому же у нас есть задачи с требуемой точность до 50мс.
Тут обновление по cron не подойдет.
А вообще вариант более экономный к ресурсам и прозрачный для понимания.
UFO just landed and posted this here
man 8 ntpdate:
Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two.
BTW: ntpd в ряде случаев тоже переставляет время рывком.
Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two.
BTW: ntpd в ряде случаев тоже переставляет время рывком.
UFO just landed and posted this here
Серваки с Ораклом тоже подвержены проблеме.
Вот и Хецнер затронуло. Пишут, что саппорт переружен запросами от пользователей, у которых всё сломалось: www.hetzner-status.de/en.html#692
А из-за чего одна лишняя секунда вызвала такие проблемы? Насколько я понимаю, в программах обычно используется unix time, которому на эту leap second глубоко пофигу, то есть время назад не пошло, не зависло и вперёд неожиданно не прыгнуло. Из-за чего же тогда такие драматические последствия?
Как раз таки наоборот. Високосная секунда — отход от определения времени Unix:«количество секунд с 01.01.1970 00:00:00». Обе секунды подряд время 1 и то же. По-хорошему, хочется оторвать некоторые части тела человеку, сделавшему так. Гораздо красивее хранить значения time_t за каждые полгода (Земные). Не думаю, что размер такого файла к 2970 в менее 8к вызовет хоть какие проблемы.
Т.е. ntpd изменило значение unix time в системе?
Хм, с другой стороны, задача ntpd как раз и состоит в том, чтобы менять системное время в целях подстройки. Но тогда, не должна ли такая ситуация происходить чаще, чем раз в 5 лет, и не должны ли программы быть на это расчитаны?
Бага не в ntpd, а где-то в глубинах ядра. У меня ядро в логи вот такое написало, после чего всё и началось:
Jul 1 03:59:59 phoenix kernel: [2747214.725946] Clock: inserting leap second 23:59:60 UTC
Спасибо, теперь немного понятнее.
На мой взгляд, лучше бы системное время шло непрерывно, а учётом leap second занимались бы функции перевода в local time. Я думал, что так оно и было сделано, но похоже, что нет.
На мой взгляд, лучше бы системное время шло непрерывно, а учётом leap second занимались бы функции перевода в local time. Я думал, что так оно и было сделано, но похоже, что нет.
Во-во. Согласен с Biga: ядру знать о високосных секундах незачем вредно. Это другой уровень. Определение Unix-time было таким красивым и естественным образом обходило проблему високосной секунды.
Простите уж мою дотошность, но над фразой «Обе секунды подряд время 1 и то же» я завис на полминуты, пока не понял, что она означает (перечитал раз пять, особенно сбивала с толку единица). Стоило написать проще: «Високосная секунда не учитывается в Unix time (как будто её нет): високосная секунда прошла, а Unix time не поменялось».
Oracle linux ;( DEAD
Без указания на версию ядра звучит как «из-за отказов тормозов АВТОМОБИЛИ врезались в здание».
По моим наблюдениям все более-менее новые линуксы (включая даже 2.6.18) живут.
По моим наблюдениям все более-менее новые линуксы (включая даже 2.6.18) живут.
Так и запишем, что Селектел ставит юзерам 2.6.18 ядро.
У нас отказы в основном на
Linux 3.2.13 #1 SMP Tue Mar 27 15:20:18 MSK 2012 x86_64 GNU/Linux
У нас отказы в основном на
Linux 3.2.13 #1 SMP Tue Mar 27 15:20:18 MSK 2012 x86_64 GNU/Linux
Вы не поверите, но в центосе 5.6 до сих пор 2.6.18. 2.6.18-308? кажись. А записывать вы можете что угодно, но только после изучения устройства RHEL/Centos.
А 3.2 у меня есть, в лаборатории, в частности — и я там никаких затруднений не заметил в связи с этим.
uname -a
Linux lab-xh4 3.2.0-3-686-pae #1 SMP Thu Jun 28 08:56:46 UTC 2012 i686 GNU/Linux
uptime
02:00:54 up 2 days, 10:29, 1 user, load average: 0.19, 0.09, 0.06
dmesg|tail
dmesg |tail
[ 24.307789] eth0: no IPv6 routers present
[ 24.750686] device xenbr0 entered promiscuous mode
[ 24.751243] device eth0 entered promiscuous mode
[ 25.123107] ip_tables: © 2000-2006 Netfilter Core Team
[ 25.289750] device eth0 left promiscuous mode
[ 25.303870] device xenbr0 left promiscuous mode
[ 25.403459] device xenbr0 entered promiscuous mode
[ 25.456223] device eth0 entered promiscuous mode
[ 27.597534] blktap_device_init: blktap device major 253
[ 27.597538] blktap_ring_init: blktap ring major: 251
А 3.2 у меня есть, в лаборатории, в частности — и я там никаких затруднений не заметил в связи с этим.
uname -a
Linux lab-xh4 3.2.0-3-686-pae #1 SMP Thu Jun 28 08:56:46 UTC 2012 i686 GNU/Linux
uptime
02:00:54 up 2 days, 10:29, 1 user, load average: 0.19, 0.09, 0.06
dmesg|tail
dmesg |tail
[ 24.307789] eth0: no IPv6 routers present
[ 24.750686] device xenbr0 entered promiscuous mode
[ 24.751243] device eth0 entered promiscuous mode
[ 25.123107] ip_tables: © 2000-2006 Netfilter Core Team
[ 25.289750] device eth0 left promiscuous mode
[ 25.303870] device xenbr0 left promiscuous mode
[ 25.403459] device xenbr0 entered promiscuous mode
[ 25.456223] device eth0 entered promiscuous mode
[ 27.597534] blktap_device_init: blktap device major 253
[ 27.597538] blktap_ring_init: blktap ring major: 251
java 6.24 успешно выжила (2.6.32-100.0.19.el5), а вот 6.31 на тесте (2.6.32-300.11.1.el5uek) — почти колом встал сервер, но на запросы отвечал.
применением даты и рестартом ntpd все вылечилось…
причем прикол — последнее ядро от Оракла :)
применением даты и рестартом ntpd все вылечилось…
причем прикол — последнее ядро от Оракла :)
UFO just landed and posted this here
Сервак на OpenSUSE 12.1 — kernel 3.1.10-1.9-xen.
Сегодня упал. В логах фагурировал процесс с java.
Сегодня упал. В логах фагурировал процесс с java.
OpenSuSE Linux 3.4.3-30 x86_64 — полет нормальный
1/07 ночью все java процессы начали хавать 100% cpu
пришлось перестартовывать сервер
Ubuntu 10
пришлось перестартовывать сервер
Ubuntu 10
Вот ещё один сводный пост: landslidecoding.blogspot.co.uk/2012/07/linuxs-leap-second-deadlocks.html
UFO just landed and posted this here
linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg00714.html
lists.debian.org/debian-user/2009/01/msg00056.html
Однаго багу не один год уже. Линукс такой линукс.
lists.debian.org/debian-user/2009/01/msg00056.html
Однаго багу не один год уже. Линукс такой линукс.
Проблема в ядре линукса.
Вот кусок метода ntp_leap_second() из kernel/time/ntp.c (версия 3.2.0):
Проблема в том, что захватывается блокировка xtime_lock, и в это же время вызывается printk который вызывает klogd демон, и при некоторых условиях может возникнуть deadlock. Странно, что этот баг до сих пор не пофикшен.
lkml.org/lkml/2009/1/2/373
Вот кусок метода ntp_leap_second() из kernel/time/ntp.c (версия 3.2.0):
write_seqlock(&xtime_lock);
switch (time_state) {
...
case TIME_INS:
timekeeping_leap_insert(-1);
time_state = TIME_OOP;
printk(KERN_NOTICE "Clock: inserting leap second 23:59:60 UTC\n");
hrtimer_add_expires_ns(&leap_timer, NSEC_PER_SEC);
res = HRTIMER_RESTART;
break;
...
}
write_sequnlock(&xtime_lock);
Проблема в том, что захватывается блокировка xtime_lock, и в это же время вызывается printk который вызывает klogd демон, и при некоторых условиях может возникнуть deadlock. Странно, что этот баг до сих пор не пофикшен.
lkml.org/lkml/2009/1/2/373
Sign up to leave a comment.
Leap second привёл к зависанию некоторых серверов на Linux