ਪ੍ਰਤੀ ਸਕਿੰਟ 1.2 ਮਿਲੀਅਨ JSON ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਲੀਨਕਸ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨਾ

HTTP ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਲੀਨਕਸ ਵਾਤਾਵਰਣ ਨੂੰ ਟਿਊਨ ਕਰਨ ਲਈ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਗਾਈਡ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਗਈ ਹੈ। ਪ੍ਰਸਤਾਵਿਤ ਤਰੀਕਿਆਂ ਨੇ ਐਮਾਜ਼ਾਨ EC2 ਵਾਤਾਵਰਨ (4 vCPU) ਵਿੱਚ ਲਾਇਬ੍ਰੇਕਟਰ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਆਧਾਰ 'ਤੇ JSON ਪ੍ਰੋਸੈਸਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ 224 ਹਜ਼ਾਰ API ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੋਂ ਕਰਨਲ 2 ਦੇ ਨਾਲ ਐਮਾਜ਼ਾਨ ਲੀਨਕਸ 4.14 ਦੀਆਂ ਸਟੈਂਡਰਡ ਸੈਟਿੰਗਾਂ ਨਾਲ ਪ੍ਰਤੀ ਸਕਿੰਟ 1.2 ਤੋਂ 436 ਮਿਲੀਅਨ ਬੇਨਤੀਆਂ ਨੂੰ ਵਧਾਉਣਾ ਸੰਭਵ ਬਣਾਇਆ ਹੈ। ਓਪਟੀਮਾਈਜੇਸ਼ਨ (79% ਦਾ ਵਾਧਾ) ਤੋਂ ਬਾਅਦ ਦੂਜਾ, ਅਤੇ ਇਹ ਵੀ XNUMX% ਦੁਆਰਾ ਪ੍ਰੋਸੈਸਿੰਗ ਬੇਨਤੀਆਂ ਵਿੱਚ ਦੇਰੀ ਵਿੱਚ ਕਮੀ ਦਾ ਕਾਰਨ ਬਣਿਆ। ਪ੍ਰਸਤਾਵਿਤ ਵਿਧੀਆਂ libreactor ਲਈ ਖਾਸ ਨਹੀਂ ਹਨ ਅਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਹੋਰ HTTP ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ nginx, Actix, Netty ਅਤੇ Node.js (ਲਿਬਰੇਕਟਰ ਨੂੰ ਟੈਸਟਾਂ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਸੀ ਕਿਉਂਕਿ ਇਸਦੇ ਆਧਾਰਿਤ ਹੱਲ ਨੇ ਬਿਹਤਰ ਕਾਰਗੁਜ਼ਾਰੀ ਦਿਖਾਈ ਸੀ)।

ਬੁਨਿਆਦੀ ਅਨੁਕੂਲਨ:

• ਲਿਬਰੇਕਟਰ ਕੋਡ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ। ਟੈਕਮਪਾਵਰ ਕਿੱਟ ਤੋਂ R18 ਵਿਕਲਪ ਨੂੰ ਆਧਾਰ ਵਜੋਂ ਵਰਤਿਆ ਗਿਆ ਸੀ, ਜਿਸ ਨੂੰ "-O25" ਵਿਕਲਪਾਂ ਦੇ ਨਾਲ GCC ਵਿੱਚ ਇਕੱਠਾ ਕਰਨ ਲਈ ਵਰਤੇ ਗਏ CPU ਕੋਰਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਲਈ ਕੋਡ ਨੂੰ ਹਟਾ ਕੇ ਸੁਧਾਰ ਕੀਤਾ ਗਿਆ ਸੀ (ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਨੇ ਕੰਮ ਨੂੰ 27-3% ਤੱਕ ਤੇਜ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਸੀ) (5-10% ਦਾ ਵਾਧਾ) ਅਤੇ "-ਮਾਰਚ-ਨੇਟਿਵ" (5-10%), ਰੀਡ/ਰਾਈਟ ਕਾਲਾਂ ਨੂੰ recv/ਭੇਜੋ (5-10%) ਨਾਲ ਬਦਲਣਾ ਅਤੇ pthreads (2-3%) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾਉਣਾ। . ਕੋਡ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਸਮੁੱਚੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਵਾਧਾ 55% ਸੀ, ਅਤੇ ਥ੍ਰੋਪੁੱਟ 224k ਬੇਨਤੀ/s ਤੋਂ 347k ਬੇਨਤੀ/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/ਮੇਲਟਡਾਊਨ) ਸੀ। - 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 ਬੇਨਤੀ/s ਤੋਂ 495k ਬੇਨਤੀ/s ਤੱਕ ਵਧ ਗਈ।
• ਸੰਬੰਧਿਤ ਕਰਨਲ ਮੋਡੀਊਲਾਂ ਨੂੰ ਅਨਲੋਡ ਕਰਕੇ iptables/netfilter ਨੂੰ ਅਯੋਗ ਕਰਨਾ। ਫਾਇਰਵਾਲ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣ ਦਾ ਵਿਚਾਰ, ਜੋ ਕਿ ਇੱਕ ਖਾਸ ਸਰਵਰ ਹੱਲ ਵਿੱਚ ਨਹੀਂ ਵਰਤਿਆ ਗਿਆ ਸੀ, ਨੂੰ ਪਰੋਫਾਈਲਿੰਗ ਨਤੀਜਿਆਂ ਦੁਆਰਾ ਪੁੱਛਿਆ ਗਿਆ ਸੀ, ਜਿਸ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ ਕਿ nf_hook_slow ਫੰਕਸ਼ਨ ਨੂੰ ਚਲਾਉਣ ਲਈ 18% ਸਮਾਂ ਲੱਗਿਆ। ਇਹ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ nftables iptables ਨਾਲੋਂ ਵਧੇਰੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਐਮਾਜ਼ਾਨ ਲੀਨਕਸ iptables ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ। iptables ਨੂੰ ਅਸਮਰੱਥ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਵਾਧਾ 22% ਸੀ, ਅਤੇ ਥ੍ਰਰੂਪੁਟ 495k ਬੇਨਤੀ/s ਤੋਂ 603k ਬੇਨਤੀ/s ਤੱਕ ਵਧਿਆ।
• ਪ੍ਰੋਸੈਸਰ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਦੀ ਕੁਸ਼ਲਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਵੱਖ-ਵੱਖ CPU ਕੋਰਾਂ ਦੇ ਵਿਚਕਾਰ ਹੈਂਡਲਰ ਦੀ ਘਟਾਈ ਗਈ ਮਾਈਗ੍ਰੇਸ਼ਨ। ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਨੂੰ CPU ਕੋਰ (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 ਬੇਨਤੀ/s ਤੋਂ 834k ਬੇਨਤੀ/s ਤੱਕ ਵਧ ਗਈ।
• ਰੁਕਾਵਟ ਹੈਂਡਲਿੰਗ ਅਤੇ ਪੋਲਿੰਗ ਦੀ ਵਰਤੋਂ ਦਾ ਅਨੁਕੂਲਨ। ENA ਡਰਾਈਵਰ ਵਿੱਚ ਅਡੈਪਟਿਵ-rx ਮੋਡ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣਾ ਅਤੇ sysctl net.core.busy_read ਵਿੱਚ ਹੇਰਾਫੇਰੀ ਕਰਨ ਨਾਲ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ 28% ਦਾ ਵਾਧਾ ਹੋਇਆ ਹੈ (ਥਰੂਪੁਟ 834k req/s ਤੋਂ 1.06M req/s ਤੱਕ ਵਧਿਆ ਹੈ, ਅਤੇ ਲੇਟੈਂਸੀ 361μs ਤੋਂ 292μs ਤੱਕ ਘਟ ਗਈ ਹੈ)।
• ਸਿਸਟਮ ਸੇਵਾਵਾਂ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣਾ ਜੋ ਨੈੱਟਵਰਕ ਸਟੈਕ ਵਿੱਚ ਬੇਲੋੜੀ ਬਲਾਕਿੰਗ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। dhclient ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣ ਅਤੇ IP ਐਡਰੈੱਸ ਨੂੰ ਹੱਥੀਂ ਸੈੱਟ ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ 6% ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਵਾਧਾ ਹੋਇਆ ਹੈ ਅਤੇ ਥਰੂਪੁਟ 1.06M ਬੇਨਤੀ/s ਤੋਂ 1.12M ਬੇਨਤੀ/s ਤੱਕ ਵਧਿਆ ਹੈ। dhclient ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦਾ ਕਾਰਨ ਇੱਕ ਕੱਚੇ ਸਾਕਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟ੍ਰੈਫਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਹੈ।
• ਸਪਿਨ ਲਾਕ ਨਾਲ ਲੜਨਾ। sysctl “net.core.default_qdisc=noqueue” ਅਤੇ “tc qdisc replace dev eth0 root mq” ਰਾਹੀਂ ਨੈੱਟਵਰਕ ਸਟੈਕ ਨੂੰ “noqueue” ਮੋਡ ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ 2% ਵਾਧਾ ਹੋਇਆ, ਅਤੇ ਥ੍ਰਰੂਪੁਟ 1.12M ਬੇਨਤੀ/s ਤੋਂ ਵਧ ਕੇ 1.15M ਹੋ ਗਿਆ। ਬੇਨਤੀ/ਸ.
• ਅੰਤਮ ਮਾਮੂਲੀ ਅਨੁਕੂਲਤਾਵਾਂ, ਜਿਵੇਂ ਕਿ "ethtool -K eth0 gro off" ਕਮਾਂਡ ਨਾਲ GRO (ਜਨਰਿਕ ਰਿਸੀਵ ਆਫਲੋਡ) ਨੂੰ ਅਯੋਗ ਕਰਨਾ ਅਤੇ sysctl "net.ipv4.tcp_congestion_control=reno" ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਿਊਬਿਕ ਕੰਜੈਸ਼ਨ ਕੰਟਰੋਲ ਐਲਗੋਰਿਦਮ ਨੂੰ ਰੇਨੋ ਨਾਲ ਬਦਲਣਾ। ਕੁੱਲ ਉਤਪਾਦਕਤਾ ਵਾਧਾ 4% ਸੀ. ਥ੍ਰੋਅਪੁੱਟ 1.15M ਬੇਨਤੀ/ਸੈਕਿੰਡ ਤੋਂ 1.2M ਬੇਨਤੀ/ਸੈਕੰਡ ਤੱਕ ਵਧਿਆ ਹੈ।

ਓਪਟੀਮਾਈਜੇਸ਼ਨਾਂ ਤੋਂ ਇਲਾਵਾ ਜੋ ਕੰਮ ਕਰਦੇ ਹਨ, ਲੇਖ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਦੀ ਵੀ ਚਰਚਾ ਕਰਦਾ ਹੈ ਜੋ ਸੰਭਾਵਿਤ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਵਾਧਾ ਨਹੀਂ ਕਰਦੇ ਸਨ। ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ ਬੇਅਸਰ ਸਾਬਤ ਹੋਏ:

• ਲਿਬਰੇਕਟਰ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਚਲਾਉਣਾ ਇਸ ਨੂੰ ਕੰਟੇਨਰ ਵਿੱਚ ਚਲਾਉਣ ਨਾਲੋਂ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਵੱਖਰਾ ਨਹੀਂ ਸੀ। ਰਾਈਟਵ ਨੂੰ ਭੇਜਣ ਨਾਲ ਬਦਲਣਾ, epoll_wait ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਘਟਨਾਵਾਂ ਨੂੰ ਵਧਾਉਣਾ, ਅਤੇ GCC ਸੰਸਕਰਣਾਂ ਅਤੇ ਫਲੈਗਾਂ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨ ਦਾ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਹੋਇਆ (ਪ੍ਰਭਾਵ ਸਿਰਫ "-O3" ਅਤੇ "-ਮਾਰਚ-ਨੇਟਿਵ" ਫਲੈਗਾਂ ਲਈ ਧਿਆਨ ਦੇਣ ਯੋਗ ਸੀ)।
• ਲੀਨਕਸ ਕਰਨਲ ਨੂੰ ਵਰਜਨ 4.19 ਅਤੇ 5.4 ਵਿੱਚ ਅੱਪਗਰੇਡ ਕਰਨਾ, SCHED_FIFO ਅਤੇ SCHED_RR ਸ਼ਡਿਊਲਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, tskew=tskew=1 ਅਤੇ ctskew=XNUMX ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕੀਤਾ।
• 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