ಪರಿಸರವನ್ನು ಶ್ರುತಿಗೊಳಿಸುವ ವಿವರವಾದ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಪ್ರಕಟಿಸಲಾಗಿದೆ. Linux HTTP ವಿನಂತಿ ಪ್ರಕ್ರಿಯೆಗೆ ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಲು. ಪ್ರಸ್ತಾವಿತ ವಿಧಾನಗಳು Amazon EC2 ಪರಿಸರದಲ್ಲಿ (4 vCPU ಗಳು) ಲಿಬ್ರೆಕ್ಟರ್ ಲೈಬ್ರರಿಯನ್ನು ಆಧರಿಸಿದ JSON ಪಾರ್ಸರ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರಮಾಣಿತ Amazon ಸೆಟ್ಟಿಂಗ್ಗಳ ಅಡಿಯಲ್ಲಿ ಸೆಕೆಂಡಿಗೆ 224 API ವಿನಂತಿಗಳಿಂದ ಹೆಚ್ಚಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟವು. Linux ಕರ್ನಲ್ 4.14 ನೊಂದಿಗೆ 2 ಆಪ್ಟಿಮೈಸೇಶನ್ ನಂತರ ಥ್ರೋಪುಟ್ ಅನ್ನು ಸೆಕೆಂಡಿಗೆ 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" (ಸ್ಪೆಕ್ಟರ್ v3/Meltdown) - 6%, "mds=off tsx_async_abort=off" (MDS/Zombieload ಮತ್ತು TSX ಅಸಮಕಾಲಿಕ ಅಬಾರ್ಟ್) - 6%. L1TF/Foreshadow ದಾಳಿಗಳು (l1tf=flush), iTLB ಮಲ್ಟಿಹಿಟ್, ಸ್ಪೆಕ್ಯುಲೇಟಿವ್ ಸ್ಟೋರ್ ಬೈಪಾಸ್ ಮತ್ತು SRBDS ವಿರುದ್ಧ ರಕ್ಷಣೆಗಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಅವು ಪರೀಕ್ಷಿಸಲಾದ ಸಂರಚನೆಯೊಂದಿಗೆ ಛೇದಿಸಲಿಲ್ಲ (ಉದಾಹರಣೆಗೆ, ಅವು ನಿರ್ದಿಷ್ಟವಾಗಿವೆ ಕೆವಿಎಂ, ನೆಸ್ಟೆಡ್ ವರ್ಚುವಲೈಸೇಶನ್ ಮತ್ತು ಇತರ 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" ಫ್ಲ್ಯಾಗ್ಗಳಿಗೆ ಮಾತ್ರ ಗಮನಾರ್ಹವಾಗಿದೆ).
- ಕರ್ನಲ್ ನವೀಕರಣವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಲಿಲ್ಲ. Linux ಆವೃತ್ತಿ 4.19 ಮತ್ತು 5.4 ರವರೆಗೆ, SCHED_FIFO ಮತ್ತು SCHED_RR ಶೆಡ್ಯೂಲರ್ಗಳನ್ನು ಬಳಸಿ, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 ಮತ್ತು clocksource=tsc ಅನ್ನು ಕುಶಲತೆಯಿಂದ ನಿರ್ವಹಿಸುತ್ತದೆ.
- 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
