sejong.jeonjo@gmail.com

Kubernetes 1.23 이상 또는 OCP 4.10 이상을 사용하는 Cluster에서 Pod를 구동하다보면, 

Pod Status가 SMTAlignmentError 에러 상태가 되면서 구동하지 못하는 경우를 만난다.

CPU Pinning을 위해 아래처럼 Pod Spec을 설정한 경우에 볼 수 있는 에러이다.

아래 YAML 예시에서 cpu 개수를 5개 설정한 것이 문제를 발생시킨다. (홀수로 설명하는 것이 문제)

kind: Pod
metadata:
  name: myapp
spec:
... 중간 생략 ...
  containers:
    resources:
      limits:
        cpu: 5   ## 이렇게 홀수인 정수를 설정한 것이 에러를 발생시킴.
... 중간 생략 ...

관련 자료를 찾아보니, 아래 문서가 가장 설명을 잘 해주고 있다.

위 문서의 요지는 이렇다.

X86_64 CPU는 아래 그림처럼 1개의 물리 Core가 2개의 논리 CPU(Thread)로 구성되어 있고, 
이 2개의 논리 CPU(Thread)가 1개의 L2 Cache를 공유하기 때문에
만약 홀수 개로 CPU를 Pinning(즉, Isolation)하면, L2 Cache의 Hit Ratio가 확 떨어지기 때문에
Core의 처리 속도가 겁나게 떨어진다는 것이다.

즉, L2 Cache 1개를 두고 LCore-0과 LCore-1이 치고 박고 시끄럽게 싸우는 꼴~~~
X86_64 CPU 구조에는 늘상 발생하는 현상으로써, "noisy neighbors"라고 표현한다.

쉽게 이해하기 위해 일상 생활과 비유해본다면,

2명의 사람이 한 집에 살면서 요리를 하는데

주방이 1개라서 홍길동은 된장찌개(Job-A)를 만들어 먹고 싶고, 이순신은 김밥(Job-B)을 만들어 먹고 싶다면

홍길동이 된장찌개 요리를 마무리하고 주방(L2 Cache)를 비워줘야, 이순신이 그 주방(L2 Cache)에서 김밥을 만들 수 있는 것과 같다.

여기서 핵심은 "주방(L2 Cache)를 비워줘야" 한다에 있다.

Local Thread가 서로 다른 일을 할 경우, L2 Cache에 담을 내용이 서로 다르기 때문에 L2 Cache 메모리에 있는 데이터를 재사용할 수 없고(즉, Hit Ratio가 떨어지고) 실제 L2 Cache는 Cache 로써의 역할을 못하게 된다.

L2 Cache의 내용 싹~~~ 갈아 엎어버리고 다른 CPU Core가 해야 할 일과 관련된 데이터를 복사해야 하니까~~~

이렇기 때문에 비슷한 Job(프로그램, 또는 Process)에 대해서 L2 Cache를 같이 사용하도록 2개씩 쌍으로 할당하는 것이 최고의 성능을 낼 수 있다.

그럴 일은 없겠지만, 만약 논리 쓰레드 3개가 1개의 L2 Cache를 공유하는 CPU 제품이 있다면 3개씩 쌍으로 할당해야 최고의 성능을 낼 수 있다. (이것은 그냥 가정이다)

내 생각에는
처음부터 Intel x86 CPU가 Hyper Threading 구조가 아니였다면, 즉 Logical Core가 L2 Cache Memory를 공유하지 않는 구조였다면 CPU Pinning 설정할 때 짝수로 설정해야 하는 제약도 없었을 것 같다.

아래 그림은 Red Hat Web Docs에서 인용한 그림.

작성일: 2022년 2월 6일

오늘 현대백화점 판교점에 가서 점심 식사를 했다.

현대백화점 푸드코트에서 밥 먹고, 바로 교보문고에 가서 책 3권 구입하고, 바로 주차장으로 갔다.

아마 백화점 실내에서 1시간 10분 ~ 20분 정도 시간을 보낸 것 같다. (입차/출차 시간은 이것보다 10분 정도 더 될듯. 전기차 충전소 찾느라 보낸 시간이 있으니...)

현대백화점 식당(sooooo) 직원이 음식값 결제할 때, 주차 정산까지 했다고 말해줬기 때문에 나는 따로 주차정산기(키오스크)에서 정산을 하지 않고 주차장 출구로 나왔는데, 차단기는 안 올라가고 7,000원이라는 요금만 전광판에 표시되었다.

"이건 뭐지? 주차 요금이 왜 나와?"

주말이라 차들이 주차장 출구에 길게 줄지어 섰기 때문에 호출 버튼을 누를 수 없었다.

일단, 바로 카드로 주차 요금 결제하고 집으로 왔다. 

집에 와서 생각해보니 sooooo 식당 직원이 주차 정산을 하지 않은 것 같다. 주차 금액이 내가 현대백화점에 머물렀던 시간만큼 모두 청구되었기 때문이다.

그래서 다시 그 식당 직원에게 문의 전화를 해보니, 본인은 정확하게 차량 등록을 해줬다는 것이다.

그렇다면, 현대백화점 주차 관리 시스템에 문제가 있나 싶어서, 아래처럼 현대백화점 고객의 의견 에 문의 글을 올렸다.

일단 뭐가 문제인지 궁금증을 해결해보고 싶었다.

아래 문의 글을 올리고 나서, 1시간 뒤에 현대백화점에서 전화가 왔다.

(일요일인데, 이렇게 바로 고객 응대를 해주니 고맙다)

고객센터 직원이 내 자동차 번호를 물어보고, 차량 조회를 해보니 내가 주차한 시간 그리고 식당에서 주차 등록을 했는지 여부를 확인해주었다.

결론은  "식당에서 주차 정산 등록을 하지 않았다"

물론 그 직원이 일부러 주차 정산을 하지 않았다고 볼 수는 없다. 아직 일이 미숙해서 그럴 수 있다.

또는 주차 정산 시스템이 마침 그때 오류가 있어서 DB에 기록되지 않았을 수도 있다.

나도 이런 과금 시스템을 개발한 개발자(프로그래머)로써 가끔 상용 시스템에 이런 이슈가 발생하면 머리카락이 쭈뼜한다. ㅠㅠ

아무튼 고객센터 직원이 내가 현대백화점 식당과 교보문고에서 지출한 내역을 바로 확인하고,
주차비를 모두 취소해주었다.

오늘의 교훈: 현대백화점을 이용할 때는 ...

현대백화점 앱에 있는 주차권을 사용하는 것이 어려모로 편할 것 같다.

한 직원의 입력 실수로 이렇게 여러 사람 피곤하게 후처리하는 것보다, 깔끔하게 앱에 있는 주차권을 사용하는 것이 좋을 듯...