스위치에서 패킷을 받아 커널을 지나 어플리케이션을 전달되는 과정을 설명하며 이에 대한 튜닝 방법 설명

1. RED HAT ENTERPISE LINUX | YONG KI, KIM1
RHEL Network Packet Flow
Performance Tuning
YONG KI, KIM
Sr. Platform Solution Architect
ykim@redhat.com
Jan 26, 2016

2. RED HAT ENTERPISE LINUX | YONG KI, KIM2
Abstract
RHEL Network Performance Tuning
최근 IT는 네트워크에 대한 의존도가 높아지게 됨에 따라 안정적인 네트워크 응답속도(latency)와 대역폭 확보를
요구하고 있습니다.
게다가 분산형 스토리지와 같이 대용량의 네트워크를 사용하는 업무에서는 packet drop과 같은 에러가 발생할
경우 tcp retransmission에 의해 성능이 저하되기 때문에 안정적인 네트워크 환경을 구축하는 것이 매우 중요하게
되었습니다.
따라서 본 문서에서는 스위치로 부터 커널을 통해 Application이 사용하는 TCP Socket까지 패킷이 어떻게
흘러가는가를 알아보고 어느 곳에서 문제가 발생하는 가를 확인하는 방법과 이에 대한 해결방안을 기술하고자
합니다. 이를 통해 그 동안 파편화되어 있는 네트워크 흐름 및 네트워크 관련 커널 파라미터를 재정립할 수 있기를
기대합니다.
이 문서는 아래 레드햇 문서를 기반으로 기술하였으며 본문이 이해 안되는 경우 아래 원문을 참고하여 주시기
바랍니다.
원문: https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf

3. RED HAT ENTERPISE LINUX | YONG KI, KIM3
Factors of Network Tuning
RHEL Network Performance Tuning
참고: https://access.redhat.com/support/policy/updates/errata
성능 튜닝을 위한 고려 요소
• 네트워크 카드(NIC)
• NIC Driver 및 옵션
• CPU to Memory 아키텍쳐
• 커널 파라미터
네트워크 감시 및 설정 도구
• netstat: 네트워크 상태를 확인하는 명령어
• ethtool: NIC 설정을 확인/ 변경하는 명령어
• dropwatch: packet drop을 확인하는 명령어
• ip: ip 주소, 라우팅, 터널링을 확인/관리하는 명령어

4. RED HAT ENTERPISE LINUX | YONG KI, KIM4
Packet Flow from Switch to TCP Socket
RHEL Network Performance Tuning
switch NIC CPU TCP Socket
NIC Driver Kernel Application

5. RED HAT ENTERPISE LINUX | YONG KI, KIM5
Packet Flow from Switch to NIC
- ring buffer
RHEL Network Performance Tuning
switch NIC
NIC Driver
패킷 흐름
스위치로 부터 패킷이 전송되면 일단 NIC의 rx ring b
uffer
에 저장됨. Kernel로 전송되기 전까지 ring buffer에
보관하고 kernel로 copy되면 해당 packet 부분은 새
로운 packet으로 overwrite됨.
Rx buffer 공간이 full되면 packet
drop 발생. Packet drop이 발생하는
가장 흔한 이유.
증상 확인
ring buffer는 NIC에서 제공하는 메모리이며 ethtool
명령으로 확인 가능.
일부 블레이드 시스템의 경우, 블레이드 바이오스에
서 조정 필요
ethtool –g eth0
Ring parameters for eth0:
- Max와 현재 값을 확인
해결 방안
일반적으로 현재값이 max값보다 작게 설정되어 있음.
ethool에서 max값과 동일하게 현재값을 설정
#ethtool –G eth0 rx [max] tx [max
]
Ring
buffer
packet

6. RED HAT ENTERPISE LINUX | YONG KI, KIM6
Packet Flow from Switch to NIC
- Ethernet Flow Control
(a.k.a Pause Frame)
RHEL Network Performance Tuning
switch NIC
NIC Driver
패킷 흐름
Ring Buffer가 full되는 경우, NIC는 switch port로
“pause frame”을 보냄. 이 경우 switch는 일시적으
로(milisecs) 패킷을 보내지 않고 스위치 버퍼에 패킷
저장.
이 기능을 통해 buffer overflow와
packet drop을 방지
증상 확인
Pause Frame 기능은 NIC와 switch port에서 모두
enable 되어 있어야 사용 가능하며, ethtool 명령으로
확인 가능
#ethtool –a eth0
Pause parameters for eth0
RX: off ; TX: off
해결 방안
NIC는 ethtool 명령으로 enable,
switch port는 스위치 벤더에 문의 필요.
#ethtool –A eth0 rx on
#ethtool –A eth0 tx on
Ring
buffer
packet
Pause Frame

7. RED HAT ENTERPISE LINUX | YONG KI, KIM7
Packet Flow from NIC to Kernel
- HW Interrupt
RHEL Network Performance Tuning
NIC
NIC Driver
패킷 흐름
NIC에 ring buffer에 데이터가 들어오면 H/W Interrupt
가 발생하여 커널에 데이터 유입을 알림. 이 후 Soft
IRQ(software Interrupt)가 패킷을 커널로 전달. Soft
IRQ는 scheduling 이 가능하기 때문에 효율적인 데이터
처리가 가능.
10G 환경에서는 rx, tx queue 가 각
각 4개 이상 생성되는지 확인 필요.
해당 queue가 많을 수록 interrupt 신
호를 CPU에 즉각 보낼 수 있음.
증상 확인
• /etc/interrupt 에서 ethX-rx-queue 개수 확인
• /etc/interrupt 에서 각 queue가 cpu core별로 분포
되어 있는 지 확인 (queue별 특정 CPU와 pining 되
도록 설정하는 것이 바람직)
/etc/interrupt 는 cpu core별
interrupt 할당을 보여주는 파일
해결 방안
• ethX-rx-queue는 NIC가 제공하는 것이며 대부분
10G는 multi-queue 지원
• cpu core별 queue 할당:
#service irqbalance oneshot
• 일부 블레이드 장비에서는 바이오
스에서 queue 개수 늘리는 기능
제공.
• irqbalance start 경우, queue와
core 매핑이 매번 바뀔 수 있으므
로 oneshot 옵션 권고
Ring
buffer
packetethX-rx-queue
ethX-rx-queue
ethX-tx-queue
ethX-tx-queue
CPU
Kernel
HW Interrupt
Or SW interrupt

8. RED HAT ENTERPISE LINUX | YONG KI, KIM8
Packet Flow from NIC to Kernel
- SoftIRQ Budget
RHEL Network Performance Tuning
NIC
NIC Driver
패킷 흐름
HW interrupt는 커널에 패킷이 들어왔음을 알려주는 것
이며, S/W interrupt(softirq)는 실제 ring buffer에서
kernel cpu로 데이터를 전송하는 역활. s/w interrupt는
NAPI Polling 방식으로 작동.
N(ew)API Polling 방식은 주기적으로
ring buffer를 탐색하여 cpu에 전달하
는 기능이며, H/W interrupt가 너무
빈번하게 발생하는 것을 방지하여
CPU 부하를 낮춤.
증상 확인
softnet_stat 의 세 번째 컬럼은 softirq가 CPU time이
부족할 때 증가하며 이 때는 netdev_budget 올려야 함.
(증가폭이 적을 때는 상관없으나 증가폭이 클 때는
netdev_budget 변경 필요)
#cat /proc/net/softnet_stat
결과값 세번째 컬럼 참조
(이 값은 16진수로 표기)
해결 방안
net.core.netdev_budget 은 softirq가 한번에 CPU를 선
점할 수 있는 메시지 수를 지정하는 것으로 이 값이 높을
수록 NIC ring buffer의 패킷을 커널로 빨리 보낼 수 있
음.
기본값은 300이며 10Gb환경에서는 600 권고.
#sysctl –w 600 net.core.netdev_bu
dget
packetethX-rx-queue
ethX-rx-queue
ethX-tx-queue
ethX-tx-queue
CPU
Kernel
SW interrupt
(NAPI Polling)
Ring
buffer

9. RED HAT ENTERPISE LINUX | YONG KI, KIM9
Packet Flow from NIC to Kernel
- backlog
RHEL Network Performance Tuning
NIC Driver
패킷 흐름
softirq에 의해 전송된 패킷은 커널의 backlog queue로
보내져 cpu에서의 처리를 기다리게 됨. backlog queue
는 각 cpu core당 생성되며 커널 파라미터
netdev_max_backlog 값 까지 자동으로 증가.
netdev_max_backlog는 backlog
queue에 쌓일 수 있는 최대 패킷 개
수.
증상 확인
cpu core당 할당된 backlog가 full차게 되면 패킷 drop
이 발생하며 queue 값의 변화는 /proc/net/softnet_stat
두번째 컬럼에서 확인 가능 . 해당 컬럼이 지속적으로 증
가하면 backlog 증가 필요
#softnet_stat (각 라인은 cpu core
의미)
LINE1 = CPU0
LINE2 = CPU1
해결 방안
max_backlog의 default 값은 1000 이며, softnet_stat
두 번째 컬럼이 증가하면 2000으로 값을 올림. 이후 에
도 증가하면 4000으로 다시 올림. 컬럼값이 증가되지 않
을 때 까지 max_backlog를 증가시켜 적정한 값 도출 필
요
#sysctl –w net.core.netdev_max_b
acklog=2000
packet
CPU
Kernel
HW Interrupt
Or SW interrupt
CPU1
backlogCPU2
backlogCPU3
backlogCPU4
backlog
NIC
ethX-rx-queue
ethX-rx-queue
ethX-tx-queue
ethX-tx-queue
Ring
buffer

10. RED HAT ENTERPISE LINUX | YONG KI, KIM10
Packet Flow from NIC to Kernel
- TCP Offload
RHEL Network Performance Tuning
NIC
NIC Driver
패킷 흐름 TCP segmentation offload(TSO)는 NIC에서 패킷
을 전송하거나 받을 때 서버의 CPU를 사용하지 않
고 NIC가 직접 처리하는 방식. 즉 커널에서 NIC로
64k 단위로 보내면 NIC가 알아서 MTU 사이즈로
쪼개서 보내는 방식.
TCP offload를 사용하게 되면 CPU의 역할이 줄어
들기 때문에 시스템 성능 향상시킬 수 있음. 하지만
양쪽에서 모두 tcp offload를 지원하지 않으면 큰
성능 향상을 못 볼 수 있으므로 on/off 하면서 성능
확인 필요
증상 확인 TCP offload 기능은 NIC에서 제공하는 기능이므
로 NIC별로 설정이 가능한 부분과 아닌 부분이 나
눠짐.일반적으로 LRO, TSO 가 설정 가능한 옵션.
GSO, GRO는 커널에서 제공하는 offload 기능이
며 slab mem을 거칠 때 page resizing을 방지하
기 때문에 cpu 부하를 낮출 수 있음.
#ethtool –k eth0
tcp-segmentation-offload: on
generic-segmentation-offload: on
large-receive-offload: on
해결 방안 tcp offload기능을 on하였을 때, 성능이 저하되는
경우도 있기 때문에 on/off 하면서 성능을 비교해
야함.
#ethtool –K eth0 tso off gso off gro off lro off
Ring
buffer
packetethX-rx-queue
ethX-rx-queue
ethX-tx-queue
ethX-tx-queue
CPU
Kernel
HW Interrupt
Or SW interrupt
CPU1
backlogCPU2
backlogCPU3
backlogCPU4
backlog
TCP
offload

11. RED HAT ENTERPISE LINUX | YONG KI, KIM11
Packet Flow from Kernel to TCP socket
- TCP buffer(rmem,wmem)
RHEL Network Performance Tuning
패킷 흐
름
네트워크 패킷이 커널로 전달되면 이는 바로 어플리
케이션에서 사용되도록 시도하고, 이게 불가능할 때
는 어플리케이션의 tcp socket buffer에 쌓이게 됨.
이 때 적정한 버퍼가 존재하지 않으면 packet drop
발생.
커널에서는 이 버퍼값을 min,max 사이에서 자동으
로 조절
새로운 패킷의 양(sk_rmem_alloc)이 최대 버퍼
(sk_rcvbuf)를 초과하게 되면 CPU가 tcp
overhead를 조작하여 빈 메모리 공간을 확보하려
하고(collapsing operation), 그래도 빈 공간을 확
보하지 못하면 packet drop 발생(pruned status)
증상 확
인
• sk_rcvbuf(최대버퍼)가 어플리케이션에서 지정
될 경우는 커널의 기본값을 override하게 됨.
• netstat에서 drop 상태(prune) 또는 메모리 확보
작업(collap) 상태가 증가되는지 확인
• 어플리케이션에서 setsockopt(SO_RCVBUF)
값 확인(packet drop시 증가)
• #netstat –sn | egrep ‘prune|collap’; sleep 3
0;netstat –sn | egrep ‘prune|collap’
해결 방
안
tcp_rmem(or wmem)은 min, default, max 값으로
이루어짐. 단위는 Byte.
어플리케이션 값이 정해져 있는 경우는 자동조절 안
됨(autotune)
#sysctl –w net.ipv4.tcp_rmem=“16384 349520
16777216”
#sysctl –w net.core.rmem_max=16777216
CPU
Kernel
CPU1
backlogCPU2
backlogCPU3
backlogCPU4
backlog
TCP Socket
tcp_rmem
tcp_wmem
Application

12. RED HAT ENTERPISE LINUX | YONG KI, KIM12
Packet Flow from Kernel to TCP socket
- TCP SACK
RHEL Network Performance Tuning
패킷 흐름 기본 TCP 연결에서는 관련된 패킷을 모두 받아야 ACK
를 전송함. 만약 중간하나의 패킷이라도 유실되면 전체
패킷을 새로 받아와야함. 그래서 유실된 패킷만 새로 받
아오도록 하는 기능이 TCP Selective Acknowledgment
s(SACK)
SACK 기능으로 sender는 유실된 패
킷만 새로 전송할 수 있게 됨(RFC
2018)
증상 확인 현재 테스트 결과로는 대역폭이 넓은 네트워크에서는 유
실된 패킷을 계산하는 것이 오히려 CPU 부하를 증가시
키기 때문에 성능 지연 현상 발생.
#sysctl net.ipv4.tcp_sack
해결 방안 high bandwidth 네트워크 환경에서는 유실된 패킷을 계
산하는 오버헤드보다 새로 패킷을 받아오는 것이 성능에
유리하므로 SACK disable 권고
#sysctl –w net.ipv4.tcp_sack=0
CPU
Kernel
CPU1
backlogCPU2
backlogCPU3
backlogCPU4
backlog
TCP Socket
tcp_rmem
tcp_wmem
tcp sack

13. RED HAT ENTERPISE LINUX | YONG KI, KIM13
Packet Flow from Kernel to TCP socket
- TCP Listen Backlog
RHEL Network Performance Tuning
패킷 흐름 TCP socker이 LISTEN 상태로 열리면, 해당 소
켓은 처리되어지길 기다리는 unaccepted 연결
을 유지하게 되며 이 연결 리스트는 listen
backlog에 저장됨
listen backlog는 tcp backlog와 전혀 별개.
증상 확인 어플리케이션이 client의 연결처리를 빠르게 못
하는 경우 클라이언트가 접속할 수 없게 될 수 있
음
#sysctl net.core.somaxconn
net.core.somaxconn = 128
해결 방안 • 클라이언트의 접속이 많아 접속이 원할하지
않은 경우에는 연결 대기 개수를 늘려 이를
해결
• 어플리케이션에서도 socketfd 값을 증가시킨
후 어플리케이션 재시작 필요
• #sysctl –w net.core.somaxconn=2048
• 어플리케이션 변경
rc = listen(socketfd, 128);
=> rc = listen(socketfd, 2048);
CPU
Kernel
CPU1
backlogCPU2
backlogCPU3
backlogCPU4
backlog
TCP Socket
tcp_rmem
tcp_wmem
tcp sack
tcp listen backlog

14. RED HAT ENTERPISE LINUX | YONG KI, KIM14
Packet Flow from Kernel to TCP socket
- TCP Windows Scaling
RHEL Network Performance Tuning
패킷 흐름 tcp window는 TCP에서 데이터를 저장하기 위한 공간
이며, tcp window는 기본 8bit로 구성. 이는 최근 네트
워크 환경에 너무 작은 수치이기 때문에 tcp window
수치를 늘려주는 것이 tpc win scale의 기능.
tcp_win_scale은 sender와 receiver 모
두 지원해야 정상작동하며 한쪽이라도
지원하지 않을 경우 8bit 로 동작
증상 확인 tcp windows scaleing은 tcp handshake(syn,
syn+ack, ack)과정에서 정해지며 tcp 패킷 캡쳐를 통
해 확인할 수 있음. 자신 서버에서 on 하여도 상대측
에서 off일 경우에는 작동하지 않기 때문에 캡쳐된 패
킷의 tcp option 필드를 확인하는 것이 가장 정확.
#sysctl
net.ipv4.tcp_windows_scaling
해결 방안 tcp_win_scale이 on 되어 있을 경우, max window 크
기가 약 1GB 까지 증가.
#sysctl –w
net.ipv4.tcp_windows_scaling=1
CPU
Kernel
CPU1
backlogCPU2
backlogCPU3
backlogCPU4
backlog
TCP Socket
tcp_rmem
tcp_wmem
tcp sack
tcp listen backlog
tcp Window Scaling

15. RED HAT ENTERPISE LINUX | YONG KI, KIM15
Packet Flow from Kernel to TCP socket
- Advanced Window Scaling
RHEL Network Performance Tuning
패킷 흐름 tcp_rmem(or wmem)공간은 커널과 어플리케이션이 공
유하는 버퍼이며, adv_win_scale =2 일 경우, 75%는 커
널 예약 공간(advertised tcp window), 25%는 어플리케
이션 공간(application buffer)으로 활용. 최근 전송되는
데이터의 용량이 커지게 됨에 따라 어플리케이션 버퍼
사용용량 확대가 필요해짐.
• adv_win_scale 의 default = 2
• 공식: app buffer = rmem/(2 ^
adv_win_scale)
증상 확인 tcp_rmem값을 조정했음에도 packet drop(pruning) 현
상이 발생하면 adv_win_scale 값 조정 필요.
RHEL5,RHEL6에서 기본값은 2, RHEL7 기본값: 1
#sysctl net.ipv4.tcp_adv_win_scal
e
net.ipv4.tcp_adv_win_scale=2
해결 방안 adv_win_scale 값을 1로 변경하게 되면, 어플리케이션
데이터 버퍼가 50%로 향상
#sysctl –w net.ipv4.tcp_adv_win_s
cale=1
CPU
Kernel
CPU1
backlogCPU2
backlogCPU3
backlogCPU4
backlog
TCP Socket
tcp_rmem
tcp_wmem
tcp sack
tcp listen backlog
tcp window Scaling
Adv. Window Scaling

16. RED HAT ENTERPISE LINUX | YONG KI, KIM16
추가 네트워크 성능 향상 방법
RHEL Network Performance Tuning
1. CPU Power States
CPU를 항상 wake 상태로 두어 network latency를 향상시키는 방법
- 확인: #cat /sys/module/intel_idle/parameters/max_cstate # result: 0
- 설정: grub의 kernel 라인에 다음 파라미터 추가: processor.max_cstate=1
2. Jumbo Frames
- 기본 MTU값은 1500이나 이를 9000을 늘려 대용량 패킷 전송에 유리
- sender, receiver, 스위치 모두 변경 필요
3. Tuned
- RHEL에서 제공하는 커널 파라미터 프로파일이며 이를 throughput-performance 또는 latency-
performance 모드로 설정하여 파라미터 일괄 변경 가능
4. TCP Timestamps
- TCP timestamps 는 패킷이 전송될 때 더 안정적으로 작동할 수 있는 millisec 단위의 counter를 제공
- 또한 wrapped sequence number를 제공하여 패킷을 주고 받을 때 순서를 더 명확히 할 수 있고 이로
인해 windows size를 증가시키거나 패킷 순서를 정렬할 때 훨신 정확한 값을 산출할 수 있음.
- sysctl –w net.ipv4.tcp_timestamps=1

17. RED HAT ENTERPISE LINUX | YONG KI, KIM17
End of Document