Leap Second - hrtimer

그러고보니, 지난 6월 30일과 7월 1일 사이가 30년마다 한번씩 찾아오는

윤초(leap second) 라면서 HP 승원형도 들어본적 있냐고 연락오고 했었는데..

울쪽에선 메일이 날라오질 않아서 신경 안쓰고 있었다..

사실 Leap second 가 일어나게 되는 원인으로는 평균 태양시랑 원자시계가

20년마다 한번씩 1초(0.9초쯤?) 차이가 나서 그걸 보정하기 위한

1초를 더하거나 덜하기 위한 가상의 변수를 뜻하는 것인데,

이게 하필 지난 주말이였다는거지..

뉴스보니 포슥이나 인스탁등등도 이녀석때문에 서버장애가 일으킨거 같은데,

사실 여기서 중요한 점은 이 녀석들이 왜 영향을 주냐는거거든...

그냥 마냥 20년정도밖에 리눅스가 안만들어져서 그런다 라는 따위의 잡설은 꺼져주시고.

적용되는 (해당되는) 시스템의 커널 버젼을 보면 잘 알 수 있어...

사실 이 윤초가 주는 영향은 시스템을 무조건 다운되거나 리붓시키는것이 아니라,

커널의 특정 타이머알고리즘에 대한 버그로 CPU 가 높은 Utilization 을 일으켜

Livelock 이라는 현상으로 진입시켜버리는 문제 ( Hang on 또는 Hanging ) 거든..

우리 Cooperate Architecture 의 장이신 Wim 아저씨가 메일 딸랑 두줄 보내주셨어..

http://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/

https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

하나는 재밌게도 Mysql 관련 테스트를 한 Mozilla 측 사람이고,

(이게 젤 흥미있었다 사실)

커널 메일링 리스트다...

자.. 원인이 되는 코드와 스코프가 정의되어 있다.. hrtimer (고해상도 타이머) 를 사용하는

( 일전에 언급했던거같은데 아닌가... 비공개인가 ㅡ,.ㅡ:: )

시스템에서 leap second 에 대한 처리는 거의 HZ tick 의 경계선상쯤에서 적용을

시켜주어야 하기때문에 CPU time 업데이트하고 가져오는 부분에서 spin_lock 이

발생할 수 있도록 되어 있기 때문이였다.. 이건 뭐 커널 버그라고 그냥 보는것 같다.

즉 자기네들도 생각 못했었던건데 하필 계산해보면 거의 그정도 tick 에 걸리더라

라는 거지... 이 부분에서 우리가 사용하는 시스템이 얼마나 시간에 민감하게

반응 하고 또 정확하려고 노력하는 지에 대해서 다시한번 고찰해 봐야 할 것이다.

즉 Latency 와 Service 에 대한 연관성에 대해서 말이다.. (너무들어갔나..)

암튼 난 여기까지~ 더이상 진행한다고 얘기하진 않았다~ 상상은 마음대로다~

(개콘 하극상)

나름 중쿡아히들과 맞춰 퇴근한답시고 남아서 글쓰고 있었는데, 매니져님이 가신듯하여

잽싸게 나도 가야겠다.. ㅋ