토스증권 Oracle DB, 평균 CPU 정상인데 커밋 지연, NIC 인터럽트 소켓 집중이 원인
·2026.10.19 12:07
핵심 내용
토스증권 Oracle DB에서 평균 CPU가 정상인데도 0.1초 이상 커밋 대기가 반복된 원인은 NIC 인터럽트가 한 소켓에 집중된 것이었고, 인터럽트를 두 소켓으로 분산해 대부분 개선됐다
자세히 보기
- 토스증권 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가 자동으로 만들었습니다. 원문의 주장과 맥락은 원문에서 확인해 주세요. 저작권은 원저작자에게 있습니다.