ฉันควร VACUUM ฐานข้อมูล PostgreSQL ของฉันด้วยตนเองหรือไม่หากเปิดเครื่องอัตโนมัติ

15

ฉันใช้ซอฟต์แวร์ที่สร้างฐานข้อมูล PostgreSQL ขนาดใหญ่ (มีตารางหนึ่งล้านแถว) และผู้พัฒนาบอกว่าฉันควรทำVACUUMและควรทำเป็นANALYZEระยะ แต่ฐานข้อมูล PostgreSQL จะถูกautovacuumเปิดใช้งาน

ฉันควรดูดฝุ่น / วิเคราะห์เลยหรือไม่? ประโยชน์คืออะไร ความแตกต่างระหว่างสูญญากาศอัตโนมัติและแมนนวลคืออะไร

ตัวอย่างเช่นใน Pgadmin3 ฉันมีสิ่งนี้:
ป้อนคำอธิบายรูปภาพที่นี่

postgresql maintenance vacuum

— kissgyorgy
แหล่งที่มา

12

ฉันเห็นด้วยกับ ETL ว่าไม่มีคำตอบสั้น ๆ ขนาดไม่ใช่สิ่งเดียวที่สำคัญ - เรารันฐานข้อมูล PostgreSQL OLTP ค่อนข้างมาก (มีบางตาราง> 100.000.000 แถว) ภายใต้การโหลดจำนวนมากและขณะนี้เราพึ่งพา autovacuum เท่านั้น

กระนั้นสองสิ่งที่สำคัญสำหรับฉันก็คือ

ดูเหมือนจะมีฉันทามติที่ว่า autovacuum ไม่ควรถูกปิดยกเว้นคุณมีเวิร์กโหลดที่กำหนดไว้เป็นอย่างดีในฐานข้อมูลของคุณและคุณรู้ว่าคุณกำลังทำอะไรอยู่ แต่โดยธรรมชาติคุณสามารถทำเพิ่มเติมVACUUMและ / หรือANALYZEเรียกใช้
ก่อนที่จะพิจารณาการVACUUMวิ่งเพิ่มเติมฉันจะตรวจสอบว่า autovacuum ติดตามได้อย่างไร คุณสามารถตรวจสอบว่าตารางใด ๆ เกินกว่าเกณฑ์ autovacuum โดยการสอบถามและpg_stat_user_tables pg_classผมโพสต์แบบสอบถามดังกล่าวในหัวข้ออื่นที่อาจจะมีที่น่าสนใจ: ก้าวร้าว Autovacuum บน PostgreSQL

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

บางส่วนของเอกสาร PostgreSQL (ยอดเยี่ยมที่สุด) ที่ฉันพบว่ามีประโยชน์:

— pygrac
แหล่งที่มา

7

Autovacuumน่าจะครอบคลุมได้ดียกเว้นว่าคุณกำหนดค่าผิดพลาด คำตอบอื่น ๆ ที่ครอบคลุมแล้ว

มีกรณีหนึ่งที่กำหนดไว้อย่างชัดเจนสำหรับคู่มือ VACUUM (และที่สำคัญกว่า: คู่มือANALYZE) แม้ว่า: ตารางชั่วคราวพวกเขาไม่ได้รับการพิจารณาโดยปีศาจ autovacuum ฉันพูดคู่มือCREATE TABLEที่นี่ :

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

— Erwin Brandstetter
แหล่งที่มา

4

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

นี่คือลิงค์ที่ดีในเรื่องนี้:

ในการตัดสินใจที่ชัดเจนต้องมีความเข้าใจในฐานข้อมูลและรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่เกิดขึ้น

— ETL
แหล่งที่มา

1

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

หากต้องการดูการตั้งค่าปัจจุบันของคุณให้เรียกใช้คิวรีนี้:

SELECT *
FROM pg_settings 
WHERE name LIKE '%vacuum%'

ฟิลด์ส่วนใหญ่อธิบายตนเอง แต่นี่คือเอกสารเกี่ยวกับพวกเขา: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

ฉันจะบอกว่าเป้าหมายของคุณควรกำหนดค่า autovacuum เพื่อทำความสะอาดขยะอย่างสม่ำเสมอ แต่อย่าเรียกใช้ autovacuum อย่างต่อเนื่อง

การตั้งค่าที่สำคัญที่สุดคือ:

autovacuum_vacuum_scale_factor - กำหนดเปอร์เซ็นต์ของสิ่งอันดับที่สามารถตายก่อนที่จะมีการเรียกใช้การล้างข้อมูล ค่าเริ่มต้น = 0.2
autovacuum_vacuum_threshold - จำนวน tuples ขั้นต่ำสุดก่อนที่จะเรียกใช้การล้างข้อมูล ค่าเริ่มต้น = 50

เกณฑ์ช่วยป้องกันกระบวนการล้างข้อมูลที่จะถูกเรียกใช้บ่อยเกินไปสำหรับตารางเล็ก ๆ

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

เกณฑ์ก็สามารถเพิ่มได้เช่นกัน แอปพลิเคชั่นหลายตัวมีตารางอยู่สองสามตารางซึ่งมีการอัปเดตบ่อยครั้งและ 50 tuples นั้นไม่มาก การเพิ่มที่ 1,000 ไม่ควรนำไปสู่ปัญหาใด ๆ แต่แน่นอนคุณควรพิจารณากรณีของคุณเอง

นอกจากนี้คุณยังสามารถปรับแต่ง autovacuum และตั้งค่าที่แตกต่างกันสำหรับตารางบางส่วนของคุณ

ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

หากคุณกำหนดค่า scale_factor และเกณฑ์ที่คุณควรจะปรับ คุณอาจเพิ่มขึ้นautovacuum_vacuum_cost_limitซึ่งโดยค่าเริ่มต้นเท่ากับvacuum_cost_limitซึ่งตั้งไว้ที่ 200 นี่เป็นคุณสมบัติที่สำคัญมากของการดูดซึ่งไม่อนุญาตให้กินทรัพยากรทั้งหมดและอนุญาตให้แอปพลิเคชันของคุณทำงานกับข้อมูลแม้ในระหว่างกระบวนการดูดฝุ่น แต่ค่าเริ่มต้นต่ำเกินไป การเพิ่มเป็น 1,000 ไม่ควรนำไปสู่ความล่าช้าที่สำคัญใด ๆ แต่จะทำให้กระบวนการสูญญากาศทำงานเสร็จเร็วขึ้นมาก

แน่นอนคุณสามารถใช้สุญญากาศได้ด้วยตนเอง ในกรณีที่ง่ายที่สุดคุณสามารถมีงาน cron ง่ายซึ่งจะทำให้การทำความสะอาดเต็มรูปแบบทุกคืนเมื่อ DB ของคุณไม่ได้เข้าถึงบ่อย

หวังว่าจะช่วย!

— Hasan Ammori
แหล่งที่มา