คำถามติดแท็ก vacuum

ฉันกำลังพยายามให้ PostgreSQL ทำการดูดฐานข้อมูลของฉันโดยอัตโนมัติ ฉันได้กำหนดค่าสูญญากาศอัตโนมัติดังนี้: autovacuum_vacuum_cost_delay = 0 # ปิดสูญญากาศที่ใช้ต้นทุน autovacuum_vacuum_cost_limit = 10,000 # ค่าสูงสุด autovacuum_vacuum_threshold = 50 # ค่าเริ่มต้น autovacuum_vacuum_scale_factor = 0.2 # ค่าเริ่มต้น ฉันสังเกตว่าสูญญากาศอัตโนมัติจะเริ่มขึ้นเฉพาะเมื่อฐานข้อมูลไม่ได้โหลดดังนั้นฉันจึงเข้าสู่สถานการณ์ที่มีสิ่งอันดับที่ตายแล้วมากกว่าสิ่งอันดับสด ดูตัวอย่างภาพหน้าจอที่แนบมา หนึ่งในตารางมี 23 tuples สด แต่ 16845 tuples ตายรอสูญญากาศ นั่นมันบ้า! Auto vacuum kicks เมื่อการทดสอบเสร็จสิ้นและเซิร์ฟเวอร์ฐานข้อมูลไม่ได้ใช้งานซึ่งไม่ใช่สิ่งที่ฉันต้องการเพราะฉันต้องการให้สูญญากาศอัตโนมัติเตะเมื่อใดก็ตามที่จำนวนของ tuples ที่ตายเกินกว่า 20% tuples สด + 50 เนื่องจากฐานข้อมูล การกำหนดค่า สูญญากาศอัตโนมัติเมื่อเซิร์ฟเวอร์ไม่ได้ใช้งานไม่มีประโยชน์สำหรับฉันเนื่องจากเซิร์ฟเวอร์ที่ใช้งานจริงคาดว่าจะมีการอัปเดต 1000 …

42 postgresql  performance  performance-testing  vacuum 

ฉันใช้ PostgreSQL 9.1 บน Ubuntu VACUUM ANALYZEยังมีกำหนดการแนะนำหรือมีระบบตอบโต้อัตโนมัติเพียงพอที่จะดูแลทุกความต้องการได้หรือไม่? หากคำตอบคือ "มันขึ้นอยู่กับ" แล้ว: ฉันมีฐานข้อมูลขนาดใหญ่ (ขนาดการถ่ายโอนข้อมูลบีบอัด 30 GiB, ไดเรกทอรีข้อมูล 200 GiB) ฉันทำ ETL ลงในฐานข้อมูลนำเข้าใกล้ 3 ล้านแถวต่อสัปดาห์ ตารางที่มีการเปลี่ยนแปลงบ่อยที่สุดนั้นสืบทอดมาจากตารางต้นแบบโดยไม่มีข้อมูลในตารางต้นแบบ (ข้อมูลถูกแบ่งพาร์ติชันเป็นรายสัปดาห์) ฉันสร้างการเปิดตัวรายชั่วโมงและจากที่นั่นรายงานรายวันรายสัปดาห์และรายเดือน ฉันถามเพราะกำหนดVACUUM ANALYZEส่งผลกระทบต่อการรายงานของฉัน มันใช้เวลานานกว่า 5 ชั่วโมงและฉันต้องฆ่ามันสองครั้งในสัปดาห์นี้เพราะมันส่งผลกระทบต่อการนำเข้าฐานข้อมูลปกติ check_postgresไม่ได้รายงานการขยายตัวที่สำคัญในฐานข้อมูลดังนั้นจึงไม่ใช่ปัญหา จากเอกสาร, autovacuum ควรดูแล ID ธุรกรรมที่มีการห่อหุ้มด้วย คำถามที่ยืน: ฉันยังคงต้องVACUUM ANALYZE?

38 postgresql  etl  vacuum 

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

36 postgresql  postgresql-9.1  vacuum 

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

27 postgresql  delete  alter-table  database-size  vacuum 

VACUUMมักจะไม่คืนพื้นที่ว่างในดิสก์ไปยังระบบปฏิบัติการยกเว้นในบางกรณีพิเศษ จากเอกสาร: รูปแบบมาตรฐานของการVACUUMลบเวอร์ชันของแถวที่ตายแล้วในตารางและดัชนีและทำเครื่องหมายพื้นที่ที่มีอยู่สำหรับการใช้ซ้ำในอนาคต อย่างไรก็ตามมันจะไม่คืนพื้นที่ไปยังระบบปฏิบัติการยกเว้นในกรณีพิเศษที่หนึ่งหรือหลายหน้าท้ายตารางกลายเป็นอิสระทั้งหมดและสามารถล็อคตารางแบบเอกสิทธิ์ได้อย่างง่ายดาย ในทางตรงกันข้ามVACUUM FULLบีบอัดตารางอย่างแข็งขันด้วยการเขียนไฟล์ตารางเวอร์ชันใหม่ที่สมบูรณ์โดยไม่มีพื้นที่ว่าง สิ่งนี้จะลดขนาดของตาราง แต่จะใช้เวลานาน นอกจากนี้ยังต้องการพื้นที่ดิสก์เพิ่มเติมสำหรับสำเนาใหม่ของตารางจนกว่าการดำเนินการจะเสร็จสมบูรณ์ คำถามคือจะทำอย่างไรเมื่อฐานข้อมูลนี้one or more pages at the end of a table become entirely freeสำเร็จ? สิ่งนี้สามารถทำได้ผ่านVACUUM FULLแต่ฉันมีพื้นที่ไม่เพียงพอที่จะใช้มัน มีความเป็นไปได้อื่นอีกไหม?

21 postgresql  postgresql-9.2  maintenance  disk-space  vacuum 

ในปี 2558 เรื่องการประดิษฐ์คิดค้น AWS กล่าวว่าเครื่องดูดฝุ่นควรทำงานไม่เพียง แต่หลังจากการปรับปรุงหรือลบ แต่ยังหลังจากการแทรก นี่คือส่วนที่เกี่ยวข้องของการพูดคุย: http://www.youtube.com/watch?v=tZXp19q8RFo&t=16m2s สมมุติว่ามีการล้างข้อมูลที่ต้องทำบนบล็อกแม้ว่าจะได้รับการแทรกเท่านั้นและการล้างข้อมูลนี้สามารถทำได้ทั้งในครั้งแรกที่มีการเลือกบล็อก (ชะลอการอ่าน) หรือระหว่างการดูด สิ่งนี้เป็นจริงหรือไม่และหากเป็นเช่นนั้นการล้างข้อมูลต้องทำอย่างไร

19 postgresql  postgresql-performance  vacuum 

บางคนสามารถอธิบายความแตกต่างระหว่างVACUUMPostgreSQL ประเภทนี้ได้ไหม ฉันอ่านเอกสาร แต่มันเพิ่งบอกว่าFULLล็อคตารางและFREEZE"ค้าง" สิ่งอันดับ ฉันคิดว่ามันเหมือนกัน ฉันผิดหรือเปล่า?

18 postgresql  vacuum 

ฉันจัดการฐานข้อมูลขนาดใหญ่ (หลายร้อยกิ๊ก) ที่มีตารางที่มีบทบาทหลายอย่างบางคนเก็บบันทึกนับล้าน บางตารางจะได้รับการแทรกและลบจำนวนมากเท่านั้นการเพิ่มจำนวนน้อยและการปรับปรุงจำนวนมาก ฐานข้อมูลทำงานบน PostgreSQL 8.4 บนระบบ Debian 6.0 amd64 พร้อม RAM ขนาด 16 กิกะไบต์ บางครั้งคำถามนั้นเป็นกระบวนการอัตโนมัติในตารางใช้เวลานานมาก (วัน) ในการดำเนินการให้เสร็จสมบูรณ์ ฉันต้องการที่จะบอกอย่างคร่าวๆว่าต้องใช้เวลานานเท่าไรในการสั่งการสูญญากาศโดยเฉพาะเพื่อให้สามารถตัดสินใจได้ว่าจะยกเลิกหรือไม่ นอกจากนี้หากมีตัวบ่งชี้ความคืบหน้าสำหรับการดำเนินการสูญญากาศ postgres มันจะมีประโยชน์จริงๆ แก้ไข: ฉันไม่ได้มองหาวิธีแก้ปัญหากระสุน เพียงแค่คำแนะนำคร่าวๆเกี่ยวกับจำนวนของ tuples ที่ตายแล้วหรือไบต์ I / O ที่จำเป็นก็เพียงพอที่จะตัดสินใจได้ มันน่ารำคาญจริง ๆ ที่ไม่มีเงื่อนงำเมื่อVACUUMจะเสร็จสิ้นอะไรก็ตาม ฉันเคยเห็นว่าpg_catalog.pg_stat_all_tablesมีคอลัมน์สำหรับจำนวน tuples ที่ตายแล้ว ดังนั้นจึงเป็นไปได้ที่จะมีการประมาณค่าแม้ว่ามันจะหมายถึงสิ่งที่มีANALYZEอยู่ในตารางก่อนหน้า บนมืออื่น ๆ , autovacuum_vacuum_thresholdและautovacuum_vacuum_scale_factorการตั้งค่าเพียงอย่างเดียวพิสูจน์ว่า postgres ตัวเองรู้ว่าบางสิ่งบางอย่างเกี่ยวกับจำนวนของการเปลี่ยนแปลงบนโต๊ะและอาจทำให้มันอยู่ในมือของ DBA เกินไป ฉันไม่แน่ใจว่าแบบสอบถามใดที่จะเรียกใช้เพราะเมื่อฉันเรียกใช้VACUUM VERBOSEฉันเห็นว่าไม่เพียง แต่ตารางเท่านั้น …

18 postgresql  vacuum 

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

15 postgresql  maintenance  vacuum 

ฉันมีตารางที่มีข้อมูลขนาด 200 GB และมีขนาด 180 GB โดยดัชนี 6 รายการ มันบวม 30% ดังนั้นฉันต้องการเรียกคืนพื้นที่ที่ไม่ต้องการครอบครอง มันเป็นคลัสเตอร์ในjob_id_idดัชนี x ดังนั้นเพื่อเรียกคืนพื้นที่ฉันต้องใช้clusterคำสั่งหรือvacuum fullคำสั่ง? ความแตกต่างระหว่างสองคำสั่งนี้คืออะไร? คือvacuum fullการสั่งซื้อตามคอลัมน์บางเช่นเดียวกับclusterคำสั่ง? ดัชนีถูกสร้างขึ้นใหม่ทั้งในคำสั่งหรือไม่? ในกรณีของฉันอันไหนจะเร็วกว่ากัน? เวอร์ชันของฐานข้อมูล PostgreSQL คือ 9.1

13 postgresql  postgresql-9.1  clustered-index  vacuum 

ฉันมีตารางที่อัปเดตบ่อยมากที่มี 240 ล้านแถว (และเพิ่มขึ้น) ทุกๆสามชั่วโมง 1.5 ล้านแถวจะถูกแทรกและ 1.5 ล้านแถวจะถูกลบ เมื่อฉันย้ายคลัสเตอร์ไปยัง SSD เวลาแทรกจำนวนมาก (โดยใช้การคัดลอก) นี้ถูกตัดจาก 22 นาทีเป็น 2.3 นาที เวลาลบก็ดีขึ้นเช่นกัน ฉันวางแผนที่จะทำการอัปเดตจำนวนมากนี้ทุกสองชั่วโมงหรือทุกชั่วโมง แม้ว่าประสิทธิภาพในตอนนี้ (หลังจาก SSD) เข้ากันได้กับการอัปเดตบ่อยครั้งมากขึ้นฉันได้อ่านเรื่องราวสยองขวัญเกี่ยวกับการตายของ SSD เนื่องจากความอดทนของ NAND จำกัด รวมกับการขยายการเขียน เนื่องจาก SSD มีราคาแพงฉันจึงต้องการผลักดันความตายไปสู่อนาคตเท่าที่จะทำได้ ดังนั้นคำถามของฉัน: เกิดอะไรขึ้นกับไฟล์ดิสก์ในการลบและสูญญากาศที่ตามมา? ฉันเดาว่ามีการเขียนดิสก์สองรายการหนึ่งรายการเพื่อทำเครื่องหมายแถวว่าถูกลบและอีกรายการหนึ่งเมื่อดูดฝุ่นเพื่อทำเครื่องหมายว่าพร้อมใช้งานเพื่อเขียนทับ หากแทนที่การลบและการดูดฉันจะแบ่งพาร์ติชันตารางที่สร้างและวางตารางที่แต่ละส่วนแทรก / ลบจำนวนมากฉันจะลดการสึกหรอของ SSD หรือไม่

13 postgresql  partitioning  delete  storage  vacuum 

เรากำลังใช้ Postgres 9.2 บน Windows เพื่อเก็บข้อมูลไทม์ความถี่ต่ำ: เราแทรกแถวประมาณ 2,000 แถวต่อวินาทีทุก ๆ 24 ชั่วโมง 7 วันต่อสัปดาห์โดยไม่มีการหยุดทำงาน มีการDELETEวิ่งบนโต๊ะทุก ๆ 10 นาทีเพื่อให้ความยาวของตารางเท่ากับจำนวนวันที่กำหนด สิ่งนี้จบลงที่ความมั่นคง 900 ล้านแถว (สำหรับผู้ที่สนใจ, SELECT, INSERT, DELETEมี performant ทั้งหมด) เช่นDELETEนี้ในขณะที่การลบแถวไม่ได้ทำให้พื้นที่ดิสก์ว่าง เพื่อที่เราจะต้องVACUUMวิ่ง ฉันสอบถามpg_stat_user_tablesและVACUUMดูเหมือนว่าจะไม่ได้ทำงาน สิ่งที่ฉันเข้าใจจากเอกสารต่าง ๆ ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ): ดูเหมือนว่าเราจะเปิดเครื่องดูดฝุ่นอัตโนมัติและจะทำงานในตารางอื่น สูญญากาศอัตโนมัติไม่ทำงานFULLและไม่ควรใช้การล็อคแบบเอกสิทธิ์บนโต๊ะ ไม่มีใครมีความคิดใด ๆ ว่าทำไมสูญญากาศอัตโนมัติไม่ทำงาน นี่เป็นเพียงเพราะตารางไม่ว่างอย่างต่อเนื่องหรือไม่ และมันก็คุ้มค่าที่จะทำงานVACUUMหลังจากทุกอย่างDELETEในกรณีนี้ (ซึ่งทำงานทุก 10 นาที)? แก้ไข: การสืบค้นโดยใช้ SQL จากลิงก์ SO …

11 postgresql  vacuum 

ฉันมีตารางที่มีการปรับปรุง / เข้าถึงมากซึ่งฉันเก็บวัตถุ Java ที่ทำให้เป็นอนุกรม พวกเขาอยู่ในตารางเป็นเวลา 2-3 ชั่วโมง (ยังมีการปรับปรุงในช่วงเวลานั้น) แล้วลบออก ขนาดของตารางประมาณ 300MB ฉันเคยเห็นว่ามันมาก VACUUMed บ่อยมากและสงสัยว่าการเปลี่ยนแปลงfillfactorจะช่วยได้อย่างไร

10 postgresql  configuration  nosql  vacuum  fill-factor 

ฉันเล่นซอVACUUMและสังเกตเห็นพฤติกรรมที่ไม่คาดคิดบางอย่างที่SELECTไอเอ็นจีแถวจากตารางดูเหมือนว่าจะลดงานที่VACUUMต้องทำหลังจากนั้น ทดสอบข้อมูล หมายเหตุ: autovacuum ถูกปิดใช้งาน CREATE TABLE numbers (num bigint); ALTER TABLE numbers SET ( autovacuum_enabled = 'f', toast.autovacuum_enabled = 'f' ); INSERT INTO numbers SELECT generate_series(1, 5000); ทดลอง 1 ตอนนี้เราทำการอัพเดทในทุกแถว UPDATE numbers SET num = 0; และเมื่อเราวิ่งVACUUM (VERBOSE) numbers;เราได้ INFO: vacuuming "public.numbers" INFO: "numbers": removed 5000 row versions in …

9 postgresql  select  vacuum  postgresql-11 

ฉันใช้ postgres (postgis) 9.4.2 บน mac (10.10.4) ฉันมีตารางใหญ่สองสามอัน (หลาย TB) ในระหว่างการสร้างดัชนีของหนึ่งในนั้นที่ใช้เวลาประมาณหนึ่งสัปดาห์ฉันดูการลดลงของพื้นที่ HD ที่มีอยู่ตามที่คุณคาดว่าจะถึงจุดที่ดัชนีจะเสร็จสิ้นเมื่อไฟฟ้าดับนานกว่าแบตเตอรี่และระบบ ลงไป. ฉันปิดบัฟเฟอร์และfillfactor=100ระหว่างการสร้างเนื่องจากเป็นแหล่งข้อมูลแบบคงที่ ในการรีบู๊ตพื้นที่ที่เหลืออยู่บนไดรฟ์จะอยู่ในตำแหน่งที่ใกล้ถึงจุดสิ้นสุดของการสร้างดัชนี การวิเคราะห์สูญญากาศไม่เพิ่มพื้นที่ว่าง ฉันลองวางโต๊ะแล้วนำเข้าไปใหม่และนั่นก็ไม่ได้ทำให้เนื้อที่ลดลง ตอนนี้ฉันอยู่ในสถานที่ที่ฉันมีพื้นที่ไม่เพียงพอที่จะสร้างดัชนี ไฟล์ถูกสร้างขึ้นในระหว่างการสร้างดัชนีติดอยู่ในบริเวณขอบรกบางส่วนที่ไม่สามารถลบออกได้โดยระบบเนื่องจากวิธีการที่เครื่องหยุดทำงานในระหว่างไฟฟ้าดับหรือไม่? เมื่อฉันมองไปที่ตารางขนาด + ดัชนีในฐานข้อมูล (ซึ่งเป็นเพียงข้อมูลในไดรฟ์นั้น) พวกเขาเพิ่มขึ้นประมาณ6TB ไดรฟ์คือ8TBและเหลือน้อยกว่า500GBบนไดรฟ์ดังนั้นดูเหมือนว่าจะมีประมาณ 1.5TB ที่หายไปที่ไหนสักแห่งซึ่งมีขนาดเท่ากับดัชนีที่น่าจะเป็น ความคิดใด ๆ

9 postgresql  index  postgresql-9.4  disk-space  vacuum