การปรับแต่ง Linux เพื่อปรับปรุงประสิทธิภาพ PostgreSQL อิลยา คอสโมเดเมียนสกี้

สำเนารายงานปี 2015 โดย Ilya Kosmodemyansky "การปรับแต่ง Linux เพื่อปรับปรุงประสิทธิภาพของ PostgreSQL"

ข้อจำกัดความรับผิดชอบ: ฉันทราบว่ารายงานนี้ลงวันที่เดือนพฤศจิกายน 2015 - ผ่านไปมากกว่า 4 ปีและผ่านไปนานมากแล้ว ไม่รองรับเวอร์ชัน 9.4 ที่กล่าวถึงในรายงานอีกต่อไป ในช่วง 4 ปีที่ผ่านมา มีการเปิดตัว PostgreSQL ใหม่ 5 รายการ และเคอร์เนล Linux 15 เวอร์ชันได้รับการเผยแพร่ หากคุณเขียนข้อความเหล่านี้ใหม่ คุณจะพบรายงานอื่น แต่ที่นี่เราจะพิจารณาการปรับแต่ง Linux ขั้นพื้นฐานสำหรับ PostgreSQL ซึ่งยังคงมีความเกี่ยวข้องในปัจจุบัน

ฉันชื่ออิลยา คอสโมเดเมียนสกี ฉันทำงานที่ PostgreSQL-Consulting และตอนนี้ฉันจะพูดเล็กน้อยเกี่ยวกับสิ่งที่ต้องทำกับ Linux ที่เกี่ยวข้องกับฐานข้อมูลโดยทั่วไปและโดยเฉพาะ PostgreSQL เนื่องจากหลักการค่อนข้างคล้ายกัน

เราจะพูดถึงเรื่องอะไร? หากคุณสื่อสารกับ PostgreSQL คุณจะต้องเป็นผู้ดูแลระบบ UNIX ในระดับหนึ่ง มันหมายความว่าอะไร? หากเราเปรียบเทียบ Oracle และ PostgreSQL ใน Oracle คุณจะต้องเป็นผู้ดูแลระบบฐานข้อมูล DBA 80% และผู้ดูแลระบบ Linux 20%

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

ทำไมเราถึงพูดถึง Linux? ไม่ใช่เลยเพราะเราอยู่ที่การประชุม Linux Peter แต่เนื่องจากในสภาพปัจจุบันหนึ่งในระบบปฏิบัติการที่เหมาะสมที่สุดสำหรับการใช้ฐานข้อมูลโดยทั่วไปและโดยเฉพาะ PostgreSQL ก็คือ Linux เนื่องจาก FreeBSD โชคไม่ดีที่กำลังพัฒนาไปในทิศทางที่แปลกมาก และจะมีปัญหาทั้งเรื่องประสิทธิภาพและเรื่องอื่น ๆ อีกมากมาย โดยทั่วไปประสิทธิภาพของ PostgreSQL บน Windows เป็นปัญหาร้ายแรงอีกประการหนึ่ง โดยพิจารณาจากข้อเท็จจริงที่ว่า Windows ไม่มีหน่วยความจำที่ใช้ร่วมกันเหมือนกับ UNIX ในขณะที่ PostgreSQL ล้วนเกี่ยวข้องกับเรื่องนี้ เนื่องจากเป็นระบบที่มีหลายกระบวนการ

และฉันคิดว่าทุกคนไม่ค่อยสนใจสิ่งแปลกใหม่อย่างโซลาริส ไปกันเลย

การกระจาย Linux สมัยใหม่มีตัวเลือก syctl มากกว่า 1 รายการ ขึ้นอยู่กับว่าคุณสร้างเคอร์เนลอย่างไร ขณะเดียวกันถ้าเราดูถั่วชนิดต่างๆ เราก็สามารถปรับบางอย่างได้หลายวิธี มีพารามิเตอร์ระบบไฟล์เกี่ยวกับวิธีการเมานต์ หากคุณมีคำถามเกี่ยวกับวิธีการเริ่มต้น: สิ่งที่ต้องเปิดใช้งานใน BIOS วิธีกำหนดค่าฮาร์ดแวร์ ฯลฯ

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

มีเป้าหมายการปรับแต่งแบบเดิมๆ อะไรบ้างใน Linux? ฉันคิดว่าเนื่องจากพวกคุณทุกคนกำลังจัดการกับการดูแลระบบ Linux จึงไม่จำเป็นต้องอธิบายว่าเป้าหมายคืออะไร

คุณสามารถปรับแต่ง:

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

ลักษณะเฉพาะของ PostgreSQL และฐานข้อมูลโดยทั่วไปมีอะไรบ้าง ปัญหาคือคุณไม่สามารถปรับแต่งน็อตแต่ละตัวได้ และเห็นว่าประสิทธิภาพของเราดีขึ้นอย่างเห็นได้ชัด

ใช่ มีอุปกรณ์ดังกล่าวอยู่บ้าง แต่ฐานข้อมูลเป็นสิ่งที่ซับซ้อน มันโต้ตอบกับทรัพยากรทั้งหมดที่เซิร์ฟเวอร์มีและต้องการโต้ตอบอย่างเต็มที่ หากคุณดูคำแนะนำในปัจจุบันของ Oracle เกี่ยวกับวิธีใช้ระบบปฏิบัติการโฮสต์ มันจะเป็นเหมือนเรื่องตลกเกี่ยวกับนักบินอวกาศชาวมองโกเลียคนนั้น - ให้อาหารสุนัขและไม่แตะต้องอะไรเลย ให้ทรัพยากรทั้งหมดแก่ฐานข้อมูลฐานข้อมูลจะจัดเรียงทุกอย่างเอง

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

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

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

ดิสก์อยู่ภายใต้ระบบนี้ ฉันวาดสิ่งนี้เป็นดิสก์ ในความเป็นจริงอาจมีตัวควบคุม RAID เป็นต้น

และอินพุต-เอาท์พุตนี้เกิดขึ้นไม่ทางใดก็ทางหนึ่งผ่านเรื่องนี้

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

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

เหตุใดจึงทำเช่นนี้? ถ้าเราสูญเสียแรงดันไฟฟ้า เราก็จะไม่ได้รับสถานการณ์ที่ข้อมูลทั้งหมดสูญหาย จนถึงตอนนี้ หน่วยความจำถาวรที่ทุกคนบอกเรานั้นยังอยู่ในทฤษฎีฐานข้อมูล - นี่คืออนาคตที่สดใสซึ่งแน่นอนว่าเรามุ่งมั่นและชอบ แต่ตอนนี้พวกเขามีชีวิตอยู่ในอีก 20 ปีข้างหน้า และแน่นอนว่าทั้งหมดนี้ต้องได้รับการตรวจสอบ

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

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

มาดูแต่ละประเด็นกันดีกว่า

หากต้องการให้เพจเหล่านี้เดินทางกลับไปกลับมาเร็วขึ้น คุณต้องดำเนินการดังต่อไปนี้:

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

หากคุณมี RAM 512 GB ในเซิร์ฟเวอร์และทั้งหมดนั้นจบลงที่ฮาร์ดไดรฟ์ SATA โดยไม่มีแคชใด ๆ เซิร์ฟเวอร์ฐานข้อมูลทั้งหมดจะเปลี่ยนไม่ใช่แค่ฟักทอง แต่เป็นฟักทองที่มีอินเทอร์เฟซ SATA คุณจะเจอมันโดยตรง และไม่มีอะไรจะช่วยคุณได้

ประเด็นแรกเรื่องความจำ มี XNUMX ประการที่ทำให้ชีวิตลำบากมาก

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

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

เกิดอะไรขึ้นจริงๆ? NUMA ย่อมาจากการเข้าถึงหน่วยความจำที่ไม่สม่ำเสมอ ประเด็นคืออะไร? คุณมี CPU ถัดจากนั้นมีหน่วยความจำในเครื่อง และการเชื่อมต่อระหว่างหน่วยความจำนี้สามารถดึงหน่วยความจำจาก CPU อื่นได้

ถ้าคุณวิ่ง numactl --hardwareแล้วจะได้แผ่นใหญ่ขนาดนี้ เหนือสิ่งอื่นใดจะมีสนามระยะทาง จะมีตัวเลข 10-20 อะไรประมาณนั้น ตัวเลขเหล่านี้ไม่มีอะไรมากไปกว่าจำนวนฮ็อพในการรับหน่วยความจำระยะไกลนี้และใช้งานในเครื่อง โดยหลักการแล้วเป็นความคิดที่ดี สิ่งนี้จะช่วยเร่งความเร็วประสิทธิภาพได้ดีภายใต้ปริมาณงานที่หลากหลาย

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

ดังนั้นตัวเลือกที่ถูกต้องกว่าสำหรับฐานข้อมูลคือให้ระบบปฏิบัติการ Linux ไม่รู้ว่าเกิดอะไรขึ้น เพื่อที่จะเข้าถึงหน่วยความจำตามที่เป็นอยู่

ทำไมเป็นเช่นนั้น? ดูเหมือนว่ามันควรจะเป็นอย่างอื่น สิ่งนี้เกิดขึ้นด้วยเหตุผลง่ายๆ ประการหนึ่ง: เราต้องการหน่วยความจำจำนวนมากสำหรับแคชของหน้า - นับสิบหลายร้อยกิกะไบต์

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

ดังนั้นจึงมีสองแนวทางในขณะนี้จนกว่าอนาคตที่สดใสจะมาถึงและฐานข้อมูลเองก็ไม่สามารถระบุได้ว่า CPU ตัวใดที่ทำงานอยู่และจำเป็นต้องดึงบางสิ่งจากที่ใด

ดังนั้นแนวทางที่ถูกต้องคือการปิดการใช้งาน NUMA โดยสิ้นเชิงเช่น เมื่อรีบูตเครื่อง ในกรณีส่วนใหญ่ การชนะนั้นมีความสำคัญมากจนไม่มีคำถามใดที่ดีกว่าเกิดขึ้นเลย

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

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

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

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

จุดต่อไปคือหน้าใหญ่ หน้าเว็บขนาดใหญ่เป็นเรื่องยากที่จะทดสอบแยกกัน และไม่มีประโยชน์ที่จะทำเช่นนั้น แม้ว่าจะมีเกณฑ์มาตรฐานที่สามารถทำได้ก็ตาม พวกเขาง่ายต่อการ Google

ประเด็นคืออะไร? คุณมีเซิร์ฟเวอร์ที่ไม่แพงมากซึ่งมี RAM จำนวนมาก เช่น มากกว่า 30 GB คุณไม่ได้ใช้หน้าขนาดใหญ่ ซึ่งหมายความว่าคุณมีค่าใช้จ่ายในการใช้งานหน่วยความจำอย่างแน่นอน และค่าใช้จ่ายนี้อยู่ไกลจากที่น่าพอใจที่สุด

ทำไมเป็นอย่างนั้น? แล้วเกิดอะไรขึ้น? ระบบปฏิบัติการจัดสรรหน่วยความจำเป็นชิ้นเล็กๆ มันสะดวกมาก มันเป็นสิ่งที่เกิดขึ้นในอดีต และหากเราลงรายละเอียด ระบบปฏิบัติการจะต้องแปลที่อยู่เสมือนเป็นที่อยู่จริง และกระบวนการนี้ไม่ใช่วิธีที่ง่ายที่สุด ดังนั้น OS จึงแคชผลลัพธ์ของการดำเนินการนี้ไว้ใน Translation Lookaside Buffer (TLB)

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

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

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

และสิ่งนี้จะเป็นเพื่อนกับ PostgreSQL ได้อย่างไร ประการแรก ต้องเปิดใช้งานเพจขนาดใหญ่ในเคอร์เนล Linux

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

และหากเซิร์ฟเวอร์ทั้งหมดของคุณทุ่มเทให้กับ PostgreSQL จุดเริ่มต้นที่ดีคือการจัดสรร RAM 25% ให้กับบัฟเฟอร์ที่ใช้ร่วมกัน หรือ 75% หากคุณแน่ใจว่าฐานข้อมูลของคุณจะพอดีกับ 75% นี้อย่างแน่นอน จุดเริ่มต้นที่หนึ่ง. และพิจารณาว่าถ้าคุณมี RAM 256 GB คุณจะมีบัฟเฟอร์ขนาดใหญ่ 64 GB คำนวณโดยประมาณด้วยการสำรองบางส่วน - ควรตั้งค่าตัวเลขนี้ไว้ที่เท่าใด

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

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

แต่ชุมชนได้ให้ความสนใจกับปัญหานี้ และใน 9.4 พวกเขาก็ปรับปรุงกิจกรรมนี้ใหม่ได้ดีมาก และใน 9.4 พารามิเตอร์ปรากฏใน postgresql.conf ซึ่งคุณสามารถเปิดใช้งาน try, on หรือ off ได้

ลองเป็นตัวเลือกที่ปลอดภัยที่สุด เมื่อ PostgreSQL เริ่มทำงาน เมื่อจัดสรรหน่วยความจำที่ใช้ร่วมกัน ระบบจะพยายามดึงหน่วยความจำนี้จากเพจขนาดใหญ่ และหากไม่ได้ผลก็จะย้อนกลับไปที่การเลือกปกติ และถ้าคุณมี FreeBSD หรือ Solaris คุณสามารถลองใช้ได้ มันจะปลอดภัยเสมอ

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

อีกหนึ่งบันทึกเล็กๆ น้อยๆ ก่อนที่เราจะไปต่อ หน้าเพจขนาดใหญ่ที่โปร่งใสยังไม่เกี่ยวกับ PostgreSQL เขาไม่สามารถใช้มันได้ตามปกติ และด้วยเพจโปร่งใสขนาดใหญ่สำหรับเวิร์กโหลดดังกล่าว เมื่อจำเป็นต้องใช้หน่วยความจำที่ใช้ร่วมกันขนาดใหญ่ ประโยชน์จะมาพร้อมกับวอลุ่มที่ใหญ่มากเท่านั้น หากคุณมีหน่วยความจำเทราไบต์ สิ่งนี้อาจเข้ามามีบทบาท หากเรากำลังพูดถึงแอปพลิเคชันในชีวิตประจำวันมากขึ้น เมื่อคุณมีหน่วยความจำ 32, 64, 128, 256 GB ในเครื่องของคุณ หน้าขนาดใหญ่ตามปกติก็ใช้ได้ และเราก็ปิดการใช้งานแบบโปร่งใส

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

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

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

ก่อนหน้านี้ เราแนะนำให้ตั้งค่า vm.swappiness ให้เป็นศูนย์ เช่น ปิดการใช้งาน swap ก่อนหน้านี้ ดูเหมือนว่า RAM ขนาด 32 GB และบัฟเฟอร์ที่ใช้ร่วมกันที่เกี่ยวข้องนั้นมีปริมาณมหาศาล วัตถุประสงค์หลักของการแลกเปลี่ยนคือการมีที่สำหรับโยนเปลือกโลกถ้าเราหลุดออกไป และมันก็ไม่สมหวังเป็นพิเศษอีกต่อไป แล้วคุณจะทำอย่างไรกับเปลือกนี้? นี่เป็นงานที่ไม่ชัดเจนนักว่าทำไมจึงต้องมีการสลับ โดยเฉพาะอย่างยิ่งขนาดดังกล่าว

แต่ในเคอร์เนลเวอร์ชันที่สามที่ทันสมัยกว่า พฤติกรรมก็เปลี่ยนไป และหากคุณตั้งค่า swap เป็นศูนย์เช่น ปิดไม่ช้าก็เร็วแม้ว่าจะมี RAM เหลืออยู่บ้างก็ตาม OOM killer จะมาหาคุณเพื่อฆ่าผู้บริโภคที่เข้มข้นที่สุด เพราะเขาจะพิจารณาว่าด้วยภาระงานดังกล่าว เรายังเหลืออีกเล็กน้อยและเราจะรีบออกไป กล่าวคือ ไม่ใช่เพื่อตอกย้ำกระบวนการของระบบ แต่เพื่อตอกย้ำสิ่งที่สำคัญน้อยกว่า สิ่งที่สำคัญน้อยกว่านี้จะเป็นผู้บริโภคหน่วยความจำที่ใช้ร่วมกันอย่างเข้มข้นนั่นคือนายไปรษณีย์ และหลังจากนั้นจะดีถ้าไม่ต้องคืนฐาน

ดังนั้น เท่าที่ฉันจำได้ ในตอนนี้ ค่าเริ่มต้นของการแจกแจงส่วนใหญ่จะอยู่ที่ประมาณ 6 นั่นคือ คุณควรเริ่มใช้ swap ณ จุดใด ขึ้นอยู่กับจำนวนหน่วยความจำที่เหลืออยู่ ตอนนี้เราขอแนะนำให้ตั้งค่า vm.swappiness = 1 เนื่องจากจะเป็นการปิดการทำงานจริง แต่ไม่ได้ให้ผลเช่นเดียวกับ OOM-killer ที่มาถึงและทำลายสิ่งทั้งหมดโดยไม่คาดคิด

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

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

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

ที่นี่ฉันมีสองภาพ ตอนนี้ฉันจะอธิบายว่ามันคืออะไร นี่คือกราฟสองกราฟที่สัมพันธ์กับเวลา กราฟแรกคือการใช้ดิสก์ ตอนนี้มันถึงเกือบ 90% แล้ว หากคุณมีความล้มเหลวของฐานข้อมูลกับฟิสิคัลดิสก์ โดยมีการใช้งานคอนโทรลเลอร์ RAID อยู่ที่ 90% นี่ถือเป็นข่าวร้าย ซึ่งหมายความว่าอีกเล็กน้อยจะถึง 100 และ I/O จะหยุดลง

หากคุณมีดิสก์อาร์เรย์ เรื่องราวก็จะแตกต่างออกไปเล็กน้อย ขึ้นอยู่กับว่ากำหนดค่าไว้อย่างไร เป็นอาร์เรย์ประเภทใด ฯลฯ

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

จะต้องทำอะไรเพื่อเอาชนะปัญหานี้? หากคุณหยุด IO ภายใต้ฐานข้อมูล หมายความว่าผู้ใช้ทุกคนที่เข้ามาเพื่อตอบสนองคำขอของตนจะรอ

หากคุณมองจากมุมมองของ Linux หากคุณใช้ฮาร์ดแวร์ที่ดี กำหนดค่าอย่างถูกต้อง กำหนดค่า PostgreSQL ตามปกติเพื่อให้จุดตรวจสอบเหล่านี้น้อยลง กระจายจุดเหล่านี้เมื่อเวลาผ่านไประหว่างกัน จากนั้น คุณจะเข้าสู่พารามิเตอร์ Debian เริ่มต้น สำหรับลีนุกซ์รุ่นส่วนใหญ่ นี่คือรูปภาพ: vm.dirty_ratio=20, vm.dirty_Background_ratio=10

มันหมายความว่าอะไร? ปีศาจตัวหนึ่งปรากฏขึ้นจากเคอร์เนล 2.6 Pdglush ขึ้นอยู่กับว่าใครใช้ซึ่งมีส่วนร่วมในการทิ้งหน้าสกปรกจากบัฟเฟอร์เคอร์เนลในเบื้องหลังและทิ้งเมื่อจำเป็นต้องทิ้งหน้าสกปรกไม่ว่าจะเกิดอะไรขึ้น เมื่อการทิ้งหน้าสกปรกไม่ได้ช่วยอะไร

เบื้องหลังจะมาเมื่อไหร่? เมื่อ 10% ของ RAM ทั้งหมดที่มีบนเซิร์ฟเวอร์ถูกครอบครองโดยเพจสกปรกในบัฟเฟอร์เคอร์เนล ฟังก์ชันการตัดค่าพิเศษจะถูกเรียกในเบื้องหลัง ทำไมมันถึงเป็นพื้นหลัง? ตามพารามิเตอร์จะคำนึงถึงจำนวนหน้าที่จะตัดออก และสมมติว่าเขาเขียนออกไป N หน้า และสักพักสิ่งนี้ก็หลับไป แล้วเธอก็มาอีกครั้งและคัดลอกหน้าเพิ่มเติม

นี่เป็นเรื่องราวที่ง่ายมาก ปัญหาที่นี่ก็เหมือนกับสระว่ายน้ำ พอไหลลงท่อหนึ่ง มันก็ไหลลงอีกท่อหนึ่ง จุดตรวจของเรามาถึงแล้วและถ้ามันส่งหน้าสกปรกไปสองสามหน้าเพื่อทิ้ง จากนั้นสิ่งทั้งหมดจะค่อยๆ ได้รับการแก้ไขอย่างเรียบร้อยจากเคอร์เนลบัฟเฟอร์ pgflush

หากเพจสกปรกเหล่านี้ยังคงสะสมต่อไป เพจเหล่านั้นจะสะสมมากถึง 20% หลังจากนั้นลำดับความสำคัญของระบบปฏิบัติการคือการเขียนสิ่งทั้งหมดลงดิสก์ เนื่องจากพลังงานจะล้มเหลวและทุกอย่างจะไม่ดีสำหรับเรา เราจะสูญเสียข้อมูลนี้ เป็นต้น

เคล็ดลับคืออะไร? เคล็ดลับก็คือพารามิเตอร์เหล่านี้ในโลกสมัยใหม่คือ 20 และ 10% ของ RAM ทั้งหมดที่อยู่ในเครื่อง ซึ่งถือว่าใหญ่มากในแง่ของปริมาณงานของระบบดิสก์ใด ๆ ที่คุณมี

ลองนึกภาพคุณมี RAM 128 GB 12,8 GB มาถึงระบบดิสก์ของคุณ และไม่ว่าคุณจะมีแคชอะไรอยู่ที่นั่น ไม่ว่าคุณจะมีอาร์เรย์อะไรก็ตาม มันก็จะอยู่ได้ไม่นานขนาดนั้น

ดังนั้น เราขอแนะนำให้คุณปรับตัวเลขเหล่านี้ทันทีตามความสามารถของคอนโทรลเลอร์ RAID ของคุณ ฉันให้คำแนะนำที่นี่ทันทีสำหรับคอนโทรลเลอร์ที่มีแคช 512 MB

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

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

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

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

มีสองสิ่งที่ค่อนข้างใหม่ พวกมันได้ปรากฏแล้วในแกนที่สาม นี่คือ sched_migration_cost ในหน่วยนาโนวินาทีและ sched_autogroup_enabled ซึ่งเป็นค่าหนึ่งตามค่าเริ่มต้น

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

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

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

เพื่อนร่วมงานของฉัน Alexey Lesovsky ทำการทดสอบด้วย pgbench แบบง่าย ๆ ซึ่งเขาเพิ่มการโยกย้าย_ต้นทุนตามลำดับความสำคัญและปิดการจัดกลุ่มอัตโนมัติ ความแตกต่างของฮาร์ดแวร์ที่ไม่ดีคือเกือบ 10%. มีการอภิปรายเกี่ยวกับรายชื่อผู้รับจดหมายของ postgres ซึ่งผู้คนให้ผลลัพธ์ของการเปลี่ยนแปลงความเร็วการสืบค้นที่คล้ายคลึงกัน มีอิทธิพล 50%. มีเรื่องราวดังกล่าวค่อนข้างมาก

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

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

หากคุณใช้สิ่งนี้บนเซิร์ฟเวอร์ที่มีฐานข้อมูลภายใต้ภาระหนัก ตัวเลือกของคุณคือ acpi_cpufreq + permormance แม้จะมีความต้องการก็ตามก็ยังมีปัญหาอยู่

Intel_pstate เป็นไดรเวอร์ที่แตกต่างออกไปเล็กน้อย และตอนนี้การตั้งค่าให้กับสิ่งนี้เนื่องจากเป็นในภายหลังและทำงานได้ดีขึ้น

และด้วยเหตุนี้ผู้ว่าราชการจึงเป็นเพียงการปฏิบัติงานเท่านั้น Ondemand, powersave และทุกสิ่งทุกอย่างไม่เกี่ยวกับคุณ

ผลลัพธ์ของการอธิบายการวิเคราะห์ PostgreSQL อาจแตกต่างกันตามลำดับความสำคัญหลายประการหากคุณเปิดใช้งานการประหยัดพลังงาน เนื่องจากในทางปฏิบัติแล้ว CPU ภายใต้ฐานข้อมูลของคุณจะทำงานในลักษณะที่คาดเดาไม่ได้โดยสิ้นเชิง

รายการเหล่านี้อาจถูกรวมไว้โดยค่าเริ่มต้น ดูอย่างละเอียดเพื่อดูว่าพวกเขาเปิดไว้ตามค่าเริ่มต้นหรือไม่ นี่อาจเป็นปัญหาใหญ่มาก

และท้ายที่สุด ฉันอยากจะกล่าวขอบคุณทีมงานจากทีม PosgreSQL-Consulting DBA ของเรา นั่นคือ Max Boguk และ Alexey Lesovsky ที่กำลังก้าวหน้าในเรื่องนี้ทุกวัน และเราพยายามทำให้ดีที่สุดเพื่อลูกค้าของเราเพื่อให้ทุกอย่างได้ผลสำหรับพวกเขา มันเหมือนกับคำแนะนำด้านความปลอดภัยในการบิน ทุกสิ่งที่นี่เขียนด้วยเลือด พบถั่วแต่ละชนิดในกระบวนการของปัญหาบางอย่าง ฉันยินดีที่จะแบ่งปันให้กับคุณ

คำถาม:

ขอบคุณ! ตัวอย่างเช่น หากบริษัทต้องการประหยัดเงินและวางฐานข้อมูลและตรรกะของแอปพลิเคชันไว้บนเซิร์ฟเวอร์เดียว หรือหากบริษัทติดตามเทรนด์แฟชั่นของสถาปัตยกรรมไมโครเซอร์วิส ซึ่ง PostgreSQL ทำงานในคอนเทนเนอร์ เคล็ดลับคืออะไร? Sysctl จะส่งผลต่อเคอร์เนลทั้งหมดทั่วโลก ฉันไม่เคยได้ยินมาก่อนว่า sysctls มีการจำลองเสมือนเพื่อให้ทำงานแยกกันบนคอนเทนเนอร์ มีเพียงกลุ่ม c และมีเพียงส่วนหนึ่งของการควบคุมเท่านั้น คุณจะอยู่กับสิ่งนี้ได้อย่างไร? หรือถ้าคุณต้องการประสิทธิภาพ ให้รัน PostgreSQL บนเซิร์ฟเวอร์ฮาร์ดแวร์แยกต่างหากแล้วปรับแต่ง

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

อะไรคือปัญหา? หากนี่คือเครื่องเสมือน เป็นไปได้มากว่าคุณจะมีปัญหามากมาย เช่น เนื่องจากในเครื่องเสมือนส่วนใหญ่ เวลาแฝงของดิสก์ค่อนข้างไม่สอดคล้องกัน แม้ว่าปริมาณงานของดิสก์จะดี แต่ธุรกรรม I/O ที่ล้มเหลวหนึ่งครั้งซึ่งไม่ส่งผลกระทบอย่างมากต่อปริมาณงานเฉลี่ยที่เกิดขึ้น ณ เวลาที่จุดตรวจสอบหรือในขณะที่เขียนถึง WAL ฐานข้อมูลก็จะได้รับผลกระทบอย่างมากจากสิ่งนี้ และคุณจะสังเกตเห็นสิ่งนี้ก่อนที่คุณจะประสบปัญหาเหล่านี้

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

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

แต่อาจมีปัญหากับ NUMA ตัวอย่างเช่น VmWare ทำงานได้ดีกับ NUMA โดยมีการตั้งค่าตรงกันข้าม และที่นี่คุณต้องเลือก - เซิร์ฟเวอร์เหล็กหรือเซิร์ฟเวอร์ที่ไม่ใช่เหล็ก

ฉันมีคำถามเกี่ยวกับ Amazon AWS พวกเขามีภาพที่กำหนดค่าไว้ล่วงหน้า หนึ่งในนั้นเรียกว่า Amazon RDS มีการตั้งค่าแบบกำหนดเองสำหรับระบบปฏิบัติการหรือไม่?

มีการตั้งค่าอยู่ที่นั่น แต่มีการตั้งค่าที่แตกต่างกัน ที่นี่เรากำหนดค่าระบบปฏิบัติการในแง่ของวิธีที่ฐานข้อมูลจะใช้สิ่งนี้ และมีพารามิเตอร์ที่กำหนดว่าเราควรไปในทิศทางใด เช่น การสร้างรูปร่าง นั่นคือเราต้องการทรัพยากรมากมาย ตอนนี้เราจะกินมันให้หมด หลังจากนี้ Amazon RDS จะกระชับทรัพยากรเหล่านี้ และประสิทธิภาพจะลดลงที่นั่น มีเรื่องราวแต่ละเรื่องเกี่ยวกับวิธีที่ผู้คนเริ่มยุ่งกับเรื่องนี้ บางครั้งก็ค่อนข้างประสบความสำเร็จ แต่สิ่งนี้ไม่เกี่ยวข้องกับการตั้งค่าระบบปฏิบัติการ มันเหมือนกับการแฮ็กระบบคลาวด์ นั่นเป็นเรื่องที่แตกต่างกัน

เหตุใดหน้าใหญ่แบบโปร่งใสจึงไม่มีผลกระทบใด ๆ เมื่อเทียบกับ Huge TLB

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

ที่มา: will.com