토스증권 Oracle DB, 평균 CPU 정상인데 커밋 지연, NIC 인터럽트 소켓 집중이 원인

·2026.10.19 12:07

핵심 내용

토스증권 Oracle DB에서 평균 CPU가 정상인데도 0.1초 이상 커밋 대기가 반복된 원인은 NIC 인터럽트가 한 소켓에 집중된 것이었고, 인터럽트를 두 소켓으로 분산해 대부분 개선됐다

1 / 11

자세히 보기

  • 토스증권 Oracle DB에서 평균 CPU와 각 레이어 지표가 정상인데도 0.1초 이상 커밋 대기가 반복된 원인 확인
  • LGWR이 28번 CPU에서 실행될 때만 지연이 발생하고, NIC 인터럽트가 물리 코어 8개, 즉 한 소켓에 집중된 것이 병목으로 확인
  • 인터커넥트 NIC 2장을 서로 다른 소켓 슬롯으로 옮기고 본딩을 Active-Active로 바꿔 인터럽트를 두 소켓으로 분산
  • 같은 조치를 적용한 다른 Oracle RAC에서는 동시접속자가 28% 많은 날에도 개장 직후 10분 평균 CPU 사용률이 36.6%에서 17.4%로, 10분 구간 최댓값은 42.5%에서 21.9%로 하락

지연 발생 구조

  • 커밋 완료는 LGWR이 리두 로그를 디스크에 기록한 뒤에야 발생하고, 세션은 log file sync 대기 이벤트로 확인
  • NIC 인터럽트는 일반 프로세스보다 먼저 처리되어 같은 코어에서 LGWR을 멈추고 리두 로그 기록을 밀어냄
  • Active-Standby 본딩은 이중화이지만 평소 트래픽과 인터럽트를 활성 포트 하나로 싣는 구조

검토한 대안

  • irqbalance 재분배는 해당 장비에서 NIC 큐와 CPU 매핑 제약으로 적용되지 않음
  • taskset으로 LGWR을 다른 소켓 CPU에 고정하는 방식은 기동마다 수동 설정이 부담으로 판단
  • NIC 슬롯 이동과 Active-Active 전환은 기동마다 챙길 설정이 남지 않는 방식으로 선택

적용 범위와 추가 관측

  • 대상은 Oracle RAC 2노드, 4소켓, 물리 32코어, 하이퍼스레딩으로 논리 CPU 64개 서버
  • 같은 피크 시간대에 초당 1,000건 넘게 인터럽트를 처리하는 물리 코어가 8개에서 15개로, 논리 CPU는 16개에서 31개로 늘고 Gini 계수는 0.80에서 0.67로 하락
  • 원래 문제 서버 피크 15분 구간 평균 %system은 부하가 33% 높은 날에도 7.77%에서 5.89%로 감소
  • AWR 공통 SQL 9건 중 8건의 1회당 수행시간이 줄었고, 주요 업무 SQL 6건은 10.5%에서 30.8%까지 단축

이 한국어 요약은 AI가 자동으로 만들었습니다. 원문의 주장과 맥락은 원문에서 확인해 주세요. 저작권은 원저작자에게 있습니다.

AI 처리 방식을 확인하거나, 요약 오류와 출처 표기 문제, 삭제 요청을 문의 · 건의로 알려주세요.