ปรับ PostgreSQL ให้เหมาะสมที่สุดสำหรับการปรับปรุง INSERTS และ bytea มากมาย


12

สิ่งที่เรามี (ซอฟต์แวร์):

  • PostrgeSQL 9.3พร้อมการกำหนดค่าพื้นฐาน (ไม่มีการเปลี่ยนแปลงpostgresql.conf)
  • Windows 7 64 บิต

ฮาร์ดแวร์:

  • Intel Core i7-3770 3.9 Ghz
  • RAM 32 Gb
  • WDC WD10EZRX-00L4HBAta ไดรฟ์ (1000Gb, SATA III)

ดังนั้นเราต้องโหลดลงใน DB aprox 100.000.000แถวที่มีbyteaคอลัมน์และง่ายขึ้น500.000.000แถว (โดยไม่ LOBs) มี 2 varcharดัชนีในตารางที่ 1 (ความยาว 13, 19) และ 2 varcharดัชนีในตารางที่ 2 (18, 10 ความยาว) นอกจากนี้ยังมีลำดับสำหรับการสร้าง id สำหรับแต่ละตาราง

ในตอนนี้การดำเนินการเหล่านี้กำลังทำอยู่กับการเชื่อมต่อ 8 แบบขนานกับขนาดแบตช์ JDBC 50 ภาพด้านล่างแสดงให้เห็นถึงการโหลดระบบ: มันเป็นศูนย์โหลดในpostgresqlกระบวนการ หลังจากโหลด 24 ชั่วโมงเราโหลดเพียง 10.000.000 แถวซึ่งเป็นผลลัพธ์ที่ช้ามาก

ป้อนคำอธิบายรูปภาพที่นี่

เรากำลังขอความช่วยเหลือในการปรับแต่งการPostrgreSQLกำหนดค่าตามวัตถุประสงค์:

1) สำหรับการโหลดข้อมูลจำนวนมากอย่างรวดเร็วมันเป็นการดำเนินการเพียงครั้งเดียวดังนั้นจึงอาจเป็นการกำหนดค่าชั่วคราว

2) สำหรับโหมดการผลิตสำหรับการเลือกจำนวนปานกลางลงในตาราง 2 ตารางนี้โดยดัชนีของพวกเขาโดยไม่ต้องเข้าร่วมและไม่มีการเรียงลำดับ

คำตอบ:


14

สำหรับinsertผลการดำเนินงานให้ดูที่เร่งขึ้นแทรกประสิทธิภาพการทำงานใน PostgreSQLและแทรกกลุ่มใน PostgreSQL

คุณกำลังเสียเวลาของคุณมี JDBC batching insertสำหรับ PgJDBC ไม่ได้ทำอะไรที่เป็นประโยชน์กับinsertแบตช์ก็แค่ทำงานแต่ละคำสั่ง <- นี่ไม่เป็นความจริงอีกต่อไปในเวอร์ชัน PgJDBC ที่ใหม่กว่าซึ่งตอนนี้สามารถแบทช์ข้อความสั่งที่เตรียมไว้เพื่อลดเวลาในการเดินทางไปกลับอย่างมาก แต่มันก็ยังดีกว่า:

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

สำหรับ "โหมดการผลิต" ของคุณฉันขอแนะนำให้โหลดตัวอย่างข้อมูลตั้งค่าแบบสอบถามที่คุณคาดว่าจะทำงานและใช้explain analyzeเพื่อตรวจสอบประสิทธิภาพ สำหรับการทดสอบเท่านั้นใช้enable_พารามิเตอร์เพื่อสำรวจการเลือกแผนที่แตกต่างกัน ตั้งค่าพารามิเตอร์ค่าใช้จ่ายในการวางแผนแบบสอบถาม ( random_page_cost, seq_page_cost, effective_cache_sizeฯลฯ ) ที่เหมาะสมสำหรับระบบของคุณและให้แน่ใจว่าshared_buffersตั้งที่เหมาะสม ตรวจสอบต่อไปในขณะที่คุณเพิ่มภาระงานการผลิตโดยใช้auto_explainโมดูลlog_min_duration_statementการตั้งค่าpg_stat_statementsส่วนขยาย ฯลฯ

ดูรายละเอียดได้จากคู่มือผู้ใช้ PostgreSQL ฉันขอแนะนำให้กลับมาที่นี่เมื่อคุณมีปัญหาที่ชัดเจนมากขึ้นเกี่ยวกับexplain analyzeรายละเอียดการดำเนินการค้นหาเป็นต้น


1
นี่คือคำตอบที่น่าพอใจ! ขอบคุณ.
Jan Mares
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.