การเพิ่มประสิทธิภาพเคอร์เนล Linux ขั้นสูงด้วย sysctl

อินฟอร์เมเทค ดิจิตอล » Recursos » การเพิ่มประสิทธิภาพเคอร์เนล Linux ขั้นสูงด้วย sysctl

หากคุณดูแลเซิร์ฟเวอร์ Linux มาสักระยะ คุณจะค้นพบว่าความแตกต่างระหว่างระบบธรรมดาและระบบที่ทำงานได้อย่างยอดเยี่ยมภายใต้ภาระงานหนักนั้นอยู่ที่การปรับแต่งเคอร์เนลให้ดียิ่งขึ้น ไม่ใช่แค่การติดตั้ง RAM เพิ่มหรือ CPU ที่ทรงพลังกว่าเดิมเท่านั้น ปัญหาคอขวดหลายอย่างสามารถแก้ไขได้ด้วยการปรับพารามิเตอร์ที่เลือกอย่างระมัดระวังเพียงไม่กี่อย่าง

เคอร์เนลมีตัวเลือกมากมายหลายร้อยรายการสำหรับการจัดการเครือข่าย หน่วยความจำ ระบบไฟล์ และการจัดตารางกระบวนการ ซึ่งสามารถแก้ไขได้ทันที ด้วยเครื่องมือนี้ sysctl และมีการปรับเปลี่ยนบางอย่างใน /procเป็นไปได้ที่จะใช้ประโยชน์จากฮาร์ดแวร์ให้ได้มากที่สุดและบรรลุเป้าหมาย ความหน่วงต่ำลง ประสิทธิภาพการรับส่งข้อมูลสูงขึ้น และความเสถียรที่ดีขึ้น หลักการนี้ใช้ได้กับเว็บเซิร์ฟเวอร์และฐานข้อมูล รวมถึงสภาพแวดล้อมแบบเรียลไทม์และ Kubernetes ด้วย อย่างไรก็ตาม สิ่งสำคัญคือต้องรู้ว่ากำลังทำอะไรอยู่และจะวัดผลได้อย่างไร

sysctl คืออะไร และมันจัดการพารามิเตอร์ของเคอร์เนลอย่างไร?

ยูทิลิตี้ sysctl นี่คือช่องทางในการเปลี่ยนแปลงพารามิเตอร์เคอร์เนลโดยไม่ต้องคอมไพล์ใหม่หรือรีบูตเครื่อง ทำให้สามารถ... อ่านและแก้ไขค่าต่างๆ ในระหว่างการทำงาน เพื่อทดสอบการตั้งค่าได้ทันที พารามิเตอร์เหล่านี้จัดเรียงอยู่ในโครงสร้างลำดับชั้นต่ำ /proc/sys/และแต่ละส่วนจะควบคุมพฤติกรรมเฉพาะของระบบ

การตั้งค่าต่างๆ ถูกจัดกลุ่มเป็นหมวดหมู่ที่ชัดเจน ทำให้ง่ายต่อการระบุสิ่งที่คุณต้องปรับแต่งเมื่อคุณประสบปัญหาด้านประสิทธิภาพหรือความเสถียรโดยเฉพาะ โครงสร้างนี้ช่วยให้คุณสามารถมุ่งเน้นเฉพาะส่วนต่างๆ เช่นเครือข่าย (net.*), หน่วยความจำ (vm.*) หรือระบบไฟล์ (fs.*)โดยไม่ต้องหลงไปกับตัวเลือกเคอร์เนลอื่นๆ

หมวดหมู่หลักที่คุณจะพบได้ใน /proc/sys/ ซึ่งรวมถึงสิ่งต่อไปนี้:

• เคอร์เนล*ตัวเลือกทั่วไปของเคอร์เนล (ตัวกำหนดตารางเวลา, PID, ข้อความ, NUMA เป็นต้น)
• วีเอ็ม.*: การจัดการหน่วยความจำเสมือน, สวอป, แคช และนโยบายโอเวอร์คอมมิต
• สุทธิ.*: โครงสร้างเครือข่าย IPv4/IPv6, บัฟเฟอร์ TCP/UDP, คิว, การควบคุมความแออัด
• เอฟ.*: ข้อจำกัดของตัวอธิบาย, inode, inotify, พฤติกรรม AIO และ VFS
• นักพัฒนา*: พารามิเตอร์เฉพาะของอุปกรณ์และไดรเวอร์บางชนิด

กับ sysctl -a คุณสามารถแสดงรายการพารามิเตอร์ที่มีอยู่ทั้งหมดได้ และใช้คำสั่งต่างๆ เช่น sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse การอ่านค่าเฉพาะ ซึ่งเป็นกุญแจสำคัญ ตรวจสอบการกำหนดค่าปัจจุบัน ก่อนที่จะเปลี่ยนแปลงอะไรก็ตาม ในการค้นหาสิ่งที่เฉพาะเจาะจง มักจะใช้การกรองด้วย grepตัวอย่างเช่น: sysctl -a | grep tcp.

การปรับเปลี่ยนพารามิเตอร์แบบเรียลไทม์นั้นง่ายมาก เพียงแค่ใช้... sysctl -w clave=valorอย่างไรก็ตาม สิ่งสำคัญคือต้องเข้าใจว่าการเปลี่ยนแปลงเหล่านี้เป็นเพียงชั่วคราว เพื่อบันทึกการเปลี่ยนแปลงหลังจากรีบูต จำเป็นต้องสำรองข้อมูลการตั้งค่าไว้ก่อน /etc/sysctl.conf หรือในไฟล์ของ /etc/sysctl.d/โดยปกติจะใช้ไฟล์ที่มีหมายเลขกำกับ (ตัวอย่างเช่น) 10-network.conf, 20-memory.conf, 99-custom.conf) ซึ่งเป็นตัวกำหนดลำดับในการนำไปใช้

วัดก่อนลงมือทำ: เกณฑ์มาตรฐานและค่าพื้นฐานของระบบ

ก่อนที่คุณจะเริ่มปรับแต่งค่าต่างๆ ควรสร้างเกณฑ์มาตรฐานด้านประสิทธิภาพที่เป็นกลาง เสีย ก่อน หากไม่มีข้อมูลก่อนหน้า คุณจะไม่มีทางรู้ได้เลยว่าการเปลี่ยนแปลงนั้นทำให้ระบบดีขึ้นหรือแย่ลง และคุณจะตกอยู่ในกับดักคลาสสิกที่ว่า "มันดูดีขึ้นสำหรับฉัน" ซึ่งไม่มีประโยชน์สำหรับการตัดสินใจที่ถูกต้อง

ในระดับระบบโดยรวม ควรเก็บรวบรวมสถิติการใช้งาน CPU, โหลด, หน่วยความจำ, ดิสก์ และเครือข่าย เป็นเวลาสองสามนาทีภายใต้โหลดที่เหมาะสม เครื่องมือต่างๆ เช่น uptime, mpstat, vmstat, iostat -x o sar -n DEV เครื่องมือเหล่านี้ช่วยให้คุณเห็นว่าเคอร์เนลมาตรฐานทำงานอย่างไร ใช้พื้นที่สวอปไปเท่าไหร่ การตอบสนองของดิสก์ I/O เป็นอย่างไร และเครือข่ายมีการใช้งานเต็มประสิทธิภาพหรือสิ้นเปลืองแบนด์วิดท์หรือไม่

นอกเหนือจากภาพรวมดังกล่าวแล้ว สิ่งสำคัญคือต้องทำการทดสอบประสิทธิภาพเฉพาะสำหรับแอปพลิเคชันที่คุณต้องการปรับปรุงประสิทธิภาพ บนเว็บเซิร์ฟเวอร์ คุณสามารถใช้ ab (Apache Bench) หรือเครื่องมือที่คล้ายกันสำหรับการวัด จำนวนคำขอต่อวินาที, เวลาแฝงเฉลี่ย และข้อผิดพลาดในฐานข้อมูล เครื่องมืออำนวยความสะดวกต่างๆ เช่น mysqlslap o sysbench เครื่องมือเหล่านี้ช่วยประเมินจำนวนธุรกรรมต่อวินาทีและเวลาในการค้นหาข้อมูล

ตัวอย่างเช่น ในสถานการณ์ที่ไม่ได้ปรับแต่งใดๆ มักจะพบตัวเลขเช่น การร้องขอ HTTP 500 ครั้งต่อวินาที โดยมีเวลาตอบสนองเฉลี่ย 200 มิลลิวินาที การสืบค้น SQL ประมาณ 250 ครั้งต่อวินาที โดยมีเวลาแฝง 40 มิลลิวินาที ความเร็วเครือข่ายประมาณ 500 เมกะบิตต่อวินาที และภาระของระบบใกล้ถึงขีดจำกัดภายใต้สภาวะกดดัน ตัวเลขเหล่านี้จะถูกนำมาใช้เพื่อตรวจสอบว่า หลังจากทำการเปลี่ยนแปลงเคอร์เนลแล้ว จะสามารถเพิ่มประสิทธิภาพการทำงานและลดเวลาแฝงได้อย่างเห็นได้ชัด หรือไม่

สุดท้ายนี้ ให้บันทึกคำสั่งและผลลัพธ์ก่อนทำการเปลี่ยนแปลงใดๆ การมีประวัติจะช่วยให้คุณเปรียบเทียบการปรับแต่งต่างๆ ได้อย่างแม่นยำ และยังช่วยให้คุณตรวจจับข้อผิดพลาดที่เกิดขึ้นหลังจากการอัปเดตเคอร์เนลหรือหลังจากนำโปรไฟล์ sysctl ใหม่มาใช้ในสภาพแวดล้อมการใช้งาน จริงได้อีกด้วย

การตั้งค่าหน่วยความจำขั้นสูง: vm.*

หน่วยความจำคือหนึ่งในระบบย่อยที่การเปลี่ยนแปลงในเคอร์เนลเห็นผลชัดเจนที่สุด เซิร์ฟเวอร์ที่มี RAM มาก แต่ตั้งค่าไม่ดี อาจใช้พื้นที่สวอปโดยไม่จำเป็น ส่งผลให้... การรับส่งข้อมูล I/O พุ่งสูงขึ้นและประสิทธิภาพลดลงอย่างมากนั่นคือเหตุผลที่ต้องใช้พารามิเตอร์ต่างๆ เช่น vm.swappinessอัตราส่วนหน้าข้อมูลที่ไม่สะอาดหรือพฤติกรรมแคช VFS ก็มีความสำคัญไม่แพ้กัน

พารามิเตอร์ vm.swappiness ค่านี้ควบคุมจำนวนหน้าหน่วยความจำที่เคอร์เนลส่งไปยังสวอป ในระบบปฏิบัติการหลายๆ รุ่น ค่านี้ถูกตั้งไว้ที่ 60 ซึ่งเป็นค่าที่เหมาะสำหรับสภาพแวดล้อมเดสก์ท็อปแบบผสม สำหรับเซิร์ฟเวอร์ฐานข้อมูลหรือแอปพลิเคชันที่มีความหน่วงต่ำ โดยทั่วไปแล้วควรลดค่านี้ลงเหลือ 10 หรือน้อยกว่านั้น ซึ่งจะทำให้ระบบมีประสิทธิภาพมากขึ้น ให้ความสำคัญกับการเก็บข้อมูลไว้ใน RAM และลดการใช้หน่วยความจำเสมือน (Swapping)ไม่ใช่เรื่องแปลกที่จะเห็นปริมาณการรับส่งข้อมูลบนดิสก์ลดลงอย่างมาก และแอปพลิเคชันตอบสนองได้ราบรื่นขึ้นหลังจากปรับแต่งแล้ว

องค์ประกอบพื้นฐานอีกอย่างหนึ่งคือ vm.dirty_ratio y vm.dirty_background_ratioค่าเหล่านี้กำหนดว่าหน่วยความจำกี่เปอร์เซ็นต์ที่สามารถรองรับการเขียนหน้าข้อมูลที่เปลี่ยนแปลงได้ก่อนที่เคอร์เนลจะเริ่มเขียนลงดิสก์ ค่าที่สูงเกินไปอาจทำให้เกิดการเขียนข้อมูลจำนวนมากในคราวเดียว ส่งผลให้แอปพลิเคชันทั้งหมดมีเวลาหน่วงมากเมื่อการเขียนลงดิสก์เกิดขึ้น การลดเปอร์เซ็นต์เหล่านี้ลงเหลือตัวเลขเช่น 15 และ 5 ตามลำดับ มักจะส่งผลให้... รูปแบบอินพุต/เอาต์พุตที่สม่ำเสมอและคาดการณ์ได้มากขึ้น.

การตั้งค่าของ vm.vfs_cache_pressure ค่านี้กำหนดว่าเคอร์เนลจะล้างแคช inode และไดเร็กทอรีอย่างรุนแรงแค่ไหน ค่าเริ่มต้นที่ 100 มักจะล้างแคชอย่างรวดเร็ว ในขณะที่การตั้งค่าประมาณ 50 จะช่วยให้เก็บข้อมูลเมตาไว้ได้นานขึ้น เพิ่มอัตราการเข้าถึงไฟล์ และปรับปรุงประสิทธิภาพ ประสิทธิภาพที่รับรู้ได้ของระบบไฟล์ซึ่งเป็นสิ่งสำคัญอย่างยิ่งในเซิร์ฟเวอร์ที่จัดการไฟล์ขนาดเล็กจำนวนหลายล้านไฟล์

สำหรับส่วนของตน vm.min_free_kbytes สำรองหน่วยความจำว่างขั้นต่ำไว้เพื่อให้แน่ใจว่าระบบสามารถตอบสนองต่อการจัดสรรหน่วยความจำที่เพิ่มขึ้นอย่างรวดเร็วได้โดยไม่เกิดสถานการณ์ผิดปกติที่ไม่คาดคิด การกำหนดขนาดหน่วยความจำว่างนี้ไว้ที่ประมาณ 0,5% ถึง 1% ของ RAM ทั้งหมดมักเป็นมาตรการความปลอดภัยที่มีประสิทธิภาพในการป้องกันไม่ให้เคอร์เนลหมดพื้นที่ภายใต้ภาระงานที่หนักมากและเริ่มปิดกระบวนการที่สำคัญ ซึ่งจะช่วยปรับปรุงประสิทธิภาพได้ ความเสถียรโดยรวมของโฮสต์.

สุดท้ายนี้ นโยบายการจัดสรรทรัพยากรเกินความจำเป็น (overcommit policy) สมควรได้รับความสนใจเป็นพิเศษ ได้แก่ พารามิเตอร์ต่างๆ เช่น vm.overcommit_memory y vm.overcommit_ratio พวกมันกำหนดว่าหน่วยความจำเสมือนจะถูกจัดสรรให้กับกระบวนการต่างๆ มากน้อยเพียงใดเมื่อเทียบกับ RAM และหน่วยความจำสวอปที่มีอยู่ ในบางกรณี (เช่น Redis หรือฐานข้อมูลบางประเภท) อนุญาตให้มีการจัดสรรเกินความจำเป็นอย่างมาก ในขณะที่ในกรณีอื่นๆ จะเลือกใช้นโยบายที่อนุรักษ์นิยมมากกว่าเพื่อจำกัดความเสี่ยง OOM และสถานการณ์ที่หน่วยความจำถูกบุกรุกมากเกินไปสำหรับเทคนิคการวิเคราะห์และวินิจฉัยกรณีที่ซับซ้อน โปรดปรึกษา การดีบักหน่วยความจำในลินุกซ์.

การเพิ่มประสิทธิภาพเครือข่ายขั้นสูง: net.* และ TCP/IP

ส่วนของเครือข่าย (Network stack) อาจเป็นส่วนที่การปรับแต่งเห็นผลชัดเจนที่สุดในสภาพแวดล้อมการใช้งานจริง การเปลี่ยนแปลงเล็กน้อยในคิวการเชื่อมต่อหรือบัฟเฟอร์ก็สามารถสร้างความแตกต่างระหว่างเซิร์ฟเวอร์ที่ทำงานติดขัดที่ความเร็ว 500 Mbps กับเซิร์ฟเวอร์ที่ทำงานได้อย่างราบรื่น มันสามารถใช้แบนด์วิดท์ระดับกิกะบิตได้เต็มประสิทธิภาพอย่างง่ายดายพารามิเตอร์ภายใต้ net.core.* y net.ipv4.* ในด้านนี้ พวกเขาคือพันธมิตรที่ดีที่สุดของคุณ

ก่อนอื่น ขนาดบัฟเฟอร์ของซ็อกเก็ตมีผลโดยตรงต่อปริมาณข้อมูลสูงสุดที่ส่งผ่านได้ของการเชื่อมต่อ โดยเฉพาะอย่างยิ่งเมื่อมีความหน่วงสูงหรือลิงก์ที่มีความจุสูง ปรับแต่ง net.core.rmem_max y net.core.wmem_max กำหนดค่าให้เหมาะสมโดยระบุค่าที่มากพอสมควร (หลักสิบหรือหลักร้อยเมกะไบต์) และกำหนดค่าให้ถูกต้อง net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (ค่าต่ำสุด ค่าเริ่มต้น และค่าสูงสุด) อนุญาตให้แต่ละซ็อกเก็ตมี พื้นที่ที่จำเป็นเพื่อรองรับปริมาณการจราจรที่เพิ่มขึ้นอย่างฉับพลัน โดยไม่ตกอยู่ภายใต้ข้อจำกัดเทียมที่ถูกกำหนดขึ้นจากค่านิยมโรงงานที่อนุรักษ์นิยมมากเกินไป

อีกประเด็นสำคัญคือขนาดของคิวการเชื่อมต่อ พารามิเตอร์ต่างๆ เช่น net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog ข้อจำกัดเหล่านี้กำหนดจำนวนการเชื่อมต่อที่รออยู่ซึ่งระบบสามารถจัดการได้ก่อนที่จะทิ้งแพ็กเก็ตหรือปฏิเสธการเชื่อมต่อ ในเว็บเซิร์ฟเวอร์ที่มีปริมาณการใช้งานสูง การเพิ่มข้อจำกัดเหล่านี้สามารถป้องกันคิวที่เต็มและลดภาระได้อย่างมาก ข้อผิดพลาดในการเชื่อมต่อระหว่างช่วงที่มีโหลดสูงสุด.

นอกจากนี้ ยังสามารถปรับแต่งพฤติกรรมของการเชื่อมต่อ TCP ได้อย่างละเอียดด้วยตัวเลือกมากมาย เช่น การเปิดใช้งาน net.ipv4.tcp_window_scaling เพื่อรองรับหน้าต่างขนาดใหญ่บนลิงก์ที่มีแบนด์วิดท์สูง ให้เปิดใช้งาน net.ipv4.tcp_sack y net.ipv4.tcp_timestamps เพื่อปรับปรุงการจัดการการสูญเสียและการส่งซ้ำ หรือปรับเปลี่ยน net.ipv4.tcp_fin_timeout และการบริหารจัดการของ TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) เพื่อควบคุมการใช้ทรัพยากรบนเซิร์ฟเวอร์ด้วย มีการเชื่อมต่อระยะสั้นนับล้านครั้งต่อนาที.

การเลือกอัลกอริทึมควบคุมการจราจรติดขัดก็มีความสำคัญเช่นกัน แม้ว่า cubic ยังคงเป็นค่าเริ่มต้นในระบบปฏิบัติการหลายระบบ การเปลี่ยนไปใช้ bbr ในเคอร์เนลเวอร์ชันใหม่ (4.9 และใหม่กว่า) โดย net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq เทคโนโลยีนี้สามารถเพิ่มปริมาณการรับส่งข้อมูล TCP ในสภาพแวดล้อมที่มีการสูญเสียหรือความหน่วงที่ซับซ้อนได้หลายเท่า โดยสามารถปรับปรุงประสิทธิภาพได้ระหว่าง 2 ถึง 25 เท่าเมื่อเทียบกับการกำหนดค่าแบบดั้งเดิมในบางสถานการณ์ แต่ก็แลกมาด้วยต้นทุนที่สูงขึ้น พฤติกรรมที่แตกต่างออกไปบ้างในเครือข่ายที่มีความหนาแน่นสูง.

เราต้องไม่ลืมพารามิเตอร์ด้านความปลอดภัยและความน่าเชื่อถือ เช่น net.ipv4.tcp_syncookiesการจัดการการเปลี่ยนเส้นทาง (net.ipv4.conf.all.accept_redirects, send_redirects) หรือการกรองในบริดจ์ (net.bridge.bridge-nf-call-iptables ในสภาพแวดล้อม Kubernetes) หากตั้งค่าอย่างถูกต้อง จะช่วยปกป้องระบบจากการโจมตีทั่วไป (SYN flood, spoofing เป็นต้น) โดยไม่ลดทอนประสิทธิภาพ ประสิทธิภาพเครือข่ายที่แข็งแกร่งสำหรับคำแนะนำเชิงปฏิบัติเกี่ยวกับกฎและวิธีการตรวจจับ โปรดดูที่... การใช้งาน Netfilter และ Suricata.

ระบบไฟล์ ตัวอธิบาย และข้อจำกัดทั่วโลก: fs.* และ ulimit

ในเซิร์ฟเวอร์สมัยใหม่ การตั้งค่าขีดจำกัดตัวจัดการไฟล์ (File Descriptor) ที่ต่ำเกินไป คือวิธีที่เร็วที่สุดที่จะทำให้ระบบล่มในช่วงเวลาที่มีการใช้งานสูงสุด เมื่อเว็บเซิร์ฟเวอร์ รีเวิร์สพร็อกซี หรือฐานข้อมูลพบข้อผิดพลาด "มีไฟล์เปิดมากเกินไป" มักเป็นเพราะพารามิเตอร์เคอร์เนลและขีดจำกัดของผู้ใช้ไม่ได้ถูกปรับให้เหมาะสมกับปริมาณงานจริง

ทั่วโลก fs.file-max ค่านี้ระบุจำนวนตัวอธิบายทั้งหมดที่เคอร์เนลสามารถเปิดได้ สำหรับแอปพลิเคชันที่มีการเชื่อมต่อพร้อมกันหลายพันรายการ มักจะเพิ่มค่านี้เป็นหลายล้าน พร้อมกับการเพิ่มค่าอื่นๆ ด้วย fs.nr_openซึ่งเป็นการกำหนดขีดจำกัดสูงสุดสำหรับคำอธิบายต่อกระบวนการ นอกจากนี้ยังจำเป็นต้องมีการปรับเปลี่ยนเพิ่มเติม /etc/security/limits.conf เพื่อให้ผู้ใช้ (หรือบริการที่จัดการโดย systemd) มี ค่าอ่อนและค่าแข็งที่สอดคล้องกับการกำหนดค่าเคอร์เนล.

ระบบย่อย inotify ซึ่งใช้กันอย่างแพร่หลายใน IDE เครื่องมือพัฒนาเว็บ และระบบตรวจสอบไฟล์ ถูกควบคุมด้วยพารามิเตอร์ต่างๆ เช่น fs.inotify.max_user_watches y fs.inotify.max_user_instancesหากคุณพบข้อผิดพลาดที่เกี่ยวข้องกับตัวตรวจสอบหรือกระบวนการที่หยุดการตรวจสอบการเปลี่ยนแปลงของดิสก์ คุณอาจต้องแก้ไขด้วยวิธีการอื่น เพิ่มขีดจำกัดเหล่านี้เพื่อหลีกเลี่ยงปัญหาคอขวดที่เกิดขึ้นโดยไม่รู้ตัว.

คุณสมบัติสำคัญอีกประการหนึ่งคือ การรับส่งข้อมูลแบบอะซิงโครนัส (AIO) ซึ่งค่าสูงสุดทั่วโลกถูกกำหนดไว้ด้วย fs.aio-max-nrในแอปพลิเคชันที่พึ่งพาการรับส่งข้อมูลแบบอะซิงโครนัสเป็นอย่างมาก (เช่น เอ็นจิ้นฐานข้อมูลบางประเภท ระบบคิว ฯลฯ) การเพิ่มค่านี้จะช่วยป้องกันไม่ให้เคอร์เนลหมดช่องว่างสำหรับการดำเนินการ AIO ภายใต้ภาระการร้องขอจำนวนมหาศาล

นอกเหนือจากพารามิเตอร์เหล่านี้แล้ว ประสิทธิภาพของระบบย่อยดิสก์ยังได้รับผลกระทบจากปัจจัยอื่นๆ อีกด้วย ตัวกำหนดตารางเวลา I/O กำหนดค่าบนอุปกรณ์บล็อกแต่ละตัว ในระบบที่มี SSD หรือ NVMe มักแนะนำให้ใช้ตัวจัดตารางเวลาแบบเบา เช่น none o mq-deadlineในขณะที่สำหรับดิสก์แบบกลไก ตัวเลือกอื่นๆ อาจเหมาะสมกว่า เช่น bfq ขึ้นอยู่กับประเภทของโหลด ปรับตัวกำหนดเวลาผ่านทาง /sys/block/<disco>/queue/scheduler และปรับแต่งตัวเลือกต่างๆ เช่น ความลึกของคิว (nr_requests) หรือ read_ahead_kb สามารถสร้างความแตกต่างที่เห็นได้ชัดใน ความหน่วงในการอ่าน/เขียน และปริมาณงานสิ่งสำคัญอีกประการหนึ่งคือการพิจารณาว่าใช้ระบบไฟล์และไดรเวอร์ใด ตัวอย่างเช่น บทความเกี่ยวกับ NTFSplus บน Linux และระบบอื่นๆ สามารถช่วยได้เมื่อออกแบบโหลดที่ไม่เป็นเนื้อเดียวกัน

สุดท้ายนี้ เราต้องไม่ลืมว่าข้อจำกัดของเคอร์เนลเหล่านี้จะต้องควบคู่ไปกับการกำหนดค่าระบบ เช่น ข้อจำกัดของ ulimit และหน่วย systemd เพื่อให้แน่ใจว่าบริการต่างๆ สามารถใช้ทรัพยากรเพิ่มเติมที่กำหนดไว้ได้จริงและจะไม่ถูกบล็อกโดย ข้อจำกัดในชั้นบน.

เคอร์เนลทั่วไป, NUMA, ความสัมพันธ์ของ CPU และเพจขนาดใหญ่

นอกเหนือจากระบบเครือข่าย หน่วยความจำ และระบบไฟล์แล้ว เคอร์เนลเองยังมีตัวเลือกการปรับแต่งมากมายที่ส่งผลต่อวิธีการจัดตารางการทำงานของกระบวนการ วิธีการกระจายภาระงานไปยังคอร์และโหนด NUMA และวิธีการจัดการหน่วยความจำในระดับขนาดใหญ่ บนเครื่องสมัยใหม่ที่มีหลายคอร์และแม้กระทั่งหลายซ็อกเก็ต รายละเอียดเหล่านี้มักสร้างความแตกต่างระหว่างเซิร์ฟเวอร์ที่มีความสมดุลและเซิร์ฟเวอร์ที่มีบางคอร์ใช้งานเต็มที่ในขณะที่คอร์อื่น ๆ ถูกใช้งานน้อยเกินไป นอกจากนี้ยังควรพิจารณาเคอร์เนลทางเลือกอื่น ๆ เช่นเคอร์เนล Liquorixในสภาพแวดล้อมที่ต้องการโปรไฟล์ความหน่วงที่แตกต่างกัน

พารามิเตอร์ เช่น kernel.pid_max พวกเขากำหนดช่วงสูงสุดของรหัสกระบวนการที่ระบบสามารถกำหนดได้ ซึ่งมีความสำคัญสำหรับโหนดที่รันคอนเทนเนอร์จำนวนมากหรือกระบวนการชั่วคราว การปรับตัวเลือกการบันทึกเคอร์เนล (kernel.printk) ช่วยลดสัญญาณรบกวนที่มากเกินไปใน dmesg ในขณะที่ยังคงบันทึกเหตุการณ์สำคัญ ซึ่งส่งผลต่อโดยอ้อมด้วย ความสามารถในการวินิจฉัยและความเสถียร.

ในส่วนของโทโพโลยีหน่วยความจำ พารามิเตอร์ kernel.numa_balancing ฟังก์ชันนี้ควบคุมขอบเขตที่เคอร์เนลจะย้ายเพจระหว่างโหนด NUMA โดยอัตโนมัติ การปิดใช้งานในบางสภาพแวดล้อมจะช่วยให้สามารถจัดการความสัมพันธ์ของกระบวนการและหน่วยความจำได้อย่างชัดเจนยิ่งขึ้น โดยใช้เครื่องมือต่างๆ เช่น numactl เพื่อให้มั่นใจว่ากระบวนการที่ใช้ CPU และ RAM มากจะยังคงอยู่บนโหนดเดียวกัน ซึ่งจะช่วยลดภาระงานลง ความล่าช้าที่เกิดจากการเข้าถึงระยะไกลเพื่อให้เข้าใจปฏิสัมพันธ์ระหว่างฮาร์ดแวร์และการจัดตารางการทำงานของคอร์ได้ดียิ่งขึ้น การทบทวนเทคโนโลยีต่างๆ เช่น ก็เป็นประโยชน์เช่นกัน ผู้อำนวยการเธรดของ Intel.

หน้ากระดาษขนาดใหญ่ (vm.nr_hugepagesนี่เป็นอีกหนึ่งองค์ประกอบสำคัญในระบบฐานข้อมูลหรือเวิร์กโหลดอื่นๆ ที่จัดการพื้นที่หน่วยความจำต่อเนื่องขนาดใหญ่ การสำรองเพจขนาดใหญ่จำนวนที่เหมาะสม (2 MB หรือแม้แต่ 1 GB ขึ้นอยู่กับสถาปัตยกรรม) สามารถลดภาระ TLB และปรับปรุงประสิทธิภาพของแอปพลิเคชันที่ทำงานได้อย่างมีนัยสำคัญ การดำเนินการหลายอย่างบนบล็อกหน่วยความจำขนาดใหญ่เพื่อให้ได้ผลลัพธ์ที่มีประสิทธิภาพ การกำหนดค่าเคอร์เนลจะต้องประสานงานกับแอปพลิเคชันเอง เพื่อให้แอปพลิเคชันใช้หน่วยความจำนั้นอย่างชัดเจน

ในด้านความหน่วงและการจัดตารางเวลา มีพารามิเตอร์ของตัวจัดตารางเวลา เช่น kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsการตั้งค่าเหล่านี้จะปรับแต่งขนาดของ "ส่วน" CPU ที่จัดสรรให้กับแต่ละงาน และความรุนแรงในการที่เคอร์เนลย้ายกระบวนการระหว่างคอร์ ค่าที่น้อยกว่าแสดงถึงระบบที่สามารถถูกขัดจังหวะได้ง่ายกว่า ซึ่งมักจะให้ผลลัพธ์ที่ดีกว่า คำตอบที่ดีที่สุดสำหรับงานแบบโต้ตอบ โดยบางครั้งอาจต้องแลกมาด้วยปริมาณงานดิบที่ลดลงเล็กน้อย

ในระบบที่หน่วยความจำถือเป็นทรัพยากรที่สำคัญ ผู้ดูแลระบบบางรายเลือกที่จะเปิดใช้งานโหมดฉุกเฉินในกรณีที่เกิดข้อผิดพลาดตั้งแต่เริ่มต้นใช้งาน (vm.panic_on_oom) และก่อตั้ง kernel.panic โดยมีเวลารีสตาร์ทอัตโนมัติ กลยุทธ์นี้แม้จะดูรุนแรงไปบ้าง แต่ก็มีประโยชน์ในสภาพแวดล้อมที่มีความพร้อมใช้งานสูง การรีบูตอย่างรวดเร็วและควบคุมได้นั้นดีกว่าการปล่อยให้เครื่องค้างและไม่เสถียร ระหว่างชั่วโมง.

โปรไฟล์เฉพาะทาง: เว็บ, ฐานข้อมูล, ความหน่วงต่ำ และ Kubernetes

แทนที่จะใช้วิธีแก้ปัญหาแบบเบ็ดเสร็จเพียงวิธีเดียว การสร้างโปรไฟล์ sysctl ที่ปรับแต่งให้เหมาะสมกับประเภทของเวิร์กโหลดต่างๆ เช่น เว็บเซิร์ฟเวอร์ ฐานข้อมูล แพลตฟอร์มคอนเทนเนอร์ หรือระบบที่มีความหน่วงต่ำ จะมีประสิทธิภาพมากกว่า การกระจายการตั้งค่าเหล่านี้ในไฟล์ต่างๆ เช่น 99-webserver.conf, 99-database.conf o 90-kubernetes.conf ช่วยด้วย รักษาการกำหนดค่าให้เป็นระเบียบและง่ายต่อการจัดการเวอร์ชันคุณยังสามารถพิจารณาการแจกจ่ายและรุ่นที่เน้นประสิทธิภาพได้เช่นกัน เช่น CachyOS Server Edition สำหรับสภาพแวดล้อมที่เฉพาะเจาะจงมาก ๆ

สำหรับเว็บเซิร์ฟเวอร์ (Nginx, Apache, พร็อกซี ฯลฯ) สิ่งสำคัญคือต้องสามารถจัดการกับการเชื่อมต่อพร้อมกันจำนวนมากที่มีคิวขนาดใหญ่และเวลาตอบสนองที่รวดเร็ว FIN_WAIT ด้วยการปรับแต่งอย่างละเอียด การขยายช่วงพอร์ตชั่วคราว และการกำหนดขีดจำกัดตัวอธิบายที่สูงมาก ทำให้สามารถเพิ่มจำนวนคำขอ HTTP ต่อวินาทีจากไม่กี่ร้อยคำขอเป็นหลายพันคำขอได้ ซึ่งจะช่วยลดเวลาแฝงเฉลี่ยและขจัดข้อผิดพลาด คิวเต็มหรือพอร์ตเต็ม.

ในส่วนของฐานข้อมูล (MySQL, PostgreSQL และฐานข้อมูลที่คล้ายกัน) จะให้ความสำคัญกับการใช้งาน swap ให้น้อยที่สุด การปรับแต่งการเขียนหน้าข้อมูลที่เปลี่ยนแปลง และการตั้งค่าหน่วยความจำที่ใช้ร่วมกันและเซมาฟอร์ที่เหมาะสมสำหรับเอนจิน พารามิเตอร์ต่างๆ เช่น kernel.shmmax, kernel.shmall, kernel.sem และการกำหนดค่าหน้าเว็บขนาดใหญ่ก็สร้างความแตกต่างในแง่ของ จำนวนธุรกรรมต่อวินาทีและเวลาตอบสนองซึ่งจะช่วยเพิ่มประสิทธิภาพขึ้นสองหรือสามเท่าเมื่อเทียบกับค่าเริ่มต้นในหลายสถานการณ์

สำหรับแอปพลิเคชันที่ต้องการความหน่วงต่ำมาก (เช่น การซื้อขาย เกมออนไลน์ การประมวลผลแบบเรียลไทม์) จะมีการเพิ่มการตั้งค่าเฉพาะเจาะจงมากขึ้น: net.ipv4.tcp_low_latencyการปิดใช้งานฟังก์ชันเริ่มต้นช้าหลังจากไม่มีการใช้งาน การใช้งาน tcp_fastopenพารามิเตอร์การสำรวจที่ไม่ว่าง (net.core.busy_poll, busy_read) และในหลายกรณี การปิดใช้งานหน้าเว็บขนาดใหญ่แบบโปร่งใสโดย /sys/kernel/mm/transparent_hugepage/enabledทั้งหมดนี้มีเป้าหมายเพื่อลด คิวการประมวลผลและเวลาแฝงสูงสุดอยู่ที่เปอร์เซ็นไทล์สูงส่งผลให้มีการปรับปรุง P99 อย่างน่าทึ่ง

ในสภาพแวดล้อมคอนเทนเนอร์และ Kubernetes นั้น สแต็กเครือข่ายและการติดตามการเชื่อมต่อจะอยู่ภายใต้ความกดดันเป็นพิเศษ พารามิเตอร์ต่างๆ เช่น net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxการใช้พอร์ตที่สงวนไว้สำหรับ NodePort หรือการปรับตาราง ARP เป็นเรื่องปกติในโหนดที่จัดการพอดหลายร้อยหรือหลายพันพอด การปรับแต่งอย่างถูกต้องจะช่วยป้องกันปัญหาได้ การเชื่อมต่อถูกตัดขาด, หมดเวลา หรือตารางเต็มเมื่อใช้ conntrack.

นอกเหนือจากโปรไฟล์เฉพาะเหล่านี้แล้ว บางองค์กรเลือกใช้ระบบจัดเก็บข้อมูลที่เน้นประสิทธิภาพพร้อมความปลอดภัยที่เพิ่มขึ้น โดยผสมผสานบัฟเฟอร์เครือข่ายขนาดใหญ่และการลดการสลับข้อมูลเข้ากับมาตรการต่างๆ เช่น tcp_syncookies หรือการปิดกั้นการเปลี่ยนเส้นทางที่เป็นอันตราย เป้าหมายคือการบรรลุผลสำเร็จ จุดสมดุลระหว่างสมรรถนะที่ดุดดันและการเสริมความแข็งแกร่งที่เหมาะสม.

เครื่องมือวิเคราะห์และตรวจสอบประสิทธิภาพเคอร์เนล

การปรับแต่งเคอร์เนลโดยไม่วัดผลก็เหมือนกับการเล่นมิกเซอร์เสียงโดยปิดตา Linux มีเครื่องมือมากมายที่จะช่วยให้เข้าใจว่าระบบกำลังทำอะไรอยู่ ตั้งแต่ตัวนับอย่างง่ายไปจนถึงการติดตามการทำงานของเคอร์เนลอย่างละเอียด ทำให้คุณสามารถเชื่อมโยงการเปลี่ยนแปลงการกำหนดค่ากับผลลัพธ์ที่วัดได้

ในบรรดาสิ่งของจำเป็นในชีวิตประจำวัน ได้แก่ vmstat, iostat, sar, ss, slabtop, htop o pidstatซึ่งให้ข้อมูลอย่างรวดเร็วเกี่ยวกับกระบวนการทำงาน CPU การรับส่งข้อมูล ซ็อกเก็ต และการใช้งานแคช เมื่อรวมกับบันทึกระบบและเมตริกที่ส่งออกไปยัง Prometheus, Grafana หรือ collectd และทรัพยากรต่างๆ เช่น โปรแกรมตรวจสอบระบบขั้นสูงสำหรับ Linuxข้อมูลเหล่านี้ให้ภาพรวมที่ค่อนข้างสมบูรณ์เกี่ยวกับพฤติกรรมของโฮสต์ก่อนและหลังการปรับแต่งแต่ละครั้ง

เพื่ออธิบายรายละเอียดเพิ่มเติม เครื่องมือต่างๆ เช่น perf เครื่องมือเหล่านี้ช่วยให้สามารถวิเคราะห์การใช้งาน CPU ในระดับฟังก์ชัน ทั้งระดับผู้ใช้และระดับเคอร์เนล โดยจะบันทึกเหตุการณ์เป็นเวลาไม่กี่วินาทีหรือนาที แล้วจึงแสดงรายงานแบบโต้ตอบได้ perf stat, perf record y perf report คุณสามารถดู เวลาการทำงานของ CPU ถูกใช้ไปที่ใด และส่วนใดเป็นส่วนของคอร์เช่น การระบุถึงเหตุการณ์ขัดจังหวะที่เกิดขึ้นบ่อยครั้ง หรือการปรับตารางเวลาที่ไม่เหมาะสม

หากคุณต้องการรายละเอียดที่มากกว่านี้ ftrace ระบบติดตามการทำงานของเคอร์เนลช่วยให้สามารถเปิดใช้งานตัวติดตามเฉพาะ (เช่น ตัวติดตามฟังก์ชัน) และตรวจสอบการเรียกใช้ฟังก์ชันต่างๆ ได้แบบเรียลไทม์หรือภายหลัง การเปิดใช้งานตัวติดตามที่เหมาะสมและการวิเคราะห์เนื้อหาของตัวติดตามนั้น /sys/kernel/debug/tracing/trace มันเปิดเผยให้คุณทราบ จุดร้อนภายในเคอร์เนลเองวิธีนี้มีประโยชน์มากเมื่อตัวชี้วัดระดับสูงไม่เพียงพอ

ในขณะเดียวกัน ควรติดตั้งสคริปต์ตรวจสอบอัตโนมัติที่บันทึกข้อมูลสำคัญ (สถิติเครือข่าย ตัวนับหน่วยความจำ จำนวนตัวจัดการไฟล์ที่เปิดอยู่ ฯลฯ) ลงในไฟล์บันทึกหมุนเวียนเป็นระยะ เมื่อถึงเกณฑ์ที่กำหนด (เช่น จำนวนตัวจัดการไฟล์ที่เปิดอยู่เกินจำนวนที่ระบุ) สคริปต์เหล่านี้จะสร้างการแจ้งเตือนผ่านอีเมลหรือช่องทางอื่น ๆ เพื่อช่วยตรวจจับแนวโน้มที่เป็นอันตรายก่อนที่ปัญหาจะลุกลามใหญ่โต

สุดท้ายนี้ ในขั้นตอนการทดสอบความเครียดที่ยาวนาน (24 ชั่วโมงขึ้นไป) เครื่องมือต่างๆ เช่น stress-ng รวมกับการรวบรวมตัวชี้วัดอย่างต่อเนื่อง (ผ่าน vmstat, iostat, sar) ช่วยให้คุณประเมินเสถียรภาพของระบบด้วยการกำหนดค่าเคอร์เนลใหม่ ตรวจสอบว่าไม่มีเหตุการณ์ OOM (Out of Memory), การขัดข้อง, การรีสตาร์ทที่ไม่คาดคิด หรือประสิทธิภาพที่ลดลงอย่างต่อเนื่องภายใต้ภาระงานที่ยาวนาน

การเพิ่มประสิทธิภาพเคอร์เนล Linux ด้วย sysctl และกลไกอื่นๆ ไม่ใช่ภารกิจที่ทำครั้งเดียวจบ แต่เป็นกระบวนการที่ต้องทำซ้ำๆ โดยต้องวัดผลลัพธ์ ปรับพารามิเตอร์ และบันทึกทุกอย่างอย่างละเอียดถี่ถ้วน ด้วยวิธีการที่ชัดเจน โปรไฟล์เฉพาะสำหรับแต่ละประเภทของภาระงาน ชุดเครื่องมือวิเคราะห์ประสิทธิภาพที่แข็งแกร่ง และการควบคุมการเปลี่ยนแปลงอย่างเข้มงวด ทำให้สามารถสร้างเซิร์ฟเวอร์ที่ใช้ฮาร์ดแวร์ได้อย่างเต็มประสิทธิภาพ มีประสิทธิภาพการทำงานที่เพิ่มขึ้น ความหน่วงที่ลดลง และความเสถียรที่มากกว่าการกำหนดค่าจากโรงงานทั่วไป อย่างเห็นได้ชัด