«Високосная секунда», введённая в ночь с 30 июня на 1 июля в
эталонные мировые атомные часы, отправила в тартарары целый ряд крупных
интернет-ресурсов во всём мире: Yelp, Reddit, Mozilla,
LinkedIn, всё, связанное с Gawker, благополучно «легло», поскольку
большинство серверных приложений оказались неготовыми обработать
появление лишней секунды.
Как пишет Opennet.ru, наблюдалось массовое зависание серверных приложений (в основном приложения работающие в Java VM, такие как Hadoop и Cassandra), начинала съедать все процессорные ресурсы СУБД MySQL; отключались VPN-туннели на базе OpеnVPN, зависали Linux-серверы.
Многие серверы пришлось перезагружать. Стабилизация некоторых приложений потребовала ручной переустановки даты.
Произошедшее, в принципе, довольно странно: секунда координации вводится нечасто, но и не то, чтобы совсем уж редко — в предыдущий раз это было проделано в 2008 году, и тогда обошлось без глобальных потрясений. А тут вдруг случилась незадача.
Чуть ли ни единственным из крупных сервисов, кто был подготовлен к «бродячей секунде», был Google:
Секунда координации (leap second) добавляется по астрономическим наблюдениям в конце суток по всемирному времени 30 июня или 31 декабря так, чтобы время UTC (всемирному координированному времени) не отличалось от среднего солнечного времени UT1 более, чем на 0,9 секунды. Грубо говоря, в такие дни после времени 23:59:59 идёт 23:59:60, и только потом 00:00:00.
Серверные приложения зачастую оказываются не готовы к такому повороту судьбы и всеми силами (путём пожирания процессорных мощностей) пытаются осознать, что происходит со временем.
Если вы ведёте свой блог, микроблог, либо участвуете в какой-то популярной социальной сети, то вы можете быстро поделиться данной заметкой со своими друзьями и посетителями. Для этого воспользуйтесь предлагаемыми ниже кнопками:
Блог: http://romanlovetext.blogspot.com/
Как пишет Opennet.ru, наблюдалось массовое зависание серверных приложений (в основном приложения работающие в Java VM, такие как Hadoop и Cassandra), начинала съедать все процессорные ресурсы СУБД MySQL; отключались VPN-туннели на базе OpеnVPN, зависали Linux-серверы.
Многие серверы пришлось перезагружать. Стабилизация некоторых приложений потребовала ручной переустановки даты.
Произошедшее, в принципе, довольно странно: секунда координации вводится нечасто, но и не то, чтобы совсем уж редко — в предыдущий раз это было проделано в 2008 году, и тогда обошлось без глобальных потрясений. А тут вдруг случилась незадача.
Чуть ли ни единственным из крупных сервисов, кто был подготовлен к «бродячей секунде», был Google:
"Мы придумали способ, который можно назвать «вискокосным смазыванием». Мы перенастроили наши внутренние NTP-серверы так, чтобы с каждым обновлением добавлялись по паре миллисекунд, варьируя эту величину, до того самого момента, когда секунда координации будет введена на самом деле. Это означало, что к моменту, когда должна была появиться дополнительная секунда, наши серверные часы уже имели это в виду... В итоге все наши серверы смогли продолжать работу в нормальном режиме, в блаженном неведении о только что случившейся високосной секунде... "— так в Google пояснили свой успех.
Секунда координации (leap second) добавляется по астрономическим наблюдениям в конце суток по всемирному времени 30 июня или 31 декабря так, чтобы время UTC (всемирному координированному времени) не отличалось от среднего солнечного времени UT1 более, чем на 0,9 секунды. Грубо говоря, в такие дни после времени 23:59:59 идёт 23:59:60, и только потом 00:00:00.
Серверные приложения зачастую оказываются не готовы к такому повороту судьбы и всеми силами (путём пожирания процессорных мощностей) пытаются осознать, что происходит со временем.
Если вы ведёте свой блог, микроблог, либо участвуете в какой-то популярной социальной сети, то вы можете быстро поделиться данной заметкой со своими друзьями и посетителями. Для этого воспользуйтесь предлагаемыми ниже кнопками:
Блог: http://romanlovetext.blogspot.com/
