ปรับ postgresql สำหรับ ram จำนวนมาก

ฉันมีเซิร์ฟเวอร์ที่เหมือนกันสองตัว (ในแง่ของฮาร์ดแวร์) พวกเขาเป็นทั้งการติดตั้งมาตรฐานของ windows server 2008 r2 โดยมีการติดตั้งซอฟต์แวร์น้อยที่สุด (โดยทั่วไปคือโค้ดของฉัน

บนเซิร์ฟเวอร์ตัวเดียวฉันใช้ SQL Server 2005 บนเซิร์ฟเวอร์ตัวที่สอง postgresql 9.1 ความแตกต่างของประสิทธิภาพในการทำงาน b / n เซิร์ฟเวอร์ทั้งสองนี้ไม่น่าเชื่อเลยมันแย่มากใน postgresql ที่ฉันเสียใจที่เริ่มแรก "ลองใช้ postgresql แทนที่จะจ่ายใบอนุญาตเซิร์ฟเวอร์ sql" ให้เจ้านายของฉันพูด เรากำลังพูดถึงความแตกต่างของ 30 วินาทีเทียบกับ 15 นาทีสำหรับคำสั่งเดียวกันและไม่ใช่แค่คำสั่งเดียวนี่คือแบบสอบถามหรือคำสั่งใด ๆ ที่ฉันส่งไป พวกเขาทั้งสองมีข้อมูลที่เหมือนกัน (ระเบียนถูกแทรกในลำดับที่แตกต่างกัน) และฐานข้อมูลทั้งสองมีโครงสร้าง / ดัชนีเหมือนกัน ฯลฯ

แต่ฉันหวังว่ามันเป็นเพียงเรื่องของการปรับแต่งประสิทธิภาพ สิ่งคือเซิร์ฟเวอร์ sql ค่อนข้างใช้ ram 32 กิ๊กทั้งหมดบนเซิร์ฟเวอร์ในขณะที่ postgresl ไม่ได้ใช้อะไรเลยมีน้อยกว่า gig ถึงแม้ว่าฉันจะไม่ได้หารายละเอียดดี ๆ

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

มีค่าคงที่ tweakable หลาย initialised postgres.confผ่านมี สิ่งที่สำคัญที่สุดคือ:

• max_connections: จำนวนเซสชันที่เกิดขึ้นพร้อมกัน
• work_mem : จำนวนหน่วยความจำสูงสุดที่จะใช้สำหรับผลลัพธ์ระดับกลางเช่นตารางแฮชและการเรียงลำดับ
• shared_buffers จำนวนหน่วยความจำที่อุทิศให้กับพื้นที่บัฟเฟอร์ 'ปักหมุด'
• effective_cache_size ปริมาณหน่วยความจำที่สมมติว่าใช้โดยบัฟเฟอร์ LRU ของระบบปฏิบัติการ
• random_page_cost : การประมาณการสำหรับค่าใช้จ่ายที่เกี่ยวข้องของการค้นหาดิสก์

max_connectionsไม่ควรตั้งค่าที่สูงกว่าที่ต้องการเชื่อมต่อทรัพยากรต้นทุนแม้ในขณะที่ไม่ได้ใช้งาน ในกรณีส่วนใหญ่การเชื่อมต่อจะใช้เวลาในการรอภายในมากกว่าการรออยู่ข้างนอก (ตามราคาของการเกิดพร้อมกัน) สูตรกฎข้อหัวแม่มือที่ดีคือ "จำนวนของสปินเดิล + จำนวนโปรเซสเซอร์ + X"

work_memเป็นเรื่องยุ่งยาก: จะสามารถนำไปใช้ทุกแบบสอบถามย่อยดังนั้นแบบสอบถามมี 5 HASHJOINSอาจมีค่าใช้จ่าย 5 work_mem* และสำหรับสถานการณ์ที่เลวร้ายที่สุดกรณีคุณควรคิดว่าหลายครั้งเสียเงินจำนวนนี้ (อีกครั้งเหตุผลที่จะเก็บmax_connectionsต่ำ)

shared_buffersคือ (IMHO) เกินจริง โดยปกติแล้วควรตั้งค่าไว้ที่ประมาณ 1/4 ... 1/2 ของหน่วยความจำ "ฟรี" ที่มีอยู่ทั้งหมด แต่ฉันมักจะทำให้มันต่ำและตั้งeffective_cache_sizeเป็นหน่วยความจำ "ฟรี" ที่มีอยู่ทั้งหมด

random_page_costเป็นค่าใช้จ่ายสำหรับการค้นหา + อ่านบนดิสก์ มันสัมพันธ์กับsequential_disk_cost, ซึ่งคือ 1 การตั้งค่าเริ่มต้น (4) สำหรับrandom_page_costสูงเกินไปสำหรับเครื่องจักรที่ทันสมัยและที่เก็บข้อมูลเครือข่ายโดยปกติจะสามารถลดลงได้ระหว่าง 2 ถึง 1.x สำหรับดิสก์ SSD คุณยังสามารถตั้งค่าเป็น 1.0 ได้เนื่องจากการค้นหานั้นฟรีสำหรับ SSD

พิจารณาใช้pgtuneเพื่อช่วยคุณปรับแต่งการกำหนดค่า PostgreSQL จาก PgFoundry:

pgtune ใช้ค่าเริ่มต้น wimpy postgresql.conf และขยายเซิร์ฟเวอร์ฐานข้อมูลให้มีประสิทธิภาพเท่ากับฮาร์ดแวร์ที่ใช้งาน

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

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

หากทุกคำสั่งหรือคำสั่งทำงานช้าฉันสงสัยว่า:

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

คุณช่วยกรุณาบอกให้เราทราบเท่าใดเวลาที่ใช้ในการเรียกใช้แบบสอบถามเหมือนselect version()? ถ้าควรจะเป็นทันที (0,16ms ในเวิร์กสเตชันของฉัน)

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

ดังนั้น, คุณใช้ระบบปฏิบัติการอะไร pgsql? ฮาร์ดแวร์อะไร คุณได้เปลี่ยนแปลงการตั้งค่าใดบ้าง ชุดข้อมูลของคุณใหญ่แค่ไหน? ตัวอย่างของแบบสอบถามที่ไม่ดีและผลลัพธ์ของการวิเคราะห์อธิบาย (เรียกใช้แบบสอบถามของคุณเช่นนี้:

อธิบายวิเคราะห์เลือก ... ส่วนที่เหลือของแบบสอบถามที่นี่ ... ;

โพสต์เอาต์พุตไปที่http://explain.depesz.com/และโพสต์ลิงก์ที่นี่