HTTP درخواستوں پر کارروائی کے لیے زیادہ سے زیادہ کارکردگی حاصل کرنے کے لیے لینکس کے ماحول کو ٹیوننگ کرنے کے لیے ایک تفصیلی گائیڈ شائع کیا گیا ہے۔ مجوزہ طریقوں نے ایمیزون ای سی 2 ماحول (4 وی سی پی یو) میں لائبرییکٹر لائبریری پر مبنی JSON پروسیسر کی کارکردگی کو 224 ہزار API درخواستوں فی سیکنڈ سے بڑھانا ممکن بنایا جس میں ایمیزون لینکس 2 کی معیاری ترتیبات کے ساتھ کرنل 4.14 سے 1.2 ملین درخواستیں فی سیکنڈ ہیں۔ اصلاح کے بعد دوسرا (436% کا اضافہ)، اور درخواستوں کی پروسیسنگ میں تاخیر میں 79% تک کمی کا باعث بنی۔ مجوزہ طریقے libreactor کے لیے مخصوص نہیں ہیں اور کام کرتے وقت دوسرے HTTP سرورز، بشمول nginx، Actix، Netty اور Node.js (لائبریکٹر کو ٹیسٹوں میں استعمال کیا گیا تھا کیونکہ اس پر مبنی حل نے بہتر کارکردگی دکھائی)۔
بنیادی اصلاح:
- لیبریکٹر کوڈ کو بہتر بنانا۔ ٹیکیم پاور کٹ سے R18 آپشن کو بنیاد کے طور پر استعمال کیا گیا تھا، جسے استعمال شدہ CPU کور کی تعداد کو محدود کرنے کے لیے کوڈ کو ہٹا کر بہتر کیا گیا تھا (آپٹمائزیشن سے کام کو 25-27% تک تیز کیا گیا تھا)، "-O3" اختیارات کے ساتھ GCC میں جمع (5-10% کا اضافہ) اور "-march-native" (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" (Specter v1 + SWAPGS سے تحفظ) سے اضافہ 1-2%، "nospectre_v2" (Specter v2 سے تحفظ) - 15-20%، "pti=off" (Spectre v3/Meltdown) - 6%، "mds=off tsx_async_abort=off" (MDS/Zombieload and TSX Asynchronous Abort) - 6%۔ L1TF/Foreshadow (l1tf=flush)، iTLB ملٹی ہٹ، Speculative Store بائی پاس اور 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 میں سیٹ کی گئی تھی۔ اسی سی پی یو کور کو لبریکٹر کے عمل اور آنے والے پیکٹوں کے نیٹ ورک کی قطار کو پروسیس کرنے کے لیے، ایک حسب ضرورت BPF ہینڈلر استعمال کیا جاتا ہے، جو ساکٹ بناتے وقت SO_ATTACH_REUSEPORT_CBPF جھنڈا ترتیب دے کر منسلک ہوتا ہے۔ باہر جانے والے پیکٹوں کی قطاروں کو 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 req/s سے بڑھ کر 1.12M req/s ہو گیا۔ dhclient کی کارکردگی کو متاثر کرنے کی وجہ خام ساکٹ کا استعمال کرتے ہوئے ٹریفک تجزیہ میں ہے۔
- اسپن لاک سے لڑنا۔ نیٹ ورک اسٹیک کو sysctl "net.core.default_qdisc=noqueue" اور "tc qdisc replace dev eth0 root mq" کے ذریعے "noqueue" موڈ میں تبدیل کرنے سے کارکردگی میں 2% اضافہ ہوا، اور تھرو پٹ 1.12M req/s سے بڑھ کر 1.15M ہو گیا۔ درخواستیں
- حتمی معمولی اصلاحیں، جیسے کہ "ethtool -K eth0 gro off" کمانڈ کے ساتھ GRO (Generic Receive Offload) کو غیر فعال کرنا اور sysctl "net.ipv4.tcp_congestion_control=reno" کا استعمال کرتے ہوئے کیوبک کنجشن کنٹرول الگورتھم کو رینو سے تبدیل کرنا۔ مجموعی پیداوار میں 4 فیصد اضافہ ہوا۔ تھرو پٹ 1.15M req/s سے بڑھ کر 1.2M req/s ہو گیا۔
کام کرنے والی اصلاحوں کے علاوہ، مضمون میں ان طریقوں پر بھی بحث کی گئی ہے جو متوقع کارکردگی میں اضافہ کا باعث نہیں بنے۔ مثال کے طور پر، مندرجہ ذیل غیر موثر ثابت ہوئے:
- لیبریکٹر کو الگ سے چلانا کنٹینر میں چلانے سے کارکردگی میں مختلف نہیں تھا۔ writev کو بھیجنے سے تبدیل کرنا، epoll_wait میں maxevents کو بڑھانا، اور GCC ورژنز اور جھنڈوں کے ساتھ تجربہ کرنے کا کوئی اثر نہیں ہوا (اثر صرف "-O3" اور "-march-native" جھنڈوں کے لیے نمایاں تھا)۔
- لینکس کرنل کو ورژن 4.19 اور 5.4 میں اپ گریڈ کرنا، SCHED_FIFO اور SCHED_RR شیڈولرز کا استعمال کرتے ہوئے، sysctl kernel.sched_min_granularity_ns، kernel.sched_wakeup_granularity_ns، transparent_hugepages=never, tskew=tscew=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