เกิดอะไรขึ้นในจุดตรวจสอบ PostgreSQL

นี่เป็นส่วนหนึ่งของบันทึกด่านของฉัน:

2014-03-26 11:51:29.341 CDT,,,18682,,532854fc.48fa,4985,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 15047 buffers (1.4%); 0 transaction log file(s) added, 0 removed, 30 recycled; write=68.980 s, sync=1.542 s, total=70.548 s; sync files=925, longest=0.216 s, average=0.001 s",,,,,,,,,""
2014-03-26 11:56:05.430 CDT,,,18682,,532854fc.48fa,4987,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 16774 buffers (1.6%); 0 transaction log file(s) added, 0 removed, 31 recycled; write=72.542 s, sync=17.164 s, total=89.733 s; sync files=885, longest=3.812 s, average=0.019 s",,,,,,,,,""
2014-03-26 12:01:21.650 CDT,,,18682,,532854fc.48fa,4989,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 14436 buffers (1.4%); 0 transaction log file(s) added, 0 removed, 33 recycled; write=122.350 s, sync=5.212 s, total=127.676 s; sync files=924, longest=3.740 s, average=0.005 s",,,,,,,,,""
2014-03-26 12:06:25.028 CDT,,,18682,,532854fc.48fa,4991,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 13277 buffers (1.3%); 0 transaction log file(s) added, 0 removed, 29 recycled; write=126.217 s, sync=5.733 s, total=131.991 s; sync files=894, longest=1.859 s, average=0.006 s",,,,,,,,,""
2014-03-26 12:10:41.958 CDT,,,18682,,532854fc.48fa,4993,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 20765 buffers (2.0%); 0 transaction log file(s) added, 0 removed, 28 recycled; write=88.015 s, sync=10.818 s, total=98.872 s; sync files=881, longest=2.690 s, average=0.012 s",,,,,,,,,""

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

คำถาม: จุดตรวจอาจทำให้เกิดสิ่งนี้? เกิดอะไรขึ้นในด่านตรวจสอบ "ซิงค์"

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

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

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

ฟลัชนี้เกิดขึ้นในสองขั้นตอน:

• บัฟเฟอร์write()ของสกปรกshared_buffersกับตาราง; และ
• fsync() ของไฟล์ที่ได้รับผลกระทบเพื่อให้แน่ใจว่าการเปลี่ยนแปลงจะกระทบกับดิสก์

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

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

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

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

ฟลัชชิงสกปรกไฟล์ OS บัฟเฟอร์ระบบที่เกิดจากเกินdirty_bytesหรือdirty_ratio เป็นเบื้องหน้าการปิดกั้นการดำเนินงาน!

tunables เคอร์เนลdirty_bytes, dirty_background_bytes, dirty_ratio, dirty_background_ratioและdirty_centisecsการควบคุมการล้างของสกปรกบัฟเฟอร์ระบบไฟล์ OS ไปยังดิสก์ dirty_bytesคือขีด จำกัด เป็นไบต์dirty_ratioเป็นขีด จำกัด เป็นอัตราส่วนของหน่วยความจำทั้งหมด dirty_background_bytesและdirty_background_ratioมีเกณฑ์ใกล้เคียงกัน แต่การฟลัชเกิดขึ้นในพื้นหลังและไม่บล็อกการดำเนินการอ่าน / เขียนอื่น ๆ จนกว่าจะเสร็จสมบูรณ์ dirty_centisecsคือกี่วินาทีก่อนที่จะส่งผ่านฟลัช

เมื่อเร็ว ๆ นี้ค่าเริ่มต้นสำหรับ tunables เหล่านี้ลดลงใน Linux เนื่องจากขนาดหน่วยความจำสำหรับเครื่องทันสมัยเพิ่มขึ้นอย่างมาก แม้แต่อัตราส่วน 5 และ 10% สำหรับdirty_background_ratioและdirty_ratioบนเครื่อง 256GB อาจทำให้ระบบ I / O เสียหายได้

การปรับแต่งdirty_background_bytesหรือdirty_background_ratioเพื่อเริ่มล้างบัฟเฟอร์สกปรกในพื้นหลังนั้นยุ่งยาก โชคดีที่คุณสามารถปรับการตั้งค่าเหล่านี้ได้โดยไม่ต้องหยุด PostgreSQL หรือโฮสต์โดยการสะท้อนค่าใหม่ไปยังไฟล์ที่เหมาะสม:

$ sudo echo [int value of bytes] > /proc/sys/vm/dirty_background_bytes

ตัวอย่างเช่นการตั้งค่าจำนวนไบต์ที่สกปรกเพื่อก่อให้เกิดการล้างพื้นหลัง หากคุณกำลังใช้แบตเตอรี่สำรองเก็บประจุได้รับการสนับสนุนหรือหน่วยความจำแฟลชการ์ด RAID (คุณไม่ต้องการที่จะเก็บข้อมูลของคุณในกรณีของความผิดพลาดไม่ได้คุณ?) เริ่มต้นด้วยการปรับแต่งdirty_background_bytes1/2 เขียนแคชขนาดของบัฟเฟอร์ และdirty_bytesถึงขนาด 3/4 ตรวจสอบโปรไฟล์ I / O ของคุณด้วย iostats และหากคุณยังคงเห็นปัญหาเวลาในการตอบสนองซึ่งหมายความว่าโหลดการเขียนฐานข้อมูลของคุณยังคงล้นแคชไฟล์บัฟเฟอร์ ลดค่าลงจนกว่าเวลาในการตอบสนองจะดีขึ้นหรือพิจารณาอัปเกรดระบบย่อย I / O ของคุณ การ์ด FusionIO และ SSD นั้นเป็นไปได้สองทางสำหรับการรับส่งข้อมูล I / O ที่รุนแรง

โชคดี!