HTTP ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಲು Linux ಪರಿಸರವನ್ನು ಟ್ಯೂನ್ ಮಾಡುವ ಕುರಿತು ವಿವರವಾದ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಪ್ರಕಟಿಸಲಾಗಿದೆ. ಪ್ರಸ್ತಾವಿತ ವಿಧಾನಗಳು ಅಮೆಜಾನ್ EC2 ಪರಿಸರದಲ್ಲಿ (4 vCPU) ಲೈಬ್ರೆಕ್ಟರ್ ಲೈಬ್ರರಿಯನ್ನು ಆಧರಿಸಿದ JSON ಪ್ರೊಸೆಸರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 224 ಸಾವಿರ API ವಿನಂತಿಗಳಿಂದ Amazon Linux 2 ನ ಪ್ರಮಾಣಿತ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಕರ್ನಲ್ 4.14 ರಿಂದ 1.2 ಮಿಲಿಯನ್ ವಿನಂತಿಗಳನ್ನು ಹೆಚ್ಚಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಆಪ್ಟಿಮೈಸೇಶನ್ ನಂತರ ಎರಡನೆಯದು (436% ಹೆಚ್ಚಳ), ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಲ್ಲಿ ವಿಳಂಬವನ್ನು 79% ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಲು ಕಾರಣವಾಯಿತು. ಪ್ರಸ್ತಾವಿತ ವಿಧಾನಗಳು ಲಿಬ್ರೆಕ್ಟರ್‌ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿಲ್ಲ ಮತ್ತು nginx, Actix, Netty ಮತ್ತು Node.js ಸೇರಿದಂತೆ ಇತರ http ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸುವಾಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ (ಲಿಬ್ರೆಕ್ಟರ್ ಅನ್ನು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಬಳಸಲಾಗಿದೆ ಏಕೆಂದರೆ ಅದರ ಆಧಾರದ ಮೇಲೆ ಪರಿಹಾರವು ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತೋರಿಸಿದೆ).
ಮೂಲ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು:
- ಲಿಬ್ರೆಕ್ಟರ್ ಕೋಡ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸಲಾಗುತ್ತಿದೆ. ಟೆಕ್‌ಪವರ್ ಕಿಟ್‌ನಿಂದ R18 ಆಯ್ಕೆಯನ್ನು ಆಧಾರವಾಗಿ ಬಳಸಲಾಗಿದೆ, ಬಳಸಿದ CPU ಕೋರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಸುಧಾರಿಸಲಾಗಿದೆ (ಆಪ್ಟಿಮೈಸೇಶನ್ ಕೆಲಸವನ್ನು 25-27% ರಷ್ಟು ವೇಗಗೊಳಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು), "-O3" ಆಯ್ಕೆಗಳೊಂದಿಗೆ GCC ಯಲ್ಲಿ ಜೋಡಿಸುವುದು (5-10% ಹೆಚ್ಚಳ) ಮತ್ತು "-ಮಾರ್ಚ್-ನೇಟಿವ್" (5-10%), ಓದುವ/ಬರೆಯುವ ಕರೆಗಳನ್ನು recv/send (5-10%) ನೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು ಮತ್ತು pthreads ಬಳಸುವಾಗ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು (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” (ಸ್ಪೆಕ್ಟರ್ v1 + SWAPGS ನಿಂದ ರಕ್ಷಣೆ) ಪ್ಯಾರಾಮೀಟರ್‌ನಿಂದ ಹೆಚ್ಚಳವು 1-2%, “nospectre_v2” (ಸ್ಪೆಕ್ಟರ್ v2 ನಿಂದ ರಕ್ಷಣೆ) - 15-20%, "pti=off" (Spectre v3/Meltdown) - 6 %, "mds=off tsx_async_abort=off" (MDS/Zombieload ಮತ್ತು TSX ಅಸಿಂಕ್ರೊನಸ್ ಅಬಾರ್ಟ್) - 6%. L1TF/Foreshadow (l1tf=flush), iTLB ಮಲ್ಟಿಹಿಟ್, ಸ್ಪೆಕ್ಯುಲೇಟಿವ್ ಸ್ಟೋರ್ ಬೈಪಾಸ್ ಮತ್ತು SRBDS ದಾಳಿಗಳ ವಿರುದ್ಧ ರಕ್ಷಣೆಗಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಗದೆ ಬಿಡಲಾಗಿದೆ, ಇದು ಪರೀಕ್ಷಿತ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ಛೇದಿಸದ ಕಾರಣ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಲಿಲ್ಲ (ಉದಾಹರಣೆಗೆ, KVM ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ, ನೆಸ್ಟೆಡ್ ವರ್ಚುವಲೈಸೇಶನ್ ಮತ್ತು ಇತರ CPU ಮಾದರಿಗಳು).
- "auditctl -a never,task" ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಆಡಿಟಿಂಗ್ ಮತ್ತು ಸಿಸ್ಟಮ್ ಕರೆ ನಿರ್ಬಂಧಿಸುವ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಮತ್ತು ಡಾಕರ್ ಕಂಟೇನರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ "--security-opt seccomp=unconfined" ಆಯ್ಕೆಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು. ಒಟ್ಟಾರೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವು 11% ಆಗಿತ್ತು, ಮತ್ತು ಥ್ರೋಪುಟ್ 446k req/s ನಿಂದ 495k req/s ಗೆ ಹೆಚ್ಚಾಯಿತು.
- ಸಂಬಂಧಿತ ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಅನ್‌ಲೋಡ್ ಮಾಡುವ ಮೂಲಕ iptables/netfilter ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತಿದೆ. ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್ ಪರಿಹಾರದಲ್ಲಿ ಬಳಸದ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಕಲ್ಪನೆಯು ಪ್ರೊಫೈಲಿಂಗ್ ಫಲಿತಾಂಶಗಳಿಂದ ಪ್ರೇರೇಪಿಸಲ್ಪಟ್ಟಿದೆ, nf_hook_slow ಕಾರ್ಯವು ಕಾರ್ಯಗತಗೊಳಿಸಲು 18% ಸಮಯವನ್ನು ತೆಗೆದುಕೊಂಡಿತು. nftables iptables ಗಿಂತ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಗಮನಿಸಲಾಗಿದೆ, ಆದರೆ Amazon Linux iptables ಅನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ. iptables ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ನಂತರ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವು 22% ಆಗಿತ್ತು, ಮತ್ತು ಥ್ರೋಪುಟ್ 495k req/s ನಿಂದ 603k req/s ಗೆ ಹೆಚ್ಚಾಯಿತು.
- ಪ್ರೊಸೆಸರ್ ಕ್ಯಾಶ್ ಬಳಕೆಯ ದಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸಲು ವಿಭಿನ್ನ CPU ಕೋರ್‌ಗಳ ನಡುವೆ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳ ವಲಸೆಯನ್ನು ಕಡಿಮೆಗೊಳಿಸಲಾಗಿದೆ. ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಸಿಪಿಯು ಕೋರ್‌ಗಳಿಗೆ ಬಂಧಿಸುವ ಲಿಬ್ರೆಕ್ಟರ್ ಪ್ರಕ್ರಿಯೆಗಳ ಮಟ್ಟದಲ್ಲಿ (ಸಿಪಿಯು ಪಿನ್ನಿಂಗ್) ಮತ್ತು ಪಿನ್ನಿಂಗ್ ಕರ್ನಲ್ ನೆಟ್ವರ್ಕ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳ ಮೂಲಕ (ಸೈಡ್ ಸ್ಕೇಲಿಂಗ್ ಸ್ವೀಕರಿಸಿ) ನಡೆಸಲಾಯಿತು. ಉದಾಹರಣೆಗೆ, irqbalance ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು CPU ಗೆ ಕ್ಯೂ ಅಫಿನಿಟಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ /proc/irq/$IRQ/smp_affinity_list ನಲ್ಲಿ ಹೊಂದಿಸಲಾಗಿದೆ. ಲಿಬ್ರೆಕ್ಟರ್ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳ ನೆಟ್ವರ್ಕ್ ಕ್ಯೂ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅದೇ CPU ಕೋರ್ ಅನ್ನು ಬಳಸಲು, ಕಸ್ಟಮ್ BPF ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಸಾಕೆಟ್ ಅನ್ನು ರಚಿಸುವಾಗ SO_ATTACH_REUSEPORT_CBPF ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಸಂಪರ್ಕಿಸಲಾಗುತ್ತದೆ. CPU ಗೆ ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಾಲುಗಳನ್ನು ಬಂಧಿಸಲು, ಸೆಟ್ಟಿಂಗ್‌ಗಳು /sys/class/net/eth0/queues/tx-/xps_cpus ಅನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ. ಒಟ್ಟಾರೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವು 38% ಆಗಿತ್ತು, ಮತ್ತು ಥ್ರೋಪುಟ್ 603k req/s ನಿಂದ 834k req/s ಗೆ ಏರಿತು.
- ಅಡಚಣೆ ನಿರ್ವಹಣೆ ಮತ್ತು ಮತದಾನದ ಬಳಕೆಯ ಆಪ್ಟಿಮೈಸೇಶನ್. ENA ಡ್ರೈವರ್‌ನಲ್ಲಿ ಅಡಾಪ್ಟಿವ್-ಆರ್‌ಎಕ್ಸ್ ಮೋಡ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಮತ್ತು sysctl net.core.busy_read ಅನ್ನು ನಿರ್ವಹಿಸುವುದರಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು 28% ಹೆಚ್ಚಿಸಿದೆ (ಥ್ರೂಪುಟ್ 834k req/s ನಿಂದ 1.06M req/s ಗೆ ಹೆಚ್ಚಿದೆ, ಮತ್ತು ಲೇಟೆನ್ಸಿ 361μs ನಿಂದ 292μs ಗೆ ಕಡಿಮೆಯಾಗಿದೆ).
- ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್ನಲ್ಲಿ ಅನಗತ್ಯ ನಿರ್ಬಂಧಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗುವ ಸಿಸ್ಟಮ್ ಸೇವೆಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು. dhclient ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಮತ್ತು IP ವಿಳಾಸವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಹೊಂದಿಸುವುದರಿಂದ 6% ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳ ಮತ್ತು ಥ್ರೋಪುಟ್ 1.06M req/s ನಿಂದ 1.12M req/s ಗೆ ಹೆಚ್ಚಾಯಿತು. dhclient ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಲು ಕಾರಣವೆಂದರೆ ಕಚ್ಚಾ ಸಾಕೆಟ್ ಅನ್ನು ಬಳಸುವ ಸಂಚಾರ ವಿಶ್ಲೇಷಣೆ.
- ಸ್ಪಿನ್ ಲಾಕ್ ಫೈಟಿಂಗ್. sysctl "net.core.default_qdisc=noqueue" ಮತ್ತು "tc qdisc ರಿಪ್ಲೇಸ್ dev eth0 root mq" ಮೂಲಕ ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್ ಅನ್ನು "noqueue" ಮೋಡ್‌ಗೆ ಬದಲಾಯಿಸುವುದರಿಂದ 2% ಕಾರ್ಯಕ್ಷಮತೆ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಯಿತು ಮತ್ತು ಥ್ರೋಪುಟ್ 1.12M req/s ನಿಂದ 1.15M ಗೆ ಹೆಚ್ಚಾಯಿತು. req/s.
- "ethtool -K eth0 gro off" ಆಜ್ಞೆಯೊಂದಿಗೆ GRO (ಜೆನೆರಿಕ್ ರಿಸೀವ್ ಆಫ್‌ಲೋಡ್) ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವಂತಹ ಅಂತಿಮ ಸಣ್ಣ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು ಮತ್ತು sysctl "net.ipv4.tcp_congestion_control=reno" ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಯೂಬಿಕ್ ದಟ್ಟಣೆ ನಿಯಂತ್ರಣ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ರೆನೊದೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು. ಒಟ್ಟಾರೆ ಉತ್ಪಾದಕತೆಯ ಹೆಚ್ಚಳವು 4% ಆಗಿತ್ತು. ಥ್ರೋಪುಟ್ 1.15M req/s ನಿಂದ 1.2M req/s ಗೆ ಹೆಚ್ಚಿದೆ.
ಕೆಲಸ ಮಾಡಿದ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳ ಜೊತೆಗೆ, ನಿರೀಕ್ಷಿತ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗದ ವಿಧಾನಗಳನ್ನು ಸಹ ಲೇಖನವು ಚರ್ಚಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕೆಳಗಿನವುಗಳು ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಹೊರಹೊಮ್ಮಿದವು:
- ಲಿಬ್ರೆಕ್ಟರ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಚಲಾಯಿಸುವುದು ಅದನ್ನು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಓಡಿಸುವುದಕ್ಕಿಂತ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ. ರೈಟೆವ್ ಅನ್ನು ಕಳುಹಿಸುವುದರೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು, epoll_wait ನಲ್ಲಿ ಮ್ಯಾಕ್ಸೆವೆಂಟ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸುವುದು ಮತ್ತು GCC ಆವೃತ್ತಿಗಳು ಮತ್ತು ಫ್ಲ್ಯಾಗ್‌ಗಳ ಪ್ರಯೋಗವು ಯಾವುದೇ ಪರಿಣಾಮವನ್ನು ಬೀರಲಿಲ್ಲ (ಪರಿಣಾಮವು "-O3" ಮತ್ತು "-march-native" ಫ್ಲ್ಯಾಗ್‌ಗಳಿಗೆ ಮಾತ್ರ ಗಮನಾರ್ಹವಾಗಿದೆ).
- SCHED_FIFO ಮತ್ತು SCHED_RR ಶೆಡ್ಯೂಲರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು Linux ಕರ್ನಲ್ ಅನ್ನು ಆವೃತ್ತಿ 4.19 ಮತ್ತು 5.4 ಗೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns ಅನ್ನು ಮ್ಯಾನಿಪುಲೇಟ್ ಮಾಡುವುದು, transparent_clock=hugets did not affect.
- 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