Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

6.3. 설정 도구

Red Hat Enterprise Linux에는 시스템을 설정할 때 관리자에게 유용한 여러 도구가 있습니다. 다음 부분에서는 이러한 도구에 대해 설명하고 Red Hat Enterprise Linux 7에서 네트워크 관련 성능 문제를 해결하는 방법에 대해 설명합니다.
일부 네트워크 성능 문제 하드웨어 기능 장애나 인프라 장애로 인한 경우가 많다는 것을 염두해 두셔야 합니다. Red Hat은 네트워크 스택을 튜닝하기 위해 이러한 도구를 사용하기 전 하드웨어 및 인프라가 제대로 작동하는지를 확인하는 것이 좋습니다.
이에 더하여 일부 네트워크 성능 관련 문제는 네트워크 서브 시스템을 다시 설정하는것 보다 애플리케이션을 변경하는 것이 문제 해결을 위해 더 나은 방법이 될 수 있습니다. 애플리케이션 영역에 데이터 큐가 있어도 데이터를 유연하게 저장할 수 있고 필요에 따라 메모리를 스왑할 수 있기 때문에 일반적으로 애플리케이션이 자주 posix 호출을 실행하도록 설정하는 것도 좋은 방법일 수 있습니다.

6.3.1. 네트워크 성능을 위한 Tuned-adm 프로파일

tuned-adm은 다수의 특정 사용 경우에서 성능을 개선하기 위한 여러 다른 프로파일을 제공합니다. 다음 프로파일은 네트워크 성능을 개선하는데 유용합니다.
  • latency-performance
  • network-latency
  • network-throughput
이러한 프로파일에 대한 보다 자세한 내용은 A.6절. “tuned-adm”에서 참조하십시오.

6.3.2. 하드웨어 버퍼 설정

다수의 패킷이 하드웨어 버퍼에 의해 드롭되는 경우 몇 가지 사용 가능한 솔루션이 있습니다.
입력 트래픽 속도 감소
들어오는 트래픽을 필터링하면 참여한 멀티 캐스트 그룹 수를 감소시키거나 큐가 채워지는 비율을 줄이기 위해 브로드캐스트 트래픽 수를 감소시킵니다. 들어오는 트래픽을 필터링하는 방법에 대한 자세한 내용은 Red Hat Enterprise Linux 7 Security Guide에서 참조하십시오. 멀티캐스트 그룹에 대한 자세한 내용은 Red Hat Enterprise Linux 7 클러스터링 문서에서 참조하십시오. 브로드캐스트 트래픽에 대한 자세한 내용은 Red Hat Enterprise Linux 7 System Administrator's Reference Guide에서 참조하거나 설정하고자 하는 장치와 관련된 문서에서 참조하십시오. 모든 Red Hat Enterprise Linux 7 문서는 http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/에서 확인하실 수 있습니다.
하드웨어 버퍼 큐 크기 변경
큐 크기를 증가시키기 위해 드롭되는 패킷 수를 줄여 쉽게 오버플로우되지 않게 합니다. ethtool 명령을 사용하여 네트워크 장치의 rx/tx 매개 변수를 수정할 수 있습니다.
# ethtool --set-ring devname value
큐 배출 비율 변경
장치 가중치는 한 번에 (한 번의 스케줄된 프로세서 에 액세스) 장치가 수신할 수 있는 패킷 수를 말합니다. dev_weight 매개 변수에 의해 관리되는 장치 가중치를 증가시켜 큐 배출 비율을 증가시킬 수 있습니다. 이러한 매개 변수는 /proc/sys/net/core/dev_weight 파일 내용을 변경하여 일시적으로 변경하거나 procps-ng 패키지에서 제공하는 sysctl를 사용하여 영구적으로 변경할 수 있습니다.
일반적으로 큐 배출 비율을 변경하는 것이 네트워크 성능 저하를 완화하는 가장 간단한 방법입니다. 하지만 한 번에 장치가 수신할 수 있는 패킷 수를 증가시켜 추가 프로세서 시간을 사용하게 되므로 그동안 다른 프로세서 스케줄에 예약될 수 없기 때문에 다른 성능 관련 문제가 발생할 수 있습니다.

6.3.3. 인터럽트 큐 설정

분석 결과에 높은 대기 시간이 나타날 경우 시스템은 인터럽트 기반 패킷 수신 대신 폴링 기반 수신을 통해 개선될 수 있습니다.

6.3.3.1. 비지 폴링 설정

비지 폴링을 통해 소켓 레이어 코드가 네트워크 장치의 수신 큐를 폴링시켜 네트워크 인터럽트를 비활성화시키므로 네트워크 수신 경로의 대기 시간을 줄일 수 있습니다. 이는 인터럽트 및 결과 컨텍스트 스위치로 인한 지연을 감소시킬 수 있지만 CPU 사용률은 증가합니다. 비지 폴링은 CPU의 수면 상태가 되는 것을 방지하므로 추가 전력 소비가 발생할 수 있습니다.
기본적으로 비지 폴링은 비활성화되어 있으며 특정 소켓에서 폴링을 활성화하려면 다음을 실행합니다.
  • sysctl.net.core.busy_poll0 이외의 값으로 설정합니다. 이 매개 변수는 소켓 폴링 및 선택 용 장치 큐에서 패킷을 기다리는 시간을 마이크로 초 단위로 관리합니다. Red Hat은 50으로 설정할 것을 권장합니다.
  • 소켓에 SO_BUSY_POLL 소켓 옵션을 추가합니다.
글로벌 비지 폴링을 사용하는 경우 sysctl.net.core.busy_read0 이외의 값으로 설정해야 합니다. 이 매개 변수는 소켓의 읽기 용 장치 큐에서 패킷을 기다리는 시간을 마이크로 초 단위로 관리합니다. 또한 SO_BUSY_POLL 옵션의 기본값이 설정됩니다. Red Hat은 소켓 수가 적은 경우 50으로 소켓 수가 많은 경우 100으로 설정할 것을 권장합니다. 소켓 수가 너무 많은 경우 (수백 이상) 대신 epoll을 사용합니다.
비지 폴링 동작은 다음 드라이버에 의해 지원됩니다. 이러한 드라이버는 Red Hat Enterprise Linux 7에서 지원됩니다.
  • bnx2x
  • be2net
  • ixgbe
  • mlx4
  • myri10ge
Red Hat Enterprise Linux 7.1에서 다음 명령을 실행하여 특정 장치가 비지 폴링을 지원하는지에 대한 여부를 확인할 수 있습니다.
# ethtool -k device | grep "busy-poll"
busy-poll: on [fixed]을 반환할 경우 장치에서 비지 폴링을 사용할 수 있습니다.

6.3.4. 소켓 수신 큐 설정

분석 결과에서 소켓 큐 배출 비율이 너무 낮아 패킷이 드롭되는 현상이 나타날 경우 이러한 성능 문제를 완화시킬 수 있는 몇 가지 방법이 있습니다.
들어오는 트래픽 속도 감소
패킷이 큐에 도달하기전 필터링 또는 드롭되거나 장치 가중치를 낮춰 큐가 채워지는 비율을 감소시킵니다.
애플리케이션의 소켓 큐 깊이 증가
제한된 트래픽을 연속적으로 수신하는 소켓 큐의 경우 연속적 트랙픽 크기에 맞게 소켓큐의 깊이를 증가시키면 패킷이 드롭되지 않게 할 수 있습니다.

6.3.4.1. 들어오는 트래픽 속도 감소

들어오는 트래픽을 필터링하거나 네트워크 인터페이스 카드의 장치 가중치를 낮게하여 들어 오는 트랙픽 속도를 늦출 수 있습니다. 들어오는 트래픽을 필터링하는 방법에 대한 자세한 내용은 http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/Red Hat Enterprise Linux 7 Security Guide에서 참조하십시오.
장치 가중치는 한 번에 (한 번의 스케줄된 프로세서에 액세스) 장치가 수신할 수 있는 패킷 수를 말합니다. 장치 가중치는 dev_weight 매개 변수에 의해 관리됩니다. 이러한 매개 변수는 /proc/sys/net/core/dev_weight 파일 내용을 변경하여 일시적으로 변경하거나 procps-ng 패키지에서 제공하는 sysctl를 사용하여 영구적으로 변경할 수 있습니다.

6.3.4.2. 큐 깊이 증가

애플리케이션 소켓 큐 깊이를 증가시키는 것이 소켓 큐 배출 비율을 개선하기 위한 가장 쉬운 방법이지만 이는 장기적 솔루션이 될 수 없습니다.
큐의 깊이를 증가시키려면 다음과 같이 변경하여 소켓 수신 버퍼 크기를 증가시킵니다:
/proc/sys/net/core/rmem_default 값을 증가
이 매개 변수는 소켓에서 사용되는 기본 수신 버퍼 크기를 관리합니다. 이 값은 /proc/sys/net/core/rmem_max 값보다 작아야 합니다.
setsockopt를 사용하여 SO_RCVBUF 값을 크게 설정
이 매개 변수는 소켓 수신 버퍼의 최대 크기를 바이트 단위로 관리합니다. getsockopt 시스템 호출을 사용하여 현재 버퍼 값을 확인합니다. 이 매개 변수에 대한 보다 자세한 내용은 man 페이지에서 참조하십시오:
$ man 7 socket

6.3.5. RSS (Receive-Side Scaling) 설정

멀티 큐 수신이라고 하는 RSS (Receive-Side Scaling)은 여러 하드웨어 기반 수신 큐에 걸처 네트워크 수신 프로세스를 분산시켜 인바운드 네트워크 트래픽을 여러 CPU에서 처리할 수 있습니다. RSS는 단일 CPU 오버로드에 의한 수신 인터럽트 처리에 있어서 병목 현상을 완화하고 네트워크 대기 시간을 감소시키는데 사용될 수 있습니다.
네트워크 인터페이스 카드가 RSS를 지원하는지 확인하려면 여러 인터럽트 요청 큐가 /proc/interrupts에 있는 인터페이스와 관련되어 있는지 확인합니다. 예를 들어 p1p1 인터페이스를 확인하려면 다음을 수행합니다:
# egrep 'CPU|p1p1' /proc/interrupts
   CPU0    CPU1    CPU2    CPU3    CPU4    CPU5
89:   40187       0       0       0       0       0   IR-PCI-MSI-edge   p1p1-0
90:       0     790       0       0       0       0   IR-PCI-MSI-edge   p1p1-1
91:       0       0     959       0       0       0   IR-PCI-MSI-edge   p1p1-2
92:       0       0       0    3310       0       0   IR-PCI-MSI-edge   p1p1-3
93:       0       0       0       0     622       0   IR-PCI-MSI-edge   p1p1-4
94:       0       0       0       0       0    2475   IR-PCI-MSI-edge   p1p1-5
위의 출력에서는 NIC 드라이버가 p1p1 인터페이스 (p1p1-5를 통한 p1p1-0)에 대해 6 수신 큐가 생성되었음을 보여주고 있습니다. 또한 각 큐에서 얼마나 많은 인터럽트가 프로세스되었는지와 어떤 CPU가 인터럽트를 처리했는지도 보여주고 있습니다. 이러한 경우 이러한 특정 NIC 드라이버가 CPU 당 하나의 큐를 생성하기 때문에 기본적으로 6 큐가 생성되어 있고 이러한 시스템에는 6 CPU가 있게 됩니다. 이는 NIC 드라이버에서 가장 일반적인 패턴입니다.
다른 방법으로 네트워크 드라이버가 로딩된 후 ls -1 /sys/devices/*/*/device_pci_address/msi_irqs 출력 결과를 확인할 수 있습니다. 예를 들어 PCI 주소가 0000:01:00.0인 장치를 확인하려면 다음 명령을 사용하여 해당 장치의 인터럽트 요청 큐를 나열할 수 있습니다:
# ls -1 /sys/devices/*/*/0000:01:00.0/msi_irqs
101
102
103
104
105
106
107
108
109
RSS는 기본적으로 활성화되어 있습니다. RSS 큐 수 (또는 네트워크 활동을 처리하는 CPU 수)는 해당 네트워크 장치 드라이버에서 설정됩니다. bnx2x 드라이버의 경우 num_queues에서 설정됩니다. sfc 드라이버의 경우 rss_cpus 매개 변수에서 설정됩니다. 이와 관계 없이 일반적으로 /sys/class/net/device/queues/rx-queue/에 설정됩니다. 여기서 device는 네트워크 장치 이름 (예: eth1)이고 rx-queue는 해당 장치 큐 이름입니다.
RSS 설정 시 Red Hat은 실제 CPU 코어 당 하나로 큐의 수를 제한할 것을 권장하고 있습니다. 분석 도구에서 하이퍼 스레드가 별도의 코어로 표시될 수 있지만 하이퍼 스레드와 같은 논리 코어를 포함한 모든 코어의 큐를 설정하는것은 네트워크 성능 향상에 도움이 되는지는 입증되어 있지 않습니다.
RSS가 활성화되어 있으면 이는 각 CPU가 큐에 등록된 처리 양에 따라 CPU 사이에서 네트워크 처리를 균등하게 분산합니다. 하지만 ethtool --show-rxfh-indir--set-rxfh-indir 매개 변수를 사용하여 네트워크 활동 분산 방법을 수정하거나 특정 네트워크 활동을 다른 활동 보다 더 중요한 것으로 가중치 부여할 수 있습니다.
irqbalance 데몬은 RSS와 함께 사용하여 노드간 메모리 전송 및 캐시 라인 반송 가능성을 감소시킬 수 있습니다. 이는 네트워크 패킷 처리 지연 시간을 줄일 수 있습니다.

6.3.6. RPS (Receive Packet Steering) 설정

RPS (Receive Packet Steering)은 특정 CPU 처리에 직접 패킷을 사용한다는 점에서 RSS와 유사합니다. 하지만 RPS는 소프트웨어 레벨에서 구현되며 단일 네트워크 인터페이스 카드의 하드웨어 큐의 네트워크 트래픽에서 병목현상이 발생하지 않도록 합니다.
RPS는 하드웨어 기반 RSS를 통해 다음과 같은 장점을 갖습니다:
  • RPS는 네트워크 인터페이스 카드와 함께 사용할 수 있습니다.
  • 새로운 프로토콜을 처리하기 위해 RPS에 소프트웨어 필터를 쉽게 추가할 수 있습니다.
  • RPS는 네트워크 장치의 하드웨어 인터럽트 비율을 증가시킬 수 없습니다. 하지만 내부 프로세서 인터럽트가 발생합니다.
RPS는 /sys/class/net/device/queues/rx-queue/rps_cpus 파일에서 네트워크 장치 및 수신 큐 마다 설정됩니다. 여기서 device는 네트워크 장치 (예: eth0) 이름이며 rx-queue는 해당 수신 큐 (예: rx-0) 이름입니다.
rps_cpus 파일의 기본값은 0입니다. 이는 RPS를 비활성화하여 네트워크 인터럽트를 처리하는 CPU가 패킷을 처리합니다.
RPS를 활성화하려면 특정 네트워크 장치 및 수신 큐에서 패킷을 처리하는 CPU에서 해당 rps_cpus 파일을 설정합니다.
rps_cpus 파일은 쉼표로 구분된 CPU 비트맵을 사용합니다. 따라서 CPU를 통해 인터페이스에서 수신 큐의 인터럽트를 처리하려면 비트맵을 1로 설정합니다. 예를 들어 CPU 0, 1, 2, 3의 인터럽트를 처리하려면 rps_cpus00001111 (1+2+4+8), 또는 f (15의 16 진수 값)로/으로 설정합니다.
단일 전송 큐가 있는 네트워크 장치의 경우 동일한 메모리 도메인에 있는 CPU를 사용하도록 RPS를 설정하여 최상의 성능이 나타나게 할 수 있습니다. 이는 비 NUMA 시스템에서 모든 사용 가능한 CPU를 사용할 수 있음을 의미합니다. 네트워크 인터럽트 비율이 너무 높을 경우 네트워크 인터럽트를 처리하는 CPU를 제외시켜 성능을 개선할 수 있습니다.
여러 큐가 있는 네트워크 장치의 경우 일반적으로 RPS 및 RSS 모두를 설정할 경우 장점이 없습니다. RSS는 기본적으로각 수신 큐에 CPU를 맵핑하도록 설정되기 때문입니다. 하지만 CPU 보다 하드웨어 큐가 적고 동일한 메모리 도메인에서 CPU를 사용하도록 RPS가 설정되어 있는 경우 RPS는 장점이 될 수 있습니다.

6.3.7. RFS (Receive Flow Steering) 설정

RFS (Receive Flow Steering)는 RPS 동작을 확장한 것으로 CPU 캐시 적중률을 높이고 네트워크 대기 시간을 줄이기 위한 것입니다. RPS는 큐 길이에 따라 패킷을 전송하지만 RFS는 최적의 CPU를 계산하기 위해 RPS 백엔드를 사용하고 패킷을 소비하는 애플리케이션의 위치에 따라 패킷을 전송합니다. 이로 인해 CPU 캐시 효율성이 증가합니다.
RFS는 기본적으로 비활성화되어 있습니다. RFS를 활성화하려면 다음의 두 파일을 편집해야 합니다:
/proc/sys/net/core/rps_sock_flow_entries
이 파일의 값을 동시에 활성화할 최대 연결 예상 수로 설정합니다. 일반적인 서버 부하의 경우 32768로 설정하는 것이 좋습니다. 입력된 모든 값은 가장 가까운 2의 거듭 제곱으로 반올림됩니다.
/sys/class/net/device/queues/rx-queue/rps_flow_cnt
device는 설정하고자 하는 네트워크 장치 이름 (예: eth0)으로 rx-queue는 설정하고자 하는 수신 큐 (예: rx-0)로 변경합니다.
이 파일 값을 N으로 나눈 rps_sock_flow_entries 값으로 설정합니다. 여기서 N은 장치의 수신 큐 수입니다. 예를 들어 rps_flow_entries32768로 설정되어 있고 16 개의 설정된 수신 큐가 있을 경우 rps_flow_cnt2048로 설정해야 합니다. 단일 큐 장치의 경우 rps_flow_cnt 값은 rps_sock_flow_entries 값과 동일합니다.
단일 전송자로 부터 수신된 데이터는 여러 CPU에 전송되지 않습니다. 단일 전송자로 부터 수신된 데이터 양이 단일 CPU가 처리할 수 있는 양 보다 많을 경우 프레임 크기를 크기 설정하여 인터럽트 수를 줄이고 결국 CPU 프로셋스 양을 줄일 수 있습니다. 다른 방법으로 NIC 오프로드 옵션 이나 빠른 CPU 사용을 고려해 볼 수 있습니다.
RFS와 함께 numactl 또는 taskset을 사용하여 애플리케이션을 특정 코어, 소켓 또는 NUMA 노드에 고정할 수 있습니다. 이를 통해 패킷이 잘못 처리되지 않게 할 수 있습니다.

6.3.8. 가속 RFS 설정

가속 RFS는 하드웨어 지원을 추가하여 RFS 속도를 높일 수 있습니다. RFS 처럼 패킷은 패킷을 소비하는 애플리케이션 위치에 따라 전송됩니다. 하지만 기존 RFS와는 다르게 패킷은 데이터를 소비하는 스레드 로컬인 CPU (애플리케이션을 실행하는 CPU 또는 캐시 계층에 있는 CPU의 CPU 로컬 중 하나)에 직접 전송됩니다.
가속 RFS는 다음과 같은 조건이 충족되는 경우에만 사용할 수 있습니다:
  • 가속 RFS는 네트워크 인터페이스 카드에 의해 지원되어야 합니다. 가속 RFS는 ndo_rx_flow_steer() netdevice 함수를 내보내는 카드에 의해 지원됩니다.
  • ntuple 필터링이 활성화되어 있어야 합니다.
이러한 조건이 충족되면 큐 맵핑에서의 CPU는 기존 RFS 설정에 따라 자동으로 추론됩니다. 즉 큐 맵핑에서의 CPU는 각 수신 큐의 드라이버에 의해 설정되는 IRQ 친화도에 따라 추론됩니다. 기존 RFS 설정에 대한 자세한 내용은 6.3.7절. “RFS (Receive Flow Steering) 설정 ”에서 참조하십시오.
Red Hat은 RFS 사용이 적합한 상황에서 네트워크 인터페이스 카드가 하드웨어 가속을 지원하는 경우 가속 RFS 사용을 권장하고 있습니다.