한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

NIC 인터럽트 단일 코어 집중 Single-queue NIC / no RSS

원인 ID nic-irq · 주 담당 인프라팀·서버 인프라

NIC가 패킷 도착 인터럽트를 CPU 코어 하나에만 보내면 그 코어가 병목이 됩니다.

왜 수신 큐가 하나이거나 여러 코어로 분산하는 RSS가 꺼져 있음 → 그러면 코어 하나가 100%가 되어 패킷을 제때 못 꺼냄 → 화면에서는 사람이 몰릴 때 서버 전체에서 손실과 지연(순간이동·입력 지연)

증상: 순간이동, 고무줄, 입력 지연
요인: 손실, 지연
누가 겪나: 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: RSS(NIC가 분산)·RPS(커널이 분산) 설정, 인터럽트를 여러 코어에 분산, UDP는 포트까지 보고 큐를 나누게 설정(ethtool -N의 rx-flow-hash udp4 sdfn), 인터럽트 처리 코어와 게임 틱 스레드 코어 분리, 코어별 %soft 감시.
수치 감각: 코어 하나가 커널을 거쳐 처리할 수 있는 양은 패킷 크기와 설정에 따라 대략 초당 수십만 패킷. 코어별 사용률에서 수신 처리 비중(mpstat의 %soft)이 한 코어에만 몰려 있으면 이 경우입니다.
그래프에서는: 한도에 닿아 평평해짐 · 코어별 %soft, 초당 수신 패킷 수
확인할 곳: mpstat -P ALL 1로 코어별 %soft(소프트웨어 인터럽트 처리 비율)를 보고, /proc/interrupts로 NIC 큐별 인터럽트가 어느 코어로 가는지, ethtool -l로 큐 수, ethtool -S로 큐별 패킷 수(이름은 드라이버마다 다름)를 확인
이러면 맞음: 한 코어만 %soft가 100% 가까이에 붙어 있고 나머지는 한가하며 인터럽트와 패킷이 큐 하나에 몰림. 그때부터 초당 수신 패킷 수가 더 오르지 못함
이러면 아님: %soft가 여러 코어에 고르게 퍼져 있으면 이 원인이 아님. CPU는 한가한데 손실이 있으면 “클라우드 PPS 한도 초과”나 “링 버퍼 부족”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 큐가 여러 개여도 게이트웨이·프록시처럼 몇 안 되는 주소에서 트래픽이 대부분 오면 한 큐로 몰립니다. UDP는 NIC 기본 설정이 주소만 보고 큐를 나누는 경우가 있어, 포트까지 보도록 바꿔야 고르게 퍼집니다.

출처

Scaling in the Linux Networking Stack Linux kernel
RSS(NIC가 여러 수신 큐로 분산)·RPS(커널이 분산), 큐마다 인터럽트를 따로 두고 여러 코어에 나누는 설정, 수신 인터럽트 처리가 병목이면 RSS 권장
How to receive a million packets per second Cloudflare
수신 큐 하나가 코어 하나로만 가면 그 코어가 초당 약 35만~43만 패킷에서 막힌 측정, NIC가 UDP를 IP 주소로만 해시해 한 큐로 몰린 사례
ethtool(8) — Linux manual page ethtool
ethtool -N rx-flow-hash udp4로 UDP 해시에 포트(f·n)까지 넣는 옵션
mpstat(1) — Linux manual page sysstat
%soft: CPU가 소프트웨어 인터럽트 처리에 쓴 시간 비율, -P ALL로 코어별

NIC 인터럽트 단일 코어 집중 Single-queue NIC / no RSS

출처

함께 보면 좋은 원인

같은 층: L6 서버 네트워크 카드

같은 증상(순간이동)의 다른 층 원인