초당 1.2만 JSON 요청을 처리하는 Linux 최적화

HTTP 요청 처리를 위한 최대 성능을 달성하기 위해 Linux 환경을 조정하는 방법에 대한 자세한 가이드가 게시되었습니다. 제안된 방법을 사용하면 Amazon EC2 환경(4 vCPU)의 libreactor 라이브러리 기반 JSON 프로세서의 성능을 커널당 224만 요청으로 구성된 Amazon Linux 2의 표준 설정으로 초당 4.14개의 API 요청에서 1.2만 요청으로 향상시킬 수 있었습니다. 최적화 후 436위(79% 증가)를 기록했으며 요청 처리 지연도 XNUMX% 감소했습니다. 제안된 방법은 libreactor에만 국한되지 않으며 nginx, Actix, Netty 및 Node.js를 포함한 다른 http 서버를 사용할 때 작동합니다(libreactor 기반 솔루션이 더 나은 성능을 보여 테스트에 사용되었습니다).

기본 최적화:

• libreactor 코드 최적화. Techempower 키트의 R18 옵션이 기본으로 사용되었으며, 사용된 CPU 코어 수를 제한하는 코드를 제거하고(최적화를 통해 작업 속도를 25~27% 향상) "-O3" 옵션을 사용하여 GCC에서 조립하여 개선되었습니다. (5-10% 증가) 및 "-march-native"(5-10%), 읽기/쓰기 호출을 recv/send(5-10%)로 대체하고 pthread 사용 시 오버헤드 감소(2-3%) . 코드 최적화 후 전체 성능은 55% 증가했으며 처리량은 224k req/s에서 347k req/s로 증가했습니다.
• 추측 실행 취약점에 대한 보호를 비활성화합니다. 커널을 로드할 때 "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" 매개변수를 사용하면 성능이 28% 증가하고 처리량이 347k req/s에서 446k req/s로 증가했습니다. 이와 별도로 "nospectre_v1"(Spectre v1 + SWAPGS 보호) 매개변수의 증가는 1-2%, "nospectre_v2"(Spectre v2로부터 보호) - 15-20%, "pti=off"(Spectre v3/Meltdown)입니다. - 6%, "mds=off tsx_async_abort=off"(MDS/Zombieload 및 TSX 비동기 중단) - 6%. L1TF/Foreshadow(l1tf=flush), iTLB 다중 적중, Speculative Store Bypass 및 SRBDS 공격에 대한 보호 설정은 변경되지 않은 채로 유지되었으며, 이는 테스트된 구성과 교차하지 않았기 때문에 성능에 영향을 미치지 않았습니다(예: KVM에 특정, 중첩됨). 가상화 및 기타 CPU 모델).
• Docker 컨테이너를 시작할 때 "auditctl -a never,task" 명령을 사용하고 "--security-opt seccomp=unconfined" 옵션을 지정하여 감사 및 시스템 호출 차단 메커니즘을 비활성화합니다. 전반적인 성능은 11% 증가했으며 처리량은 446 req/s에서 495 req/s로 증가했습니다.
• 관련 커널 모듈을 언로드하여 iptables/netfilter를 비활성화합니다. 특정 서버 솔루션에서는 사용되지 않았던 방화벽을 비활성화하려는 아이디어는 프로파일링 결과에서 nf_hook_slow 함수 실행 시간이 18% 소요된 것으로 판단되어 촉발되었습니다. nftables는 iptables보다 더 효율적으로 작동하지만 Amazon Linux는 계속해서 iptables를 사용합니다. iptables를 비활성화한 후 성능은 22% 증가했고 처리량은 495k req/s에서 603k req/s로 증가했습니다.
• 프로세서 캐시 사용 효율성을 높이기 위해 서로 다른 CPU 코어 간의 핸들러 마이그레이션을 줄였습니다. 최적화는 libreactor 프로세스를 CPU 코어에 바인딩하는 수준(CPU Pinning)과 커널 네트워크 핸들러 고정(Receive Side Scaling)을 통해 수행되었습니다. 예를 들어, irqbalance는 비활성화되었고 CPU에 대한 대기열 선호도는 /proc/irq/$IRQ/smp_affinity_list에 명시적으로 설정되었습니다. libreactor 프로세스와 수신 패킷의 네트워크 큐를 처리하기 위해 동일한 CPU 코어를 사용하려면 소켓을 생성할 때 SO_ATTACH_REUSEPORT_CBPF 플래그를 설정하여 연결되는 사용자 지정 BPF 핸들러가 사용됩니다. 나가는 패킷의 대기열을 CPU에 바인딩하기 위해 /sys/class/net/eth0/queues/tx- 설정이 변경되었습니다. /xps_cpus. 전반적인 성능은 38% 증가했으며 처리량은 603k req/s에서 834k req/s로 증가했습니다.
• 인터럽트 처리 및 폴링 사용 최적화. ENA 드라이버에서adaptive-rx 모드를 활성화하고 sysctl net.core.busy_read를 조작하면 성능이 28% 향상되었습니다(처리량은 834k req/s에서 1.06M req/s로 증가하고 대기 시간은 361μs에서 292μs로 감소).
• 네트워크 스택에서 불필요한 차단을 초래하는 시스템 서비스를 비활성화합니다. dhclient를 비활성화하고 IP 주소를 수동으로 설정하면 성능이 6% 증가하고 처리량이 1.06M 요청/초에서 1.12M 요청/초로 증가했습니다. dhclient가 성능에 영향을 미치는 이유는 원시 소켓을 사용한 트래픽 분석에 있습니다.
• 파이팅 스핀 락. sysctl "net.core.default_qdisc=noqueue" 및 "tc qdisc replacement dev eth0 root mq"를 통해 네트워크 스택을 "noqueue" 모드로 전환하면 성능이 2% 증가하고 처리량이 1.12M req/s에서 1.15M로 증가했습니다. 요청/초
• "ethtool -K eth0 gro off" 명령을 사용하여 GRO(일반 수신 오프로드)를 비활성화하고 sysctl "net.ipv4.tcp_congestion_control=reno"를 사용하여 큐빅 혼잡 제어 알고리즘을 reno로 바꾸는 등의 최종 사소한 최적화입니다. 전반적인 생산성 증가는 4%였습니다. 처리량이 1.15만 요청/초에서 1.2만 요청/초로 증가했습니다.

이 기사에서는 효과가 있었던 최적화 외에도 예상되는 성능 향상으로 이어지지 못한 방법에 대해서도 설명합니다. 예를 들어 다음은 효과가 없는 것으로 나타났습니다.

• libreactor를 별도로 실행해도 컨테이너에서 실행하는 것과 성능이 다르지 않았습니다. writev를 send로 바꾸고, epoll_wait에서 maxevents를 늘리고, GCC 버전과 플래그를 실험해도 효과가 없었습니다(효과는 "-O3" 및 "-march-native" 플래그에서만 눈에 띄었습니다).
• SCHED_FIFO 및 SCHED_RR 스케줄러를 사용하고 sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never,skew_tick=4.19 및 clocksource=tsc를 조작하여 Linux 커널을 버전 5.4 및 1로 업그레이드해도 성능에 영향을 미치지 않았습니다.
• ENA 드라이버에서 오프로드 모드(세그먼트화, 분산 수집, rx/tx 체크섬) 활성화, "-O3" 플래그를 사용한 구축, ena.rx_queue_size 및 ena.force_large_llq_header 매개변수 사용은 효과가 없었습니다.
• 네트워크 스택의 변경으로 인해 성능이 향상되지 않았습니다.
  • IPv6 비활성화: ipv6.disable=1
  • VLAN 비활성화: modprobe -rv 8021q
  • 패키지 소스 확인 비활성화
    • net.ipv4.conf.all.rp_filter=0
    • net.ipv4.conf.eth0.rp_filter=0
    • net.ipv4.conf.all.accept_local=1(부정적인 효과)
  • net.ipv4.tcp_sack = 0
  • net.ipv4.tcp_dsack=0
  • net.ipv4.tcp_mem/tcp_wmem/tcp_rmem
  • net.core.netdev_budget
  • net.core.dev_weight
  • net.core.netdev_max_backlog
  • net.ipv4.tcp_slow_start_after_idle=0
  • net.ipv4.tcp_moderate_rcvbuf=0
  • net.ipv4.tcp_timestamps=0
  • net.ipv4.tcp_low_latency = 1
  • SO_PRIORITY
  • TCP_NODELAY

  출처 : opennet.ru