Кто-нибудь еще сталкивается с высокими темпами сбоя Linux-сервера во время прыжка на второй день?

* ПРИМЕЧАНИЕ. Если на вашем сервере все еще есть проблемы из-за запутанных ядер, и вы не можете перезагрузиться - самое простое решение, предлагаемое с установленной в вашей системе датой gnu: date -s now. Это приведет к сбросу внутренней переменной «time_was_set» ядра и исправлению петли futex процессора в java и других инструментах пользовательского пространства. Я прервал эту команду в своей собственной системе и подтвердил, что она делает то, что она говорит на олове *

POSTMORTEM

Anticlimax: единственная вещь, которая умерла, была моей связью VPN (openvpn) с кластером, так что было несколько захватывающих секунд, пока она была восстановлена. Все остальное было хорошо, и запуск ntp прошел чисто после того, как прошел второй прыжок.

Я написал свой полный опыт дня в http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/

Если вы посмотрите блог Марко на http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second - у него есть решение для фазирования изменения времени в течение 24 часов с помощью ntpd -x, чтобы избежать 1-секундного пропуска. Это альтернативный метод смазывания для запуска вашей собственной инфраструктуры ntp.


Только сегодня, суббота, 30 июня 2012 года - начало скоро после начала дня GMT. У нас было несколько серверов в разных центрах обработки данных, которые управляются разными командами, все темнеет - не реагирует на пинги, пробел экрана.

Все они работают с Debian Squeeze - со всем, начиная от ядра базы данных и заканчивая пользовательскими сборками 3.2.21. Большинство из них - blade-серверы Dell M610, но я также потерял Dell R510, а другие отделы также потеряли машины от других производителей. Был также старый IBM x3550, который разбился и который, как я думал, может быть не связан, но теперь мне интересно.

Одна авария, которая у меня была, дала с экрана:

[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001]  lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0

К сожалению, у всех лезвий, по-видимому, было настроено kdump, но они так сильно погибли, что kdump не срабатывал - и они включили консольное гашение. Я отключил консольное гашение сейчас, так что пальцы скрещены. У меня будет дополнительная информация после следующего сбоя.

Просто хочу знать, является ли это общей нитью или «просто нами». Странно, что они разные подразделения в разных центрах обработки данных, которые покупаются в разное время и управляются разными администраторами (я запускаю FastMail.FM) ... и теперь даже другое оборудование поставщика. Большинство машин, которые разбились, работали в течение нескольких недель /месяцев и запускали ядра 3.1 или 3.2 серии.

Самая недавняя авария была машиной, которая работала всего на 6 часов 3.2.21.

ПРОГРАММА

Хорошо, вот как я работал вокруг.

  1. отключен ntp: /etc/init.d/ntp stop
  2. создан http://linux.brong.fastmail.fm/2012-06-30 /fixtime.pl (код, украденный у Марко, см. В сообщениях блога в комментариях).
  3. ran fixtime.pl без аргумента, чтобы увидеть, что был второй набор ran fixtime.pl с аргументом для удаления второго прыжка

ПРИМЕЧАНИЕ: зависит от adjtimex. Я поставил копию двоичного кода squode adjtimex в http://linux.brong.fastmail.fm/2012-06-30/adjtimex - он будет работать без зависимостей от сжатия 64-битной системы. Если вы поместите его в тот же каталог, что и fixtime.pl, он будет использоваться, если его нет. Очевидно, если вы не сжимаете 64-битный ... найдите свой собственный.

Завтра я запустим ntp.

Как анонимный пользователь предложил - альтернатива запуску adjtimex - просто установить время самостоятельно, что, по-видимому, также очистит счетчик leapsecond.

366 голосов | спросил Bron Gondwana 30 J0000006Europe/Moscow 2012, 20:15:09

5 ответов


322

Это вызвано livelock, когда ntpd вызывает adjtimex (2), чтобы сообщить ядру вставить секунду прыжка. См. Публикацию lkml http://lkml.indiana.edu/hypermail/linux /kernel/1203.1/04598.html

Red Hat также должен обновлять свою статью в KB. https://access.redhat.com/knowledge/articles/15145

UPDATE: Red Hat имеет вторую статью в KB для этой проблемы: https: //access.redhat.com/knowledge/solutions/154713 - предыдущая статья предназначена для более ранней, несвязанной проблемы.

Обход - это просто отключить ntpd. Если ntpd уже выпустил вызов adjtimex (2), вам может потребоваться отключить ntpd и перезагрузиться, чтобы быть на 100% безопасным.

Это влияет на RHEL 6 и другие дистрибутивы с новыми ядрами (новее, чем приблизительно 2.6.26), но не RHEL 5.

Причина, по которой это происходит до , на самом деле запланирована секунда скачка, заключается в том, что ntpd позволяет ядру обрабатывать прыжок второй в полночь, но ему необходимо предупредить ядро, чтобы вставить секунду прыжка до полуночи , Поэтому ntpd вызывает adjtimex (2) когда-нибудь в течение дня скачка, после чего эта ошибка запускается.

Если у вас установлено adjtimex (8), вы можете использовать этот скрипт, чтобы определить, установлен ли флаг 16. Флаг 16 - «вставка секунды прыжка»:

adjtimex -p | perl -p -e 'undef $_, next unless m/status: (\d+)/; (16 & $1) && print "leap second flag is set:\n"'

UPDATE:

Red Hat обновила свою статью в KB, чтобы отметить: «Клиенты RHEL 6 могут быть затронуты известной проблемой, которая заставляет NMI Watchdog обнаруживать зависание при получении анонса leptecond NTP. Эта проблема решается своевременно. ваши системы получили объявление leapsecond и не испытывали этой проблемы, тогда они больше не затрагиваются ».

ОБНОВЛЕНИЕ: вышеуказанный язык был удален из статьи Red Hat; и добавлено второе решение KB, в котором подробно описывается проблема сбоя adjtimex (2): https: //access. redhat.com/knowledge/solutions/154713

Тем не менее, изменение кода в сообщении LKML от IBM Engineer John Stultz отмечает, что также может возникнуть тупиковая ситуация, когда фактически применяется прыжок, поэтому вы можете отключить скачок второй путем перезагрузки или использования adjtimex (8) после отключить ntpd.

ЗАКЛЮЧИТЕЛЬНОЕ ОБНОВЛЕНИЕ:

Ну, я не разработчик ядра, но я снова рассмотрел патч Джона Штутца: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h = 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Если я сейчас прочитаю это правильно, я ошибался в том, что есть другой тупик, когда применяется второй прыжок. Это похоже на мнение Red Hat, основываясь на их записи в КБ. Однако, если вы отключили ntpd, отключите его еще на 10 минут, чтобы вы не попали в тупик, когда ntpd вызывает adjtimex (2).

Мы выясним, есть ли больше ошибок:)

ВТОРОЕ ОБНОВЛЕНИЕ POST-LEAP:

Я провел последние несколько часов, просматривая код ядра ntpd и pre-patch (buggy), и, хотя я могу быть очень не прав, я попытаюсь объяснить, что я думаю:

Во-первых, ntpd вызывает adjtimex (2) все время. Он делает это как часть своего «фильтра петли часов», определенного в local_clock в ntp_loopfilter.c. Вы можете увидеть этот код здесь: http: //www .opensource.apple.com /source /ntp /ntp-70 /ntpd /ntp_loopfilter.c (из версии ntp 4.2.6).

Фильтр цикла синхронизации работает довольно часто - он запускается каждый раз, когда ntpd опросает свои восходящие серверы, которые по умолчанию - каждые 17 минут или более. Соответствующим битом фильтра синхронизации часов является:

if (sys_leap == LEAP_ADDSECOND)
    ntv.status |= STA_INS;

И затем:

ntp_adjtime(&ntv)

Другими словами, в дни, когда есть секунда скачка, ntpd устанавливает флаг «STA_INS» и вызывает adjtimex (2) (через свою переносимость-обертку).

Этот системный вызов пробивается к ядру. Вот соответствующий код ядра: https://github.com/зеркала /Linux /блобы /a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33 /ядро ​​/время /ntp.c

Кодовая строка ядра примерно такая:

  • строка 663 - начало процедуры do_adjtimex.
  • строка 691 - отменить любую существующую прыжковую секундутаймер.
  • строка 709 - захватить спин-блокировку ntp_lock (эта блокировка задействована в возможном сбое в работе)
  • строка 724 - вызов process_adjtimex_modes.
  • строка 616 - вызов process_adj_status.
  • строка 590 - установить глобальную переменную time_status на основе флагов, установленных в adjtimex (2) call
  • строка 592 - проверить глобальную переменную time_state. в большинстве случаев вызовите ntp_start_leap_timer.
  • строка 554 - проверить глобальную переменную time_status. STA_INS будет установлен, поэтому установите time_state в TIME_INS и вызовите hrtimer_start (другая функция ядра), чтобы запустить секундомер второго уровня. в процессе создания таймера этот код захватывает xtime_lock. если это произойдет, когда другой процессор уже захватил xtime_lock и ntp_lock, то ядро ​​livelocks. поэтому Джон Стулц написал патч, чтобы избежать использования hrtimers. Вот что сегодня вызывало проблемы.
  • строка 598 - если ntp_start_leap_timer фактически не запускает таймер прыжка, установите time_state в TIME_OK
  • строка 751 - при условии, что ядро ​​не будет находиться в режиме ожидания, стек разматывается, и отключается spinlock ntp_lock.

Здесь есть пара интересных вещей.

Во-первых, строка 691 отменяет существующий таймер каждый раз, когда вызывается adjtimex (2). Затем 554 повторно создает этот таймер. Это означает, что каждый раз, когда ntpd запускает свой фильтр синхронизации часов, вызывается код ошибки.

Поэтому я считаю, что Red Hat ошибалась, когда они говорили, что, как только ntpd установит флаг прыжков, система не потерпит крах. Я полагаю, что каждая система, работающая под управлением ntpd, имела потенциал для оживления каждые 17 минут (или более) для 24-часового периода до прыжка-секунды. Я считаю, что это также может объяснить, почему так много систем разбилось; одноразовый шанс срыва будет гораздо менее вероятен, чем 3 шанса в час.

UPDATE: в решении KB Red Hat в https://access.redhat.com/knowledge /solutions /154713 , инженеры Red Hat пришли к такому же выводу (что запуск ntpd будет постоянно ударять по коду ошибок). И действительно, они сделали это за несколько часов до этого. Это решение не было связано с основной статьей на https://access.redhat.com/knowledge /articles /15145 , поэтому я не заметил этого до сих пор.

Во-вторых, это объясняет, почему сбойные системы с большей вероятностью вылетают. Загруженные системы будут обрабатывать больше прерываний, в результате чего функция ядра do_tick будет вызываться чаще, что дает больше шансов для запуска этого кода и захвата ntp_lock во время создания таймера.

В-третьих, есть ли вероятность сбоя системы, когда действительно произойдет прыжок? Я не знаю точно, но, возможно, да, потому что таймер, который запускает и фактически выполняет настройку скачкообразной перестройки (ntp_leap_second, строка 388), также захватывает спин-блокировку ntp_lock и имеет вызов hrtimer_add_expires_ns. Я не знаю, может ли этот вызов вызвать ожидание, но это не кажется невозможным.

Наконец, что заставляет флаг прыжков секунд отключиться после выполнения прыжка? Ответ: ntpd останавливает установку знака прыжка в какой-то момент после полуночи, когда он вызывает adjtimex (2). Поскольку флаг не установлен, строка проверки 554 будет недействительной, и таймер не будет создан, а строка 598 сбросит глобальную переменную time_state на TIME_OK. Это объясняет, почему, если вы проверили флаг с помощью adjtimex (8) сразу после второго прыжка, вы все равно увидите установленный флаг прыжков.

Короче говоря, лучший совет на сегодняшний день, кажется, первый, который я дал в конце концов: отключить ntpd и отключить флаг прыжков.

И некоторые окончательные мысли:

  • ни один из поставщиков Linux не заметил патча Джона Штутца и применил его к своим ядрам: (
  • Почему Джон Сталтз не предупредил некоторых продавцов, что это было необходимо? возможно, шанс на ожидание казался достаточно низким, чтобы шум не был оправдан.
  • Я слышал, как отчеты о процессах Java блокировались или вращались при применении прыжковой секунды. Возможно, нам следует следовать руководству Google и переосмыслить, как мы применяем прыжки-секунды к нашим системам: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

06/02 Обновление от Джона Стулца:

https://lkml.org/lkml/2012/7/1/203

В посте содержалось пошаговое описание причин, по которым секунда скачка приводила к тому, что таймеры futex истекали преждевременно и непрерывно, что приводило к нагрузке на процессор.

ответил Daniel S. Sterling 30 J0000006Europe/Moscow 2012, 23:56:43
33

Это сильно ударило нас. После перезагрузки многих наших хостов следующее оказалось неловко простым и полностью эффективным без перезапуска хоста:

/etc/init.d/ntp stop
ntpdate 0.us.pool.ntp.org
/etc/init.d/ntp start

Все, что требуется, - это сброс системных часов. Sheesh. То, что я дал, знал это шесть часов назад.

ответил HikeOnPast 1 J000000Sunday12 2012, 11:49:39
24

Простая C-программа, которая очищает второй бит скачка в поле состояния времени ядра:

 #include <sys/timex.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char **argv) {
    struct timex txc;
    int ret;

    (void) argc;
    (void) argv;

    bzero(&txc, sizeof(txc));
    txc.modes = 0;  /* fetch */
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (get)");
        return 1;
    }

    txc.modes = ADJ_STATUS;
    txc.status &= ~16;
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (set)");
        return 1;
    }

    return 0;
}

Сохранить как lsec.c, скомпилировать с помощью gcc -Wall -Wextra -o lsec lsec.c и запустить с правами root.

Вероятно, вы захотите остановить ntpd перед его запуском и перезапустить ntpd после второй секунды.

ответил jon 1 J000000Sunday12 2012, 03:13:17
18

Постмарт кажется ./lsec не имеет эффекта.

То, что мы видим, - это много процессов softirqd, которые используют процессор (обычно линейный для загрузки java-процессов).

Что нужно для исправления POSTMORTEM с секундомерами, уже примененными ntp, является следующее:

Кажется, достаточно просто выпустить:

export LANG="en_EN"; date -s "`date`"

Это должно уменьшить нагрузку без перезагрузки или перезагрузки ntpd. В качестве альтернативы вы можете указать:

apt-get install ntpdate
/etc/init.d/ntpd stop; ntpdate pool.ntp.org; /etc/init.d/ntpd start
ответил Gregor 1 J000000Sunday12 2012, 07:41:47
17

http://my.opera.com /marcomarongiu /blog /2012/03/12 /no-step-back , похоже, указывает, что ядро ​​сжимания Debian не будет обрабатывать секунды прыжка.

Этот поток в comp.protocols.tim.ntp представляет интерес, а также: https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.time.ntp/KSflIgjUdPE

Тем не менее, второй шаг еще не произошел: 23:59:60 UTC

Наконец, https://access.redhat.com/knowledge/articles/15145 имеет следующий смысл: «Когда происходит скачок, ядро ​​печатает сообщение в системном журнале. Существует вероятность того, что печать этого сообщения может привести к сбою ядра в Red Hat Enterprise Linux».

ответил Luca Filipozzi 30 J0000006Europe/Moscow 2012, 22:47:07

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132