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

การแนะนำ

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

หลังจากค้นคว้าคำถามนี้แล้ว ฉันพบบทความมากมายเกี่ยวกับการติดตั้ง PostgreSQL ทีละขั้นตอนสำหรับหุ่นจำลอง ทั้งบน Linux และบน Windows แต่บทความส่วนใหญ่อธิบายการติดตั้งจนกระทั่ง "ติดตั้งแล้ว - มาสร้างฐานข้อมูลกันเถอะ" และไม่ได้พูดถึงปัญหาการกำหนดค่าเลย ในส่วนที่เหลือ การกำหนดค่าจะกล่าวถึงในระดับ "ระบุค่าดังกล่าว" เท่านั้น โดยแทบไม่มีคำอธิบายว่าทำไม

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

ควรจำไว้ว่าสำหรับ 1C แอสเซมบลี PostgreSQL จากนักพัฒนา DBMS นั้นไม่เหมาะสม แต่จะประกอบจากซอร์สโค้ด 1C ที่ได้รับแพตช์เท่านั้น แอสเซมบลีที่เข้ากันได้สำเร็จรูปนั้นนำเสนอโดย 1C (ผ่านดิสก์ ITS และบัญชีสำหรับผู้ที่สมัครสมาชิกการสนับสนุน) และ EterSoft

ได้ทำการทดสอบใน สภาพแวดล้อมของวินโดวส์แต่คำแนะนำการกำหนดค่าทั้งหมดไม่ได้เฉพาะแพลตฟอร์มและใช้กับระบบปฏิบัติการใดๆ

การทดสอบและการเปรียบเทียบ

เมื่อทำการทดสอบ ฉันไม่ได้ตั้งใจที่จะดำเนินการทดสอบในโหมดการทำงานและสถานการณ์ทั้งหมด เพียงตรวจสอบการกำหนดค่าที่สำเร็จคร่าวๆ เท่านั้น

สำหรับการทดสอบฉันใช้การกำหนดค่าต่อไปนี้:
เครื่องโฮสต์: Win7, Core i5-760 2.8MHz, 4 คอร์, RAM 12GB, VMWare 10
เสมือน: Win7 x64, 2 คอร์, RAM 4GB, แยกทางกายภาพ ฮาร์ดดิสสำหรับการโฮสต์ฐานข้อมูล (ไม่ใช่ SSD)
MSSQL เอ็กซ์เพรส 2014
PostgreSQL อีเธอร์ซอฟท์ 9.2.1
1C 8.3.5 1383

มีการใช้ฐานข้อมูล dt-upload 780MB
หลังจากกู้คืนฐานข้อมูลแล้ว:
ขนาดไฟล์ 1CD ในเวอร์ชันไฟล์ - 10GB,
ขนาดฐานข้อมูล PostgreSQL - 8GB,
ขนาดฐานข้อมูล MSSQL คือ 6.7GB

สำหรับการทดสอบ ฉันใช้คำขอตัวอย่างข้อตกลงคู่สัญญา (21k) พร้อมการเลือกรายละเอียดเพิ่มเติมจากการลงทะเบียนต่างๆ สำหรับแต่ละข้อตกลง จะมีการสร้างตัวอย่างแยกต่างหากจากการลงทะเบียนจริง ฉันใช้การกำหนดค่าที่มีอยู่ - ได้รับการแก้ไขอย่างมากบนพื้นฐานของ Accounting 3.0

ในระหว่างการทดสอบ ฉันรันคำขอกับไคลเอนต์หนึ่งและสองตัวหลายครั้งจนกระทั่งได้ผลลัพธ์ที่เสถียร ฉันไม่สนใจการวิ่งครั้งแรก

การทดสอบกับไคลเอนต์รายเดียว:

การสุ่มตัวอย่างบนโฮสต์จากเวอร์ชันไฟล์ด้วยฐานข้อมูลที่วางอยู่บน SSD - 31c
การเลือกจากรูปแบบไฟล์ใน เครื่องเสมือน(กับ ฮาร์ดไดรฟ์) - 46ส
การสุ่มตัวอย่างจากฐานข้อมูล MSSQL - ผ่านครั้งแรก - 25 วินาทีหรือ 9 วินาที (เห็นได้ชัดว่าขึ้นอยู่กับความเกี่ยวข้องของแคช DBMS) (การใช้หน่วยความจำโดยกระบวนการ DBMS อยู่ที่ประมาณ 1.3GB)
การสุ่มตัวอย่างจาก PostgreSQL ด้วยการตั้งค่าเริ่มต้น - 43 วินาที (การใช้หน่วยความจำไม่เกิน 80MB ต่อการเชื่อมต่อ)
การสุ่มตัวอย่างจาก PostgreSQL ที่ปรับให้เหมาะสม - 21 วินาที (การใช้หน่วยความจำคือ 120MB ต่อการเชื่อมต่อ)

การทดสอบกับลูกค้าสองราย:

การสุ่มตัวอย่างบนโฮสต์จากเวอร์ชันไฟล์โดยฐานข้อมูลวางอยู่บน SSD - ครั้งละ 34 วินาที
การสุ่มตัวอย่างจากเวอร์ชันไฟล์ในเครื่องเสมือน (จากฮาร์ดไดรฟ์) - ครั้งละ 56 วินาที
การสุ่มตัวอย่างจากฐานข้อมูล MSSQL - 50 หรือ 20 วินาที (ขึ้นอยู่กับความเกี่ยวข้องของแคช DBMS)
การสุ่มตัวอย่างจาก PostgreSQL ด้วยการตั้งค่าเริ่มต้น - ครั้งละ 60 วินาที
การสุ่มตัวอย่างจาก PostgreSQL ที่ปรับให้เหมาะสม - ครั้งละ 40 วินาที

บันทึกการทดสอบ:

1. หลังจากเพิ่มคอร์ตัวที่สามแล้ว ตัวแปร PostgreSQL และ MSSQL ก็เริ่มทำงานในการทดสอบ "ไคลเอนต์สองเครื่อง" เกือบจะเทียบเท่ากับประสิทธิภาพของการทดสอบ "ไคลเอนต์หนึ่งตัว" เช่น ขนานกันได้สำเร็จ สิ่งที่ขัดขวางไม่ให้พวกเขาทำงานขนานกันบนสองคอร์ยังคงเป็นปริศนาสำหรับฉัน
2. MSSQL ใช้หน่วยความจำจำนวนมากในคราวเดียว PostgreSQL ต้องการหน่วยความจำน้อยลงอย่างมากในทุกโหมด และเปิดตัวเกือบทั้งหมดทันทีหลังจากกรอกแบบสอบถาม
3. MSSQL ทำงานเป็นกระบวนการเดียว PostgreSQL เปิดตัวกระบวนการแยกต่างหากต่อการเชื่อมต่อ + กระบวนการบริการ ซึ่งช่วยให้แม้แต่รุ่น 32 บิตก็สามารถใช้หน่วยความจำได้อย่างมีประสิทธิภาพเมื่อประมวลผลคำขอจากไคลเอนต์หลายเครื่อง
4. การเพิ่มหน่วยความจำสำหรับ PostgreSQL ในการตั้งค่าเหนือค่าที่แสดงด้านล่างไม่ได้ทำให้ประสิทธิภาพเพิ่มขึ้นอย่างเห็นได้ชัด
5. การทดสอบครั้งแรกในทุกกรณีใช้เวลานานกว่าการวัดครั้งต่อไป ฉันไม่ได้ทำการวัดพิเศษใดๆ แต่ MSSQL เริ่มเร็วขึ้น

การกำหนดค่า PostgreSQL

มีหนังสือดีๆ ในภาษารัสเซียเกี่ยวกับการกำหนดค่าและเพิ่มประสิทธิภาพ PostgreSQL: เป็นเรื่องที่สมเหตุสมผลสำหรับคนรักช้างทุกคนที่จะบุ๊กมาร์กลิงก์นี้ หนังสือเล่มนี้อธิบายเทคนิคต่างๆ มากมายในการปรับ DBMS ให้เหมาะสม การสร้างระบบที่ทนทานต่อข้อผิดพลาดและแบบกระจาย แต่ตอนนี้เราจะดูสิ่งที่จะเป็นประโยชน์สำหรับทุกคน - การกำหนดค่าการใช้หน่วยความจำ PostgreSQL จะไม่ใช้หน่วยความจำมากเกินกว่าที่การตั้งค่าอนุญาต และด้วยการตั้งค่าเริ่มต้น PostgreSQL จะใช้หน่วยความจำขั้นต่ำ ในเวลาเดียวกัน คุณไม่ควรระบุหน่วยความจำเกินกว่าที่พร้อมใช้งาน - ระบบจะเริ่มใช้ไฟล์สลับพร้อมกับผลที่ตามมาร้ายแรงต่อประสิทธิภาพของเซิร์ฟเวอร์ เคล็ดลับหลายประการในการตั้งค่า PostgreSQL มีระบุไว้ในดิสก์ ITS

บน Windows ไฟล์การกำหนดค่า PostgreSQL จะอยู่ในไดเร็กทอรีการติดตั้งในไดเร็กทอรี Data:

• postgresql.conf- ไฟล์หลักพร้อมการตั้งค่า DBMS
• pg_hba.conf- ไฟล์ที่มีการตั้งค่าการเข้าถึงสำหรับลูกค้า โดยเฉพาะอย่างยิ่ง คุณสามารถระบุได้ว่าผู้ใช้รายใดที่ที่อยู่ IP สามารถเชื่อมต่อกับฐานข้อมูลบางฐานข้อมูลได้ และจำเป็นต้องตรวจสอบรหัสผ่านของผู้ใช้หรือไม่ และหากเป็นเช่นนั้น ด้วยวิธีใด
• pg_ident.conf- ไฟล์ที่มีการแปลงชื่อผู้ใช้จากระบบไปเป็นภายใน (ผู้ใช้ส่วนใหญ่ไม่น่าจะต้องการมัน)

ไฟล์เป็นข้อความ คุณสามารถแก้ไขได้ด้วยแผ่นจดบันทึก เส้นที่ขึ้นต้นด้วย # ถือเป็นความคิดเห็นและละเว้น

พารามิเตอร์ที่เกี่ยวข้องกับความจุหน่วยความจำสามารถเสริมด้วยส่วนต่อท้าย kB, MB, GB - กิโลไบต์, เมกะไบต์, กิกะไบต์เช่น 128MB พารามิเตอร์ที่อธิบายช่วงเวลาสามารถเสริมด้วยคำต่อท้าย ms, s, min, h, d - มิลลิวินาที, วินาที, นาที, ชั่วโมง, วัน, เช่น 5 นาที

หากคุณลืมรหัสผ่านสำหรับ Postgress ก็ไม่มีปัญหา คุณสามารถเขียนลงไปได้ pg_hba.confเส้น:

โฮสต์ความไว้วางใจ 127.0.0.1/32 ทั้งหมด

และเชื่อมต่อโดยผู้ใช้รายใดก็ได้ (เช่น โพสต์เกรส) ไปยัง DBMS บนเครื่องโลคัลที่ 127.0.0.1 โดยไม่ต้องตรวจสอบรหัสผ่าน

การเพิ่มประสิทธิภาพการใช้ความจำ

การตั้งค่าการใช้หน่วยความจำอยู่ใน postgresql.conf

ค่าพารามิเตอร์ที่เหมาะสมที่สุดขึ้นอยู่กับปริมาณของว่าง หน่วยความจำเข้าถึงโดยสุ่มขนาดของฐานข้อมูลและองค์ประกอบแต่ละส่วนของฐานข้อมูล (ตารางและดัชนี) ความซับซ้อนของการสืบค้น (โดยหลักการแล้ว คุณควรถือว่าการสืบค้นจะค่อนข้างซับซ้อน - การเชื่อมต่อหลายครั้งในการสืบค้นเป็นสถานการณ์ทั่วไป) และจำนวน ลูกค้าที่ใช้งานพร้อมกัน อย่างไรก็ตาม PostgreSQL จะจัดเก็บตารางฐานข้อมูลและดัชนีไว้ แยกไฟล์ (<каталог установки PG>\ข้อมูล\ฐาน\<идентификатор БД>\) และสามารถประมาณขนาดของวัตถุได้ คุณยังสามารถใช้ยูทิลิตี้ pgAdmin ที่ให้มาเพื่อเชื่อมต่อกับฐานข้อมูล ขยาย “Schemas” - “public” และสร้างรายงานสถิติสำหรับองค์ประกอบ “Tables”

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

เมื่อตั้งค่าเซิร์ฟเวอร์สำหรับการทดสอบ ฉันอาศัยการคำนวณต่อไปนี้:
RAM เพียง 4GB ผู้บริโภค - Windows OS, เซิร์ฟเวอร์ 1C, PostgreSQL และแคชดิสก์ระบบ ฉันคิดว่าสามารถจัดสรร RAM ได้สูงสุด 2.5GB สำหรับ DBMS

สามารถระบุค่าด้วยส่วนต่อท้าย kB, MB, GB (ค่าเป็นกิโลไบต์ เมกะไบต์ หรือกิกะไบต์) หลังจากเปลี่ยนค่าแล้ว คุณต้องเริ่มบริการ PostgreSQL ใหม่

shared_buffers - บัฟเฟอร์เซิร์ฟเวอร์ที่ใช้ร่วมกัน

ขนาดของแคชการอ่านและเขียน PostgreSQL ที่ใช้ร่วมกันโดยการเชื่อมต่อทั้งหมด หากข้อมูลไม่อยู่ในแคช ข้อมูลนั้นจะถูกอ่านจากดิสก์ (อาจเป็นแคชโดยระบบปฏิบัติการ)

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

แต่นี่ไม่ใช่หน่วยความจำทั้งหมดที่จำเป็นสำหรับการทำงาน คุณไม่ควรระบุมากเกินไป ความสำคัญอย่างยิ่งมิฉะนั้นจะไม่มีหน่วยความจำเหลือทั้งสำหรับการดำเนินการตามคำขอของลูกค้าจริง (และยิ่งมีมากเท่าใด การใช้หน่วยความจำก็จะยิ่งสูงขึ้น) และสำหรับระบบปฏิบัติการและแอปพลิเคชันอื่น ๆ เช่นกระบวนการเซิร์ฟเวอร์ 1C เซิร์ฟเวอร์ยังอาศัยแคชของระบบปฏิบัติการและพยายามไม่เก็บสิ่งที่ระบบน่าจะแคชไว้ในบัฟเฟอร์มากที่สุด

การทดสอบที่ใช้

shared_buffers = 512MB

work_mem- หน่วยความจำสำหรับการเรียงลำดับ การรวมข้อมูล ฯลฯ

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

มีคำแนะนำในการคำนวณเพื่อใช้จำนวนหน่วยความจำที่มีอยู่ลบด้วย shared_buffersและหารด้วยจำนวนคำขอที่ดำเนินการพร้อมกัน ในกรณีที่มีการสืบค้นที่ซับซ้อน ควรเพิ่มตัวหาร เช่น ลดผลลัพธ์ สำหรับกรณีที่อยู่ระหว่างการพิจารณา อิงจากผู้ใช้ที่ใช้งานอยู่ 5 ราย (2.5GB-0.5GB (shared_buffers))/5=400MB หาก DBMS พิจารณาว่าแบบสอบถามค่อนข้างซับซ้อน หรือหากมีผู้ใช้เพิ่มเติมปรากฏขึ้น ค่าจะต้องลดลง

สำหรับการสืบค้นแบบง่ายค่าเล็กน้อยก็เพียงพอแล้ว - มากถึงสองเมกะไบต์ แต่สำหรับการสืบค้นที่ซับซ้อน (และนี่คือสถานการณ์ทั่วไปสำหรับ 1C) จะต้องมากกว่านี้ คำแนะนำ - สำหรับหน่วยความจำ 1-4GB คุณสามารถใช้ค่า 32-128MB ฉันใช้มันในการทดสอบ

work_mem = 128MB

การบำรุงรักษา_งาน_mem- หน่วยความจำสำหรับคำสั่งเก็บขยะ, สถิติ, การสร้างดัชนี

ขอแนะนำให้ตั้งค่าเป็น 50-75% ของขนาดของตารางหรือดัชนีที่ใหญ่ที่สุด แต่เพื่อให้มีหน่วยความจำเพียงพอที่จะเรียกใช้ระบบและแอปพลิเคชัน ขอแนะนำให้ตั้งค่ามากกว่า work_mem ฉันใช้มันในการทดสอบ
การบำรุงรักษา_งาน_mem = 192MB

temp_buffers- บัฟเฟอร์สำหรับวัตถุชั่วคราว ส่วนใหญ่ใช้สำหรับตารางชั่วคราว

คุณสามารถติดตั้งได้ประมาณ 16 MB ฉันใช้มันในการทดสอบ
temp_buffers = 32MB

มีประสิทธิภาพ_แคช_ขนาด- ขนาดโดยประมาณของแคชดิสก์ระบบไฟล์

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

Autovacuum - "เก็บขยะ"

PostgreSQL ในฐานะตัวแทนทั่วไปของ DBMS "เวอร์ชัน" (ซึ่งตรงข้ามกับการบล็อก) ไม่ได้บล็อกตารางและบันทึกอย่างอิสระจากการอ่านธุรกรรมเมื่อเปลี่ยนแปลงข้อมูล (ในกรณีของ 1C เซิร์ฟเวอร์ 1C เองก็ทำสิ่งนี้) แต่จะมีการสร้างสำเนาของบันทึกที่แก้ไข ซึ่งจะปรากฏให้เห็นในการทำธุรกรรมครั้งต่อๆ ไป ในขณะที่รายการที่มีอยู่จะยังคงเห็นข้อมูลที่เป็นปัจจุบันเมื่อเริ่มต้นการทำธุรกรรม เป็นผลให้ข้อมูลที่ล้าสมัยสะสมอยู่ในตาราง - รุ่นก่อนหน้าบันทึกการเปลี่ยนแปลง เพื่อให้ DBMS ใช้พื้นที่ว่าง จำเป็นต้องดำเนินการ "รวบรวมขยะ" - เพื่อพิจารณาว่าบันทึกใดจะไม่ถูกใช้อีกต่อไป ซึ่งสามารถทำได้อย่างชัดเจนด้วยคำสั่ง SQL เครื่องดูดฝุ่นหรือรอให้เครื่องเก็บขยะอัตโนมัติประมวลผลตาราง - เครื่องดูดฝุ่นอัตโนมัติ. นอกจากนี้ การรวบรวมขยะยังเชื่อมโยงกับการรวบรวมสถิติจนถึงเวอร์ชันหนึ่ง (ผู้วางแผนใช้ข้อมูลเกี่ยวกับจำนวนบันทึกในตารางและการกระจายค่าของฟิลด์ที่จัดทำดัชนีเพื่อสร้างแผนการสืบค้นที่เหมาะสมที่สุด) ประการหนึ่ง ต้องทำการรวบรวมขยะเพื่อไม่ให้ตารางขยายและใช้พื้นที่ดิสก์อย่างมีประสิทธิภาพ ในทางกลับกัน การรวบรวมขยะที่เริ่มต้นอย่างกะทันหันทำให้เกิดภาระเพิ่มเติมบนดิสก์และตาราง ซึ่งทำให้เวลาในการดำเนินการแบบสอบถามเพิ่มขึ้น เอฟเฟกต์ที่คล้ายกันนี้ถูกสร้างขึ้นโดยการรวบรวมสถิติอัตโนมัติ (เห็นได้ชัดว่าสามารถเปิดใช้งานได้ด้วยคำสั่ง วิเคราะห์หรือร่วมกับการเก็บขยะ การวิเคราะห์สุญญากาศ). และแม้ว่า PostgreSQL จะปรับปรุงกลไกเหล่านี้จากเวอร์ชันหนึ่งไปอีกเวอร์ชันหนึ่งเพื่อลดขนาดลง อิทธิพลเชิงลบเกี่ยวกับประสิทธิภาพ (ตัวอย่างเช่นในเวอร์ชันก่อนหน้า การรวบรวมขยะบล็อกการเข้าถึงตารางอย่างสมบูรณ์ เนื่องจากเวอร์ชัน 9.0 ใช้งานได้ เครื่องดูดฝุ่นเร่งความเร็ว) มีบางอย่างที่ต้องกำหนดค่าที่นี่

คุณสามารถปิดการใช้งาน autovacuum ได้อย่างสมบูรณ์ด้วยพารามิเตอร์ต่อไปนี้:

เครื่องดูดฝุ่นอัตโนมัติ = ปิด

นอกจากนี้ เพื่อให้ Autovacuum ทำงาน จำเป็นต้องมีพารามิเตอร์ track_counts = on ไม่เช่นนั้นจะไม่ทำงาน

ตามค่าเริ่มต้น ตัวเลือกทั้งสองจะถูกเปิดใช้งาน ในความเป็นจริง ไม่สามารถปิดใช้งาน autovacuum ได้อย่างสมบูรณ์ - แม้ว่า autovacuum = ปิดอยู่ แต่บางครั้ง (หลังจากทำธุรกรรมจำนวนมาก) autovacuum จะเริ่มทำงาน

ความคิดเห็น: เครื่องดูดฝุ่นโดยปกติจะไม่ลดขนาดไฟล์ตาราง แต่จะทำเครื่องหมายเฉพาะพื้นที่ว่างที่สามารถนำกลับมาใช้ใหม่ได้ หากคุณต้องการเพิ่มพื้นที่ว่างส่วนเกินทางกายภาพและลดพื้นที่ว่างในดิสก์ให้เหลือน้อยที่สุด คุณจะต้องใช้คำสั่ง สูญญากาศเต็ม. ตัวเลือกนี้จะบล็อกการเข้าถึงตารางในขณะที่กำลังทำงานอยู่ และโดยทั่วไปไม่จำเป็น ข้อมูลเพิ่มเติมเกี่ยวกับการใช้คำสั่ง VACUUM มีอยู่ในเอกสารประกอบ (เป็นภาษาอังกฤษ)

หาก Autovacuum ไม่ได้ปิดใช้งานโดยสมบูรณ์ คุณสามารถกำหนดค่าอิทธิพลต่อการดำเนินการสืบค้นได้โดยใช้พารามิเตอร์ต่อไปนี้:

autovacuum_max_workers- จำนวนสูงสุดของกระบวนการทำความสะอาดที่ทำงานแบบขนาน

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

autovacuum_vacuum_threshold, - จำนวนบันทึกที่เปลี่ยนแปลงหรือถูกลบในตารางที่จำเป็นเพื่อกระตุ้นกระบวนการรวบรวมขยะ เครื่องดูดฝุ่นหรือการเก็บสถิติ วิเคราะห์. ค่าเริ่มต้นคือ 50

autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - ค่าสัมประสิทธิ์ขนาดตารางในบันทึกที่เพิ่มเข้าไป autovacuum_vacuum_thresholdและ autovacuum_analyze_thresholdตามลำดับ ค่าเริ่มต้นคือ 0.2 (เช่น 20% ของจำนวนบันทึก) และ 0.1 (10%) ตามลำดับ

ลองพิจารณาตัวอย่างด้วยตารางที่มี 10,000 เรคคอร์ด จากนั้น ด้วยการตั้งค่าเริ่มต้น หลังจาก 50+10000*0.1=1050 ระเบียนที่เปลี่ยนแปลงหรือถูกลบ การรวบรวมสถิติจะเริ่มต้นขึ้น วิเคราะห์และหลังปี 2050 การเปลี่ยนแปลง - การเก็บขยะ เครื่องดูดฝุ่น.

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

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

default_statistics_target - กำหนดจำนวนสถิติที่รวบรวมโดยคำสั่ง วิเคราะห์. ค่าเริ่มต้นคือ 100 ค่าที่มากขึ้นจะเพิ่มเวลาดำเนินการของคำสั่ง ANALYZE แต่อนุญาตให้ตัวกำหนดเวลาสร้างแผนการสืบค้นที่มีประสิทธิภาพมากขึ้น มีแนะนำให้เพิ่มเป็น 300.

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

Vacuum_cost_page_hit- ขนาดของ "ดี" สำหรับการประมวลผลบล็อกที่อยู่ใน shared_buffers เกี่ยวข้องกับความจำเป็นในการบล็อกการเข้าถึงบัฟเฟอร์ ค่าเริ่มต้น 1

Vacuum_cost_page_miss - ขนาดของ "ดี" สำหรับการประมวลผลบล็อกบนดิสก์ เกี่ยวข้องกับการบล็อกบัฟเฟอร์, ค้นหาข้อมูลในบัฟเฟอร์, อ่านข้อมูลจากดิสก์ ค่าเริ่มต้น 10

Vacuum_cost_page_dirty- ขนาดของ "ละเอียด" สำหรับการแก้ไขบล็อก เกี่ยวข้องกับความจำเป็นในการรีเซ็ตข้อมูลที่แก้ไขลงดิสก์ ค่าเริ่มต้น 20

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

สูญญากาศ_ต้นทุน_ล่าช้า- ถึงเวลา “หยุด” กระบวนการรวบรวมขยะเมื่อถึง Vacuum_cost_limit ค่าเริ่มต้น 0ms

autovacuum_vacuum_cost_delay- ถึงเวลา “แช่แข็ง” กระบวนการเก็บขยะสำหรับเครื่องดูดฝุ่นอัตโนมัติ ค่าเริ่มต้นคือ 20ms หากตั้งค่าเป็น -1 ระบบจะใช้ค่า Vacuum_cost_delay

autovacuum_vacuum_cost_limit- ขนาดสูงสุดของ "ละเอียด" สำหรับเครื่องดูดฝุ่นอัตโนมัติ ค่าเริ่มต้น -1 - ใช้ค่า Vacuum_cost_limit

รายงานการใช้งาน Vacuum_cost_page_hit = 6, Vacuum_cost_limit = 100, autovacuum_vacuum_cost_delay = 200ms ลดผลกระทบของ AUTOVACUUM ได้ถึง 80% แต่เพิ่มเวลาในการดำเนินการเป็นสามเท่า

การตั้งค่าการบันทึกดิสก์

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

ในระบบไม่ว่างซึ่งมีวอลุ่มการเขียนขนาดใหญ่ การย้ายบันทึกธุรกรรมไปยังดิสก์ที่แยกจากกันอาจเป็นเรื่องที่เหมาะสม (แต่ไม่ใช่ไปยังพาร์ติชันอื่นของดิสก์เดียวกัน!) เมื่อต้องการทำเช่นนี้ คุณต้องหยุด DBMS ย้ายไดเร็กทอรี pg_xlog ไปยังตำแหน่งอื่น และสร้างลิงก์สัญลักษณ์ในตำแหน่งเก่า ตัวอย่างเช่น การใช้ยูทิลิตีการเชื่อม Far Manager (Alt-F6) สามารถสร้างลิงก์ได้เช่นกัน ในกรณีนี้ คุณต้องตรวจสอบให้แน่ใจว่าตำแหน่งใหม่มีสิทธิ์การเข้าถึงสำหรับผู้ใช้ที่ใช้ PostgreSQL (โดยปกติคือ postgres)

หากมีการดำเนินการแก้ไขข้อมูลจำนวนมาก คุณอาจต้องเพิ่มค่า checkpoint_segments ซึ่งจะควบคุมปริมาณข้อมูลที่สามารถรอการถ่ายโอนจากบันทึกไปยังฐานข้อมูลได้ ค่าเริ่มต้นคือ 3 ควรคำนึงว่ามีการจัดสรรพื้นที่สำหรับบันทึกโดยคำนวณโดยสูตร (checkpoint_segments * 2 + 1) * 16 MB ซึ่งด้วยค่า 32 จะต้องใช้ดิสก์มากกว่า 1 GB อยู่แล้ว ช่องว่าง.

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

fsync=ปิด
full_page_writes = ปิด

ซึ่งสามารถทำได้ก็ต่อเมื่อคุณเชื่อถืออุปกรณ์และ UPS 100% (ที่มา แหล่งจ่ายไฟสำรอง). มิฉะนั้นในกรณีที่ระบบล่มก็มีความเสี่ยงที่ฐานข้อมูลจะถูกทำลาย และไม่ว่าในกรณีใดตัวควบคุม RAID ที่มีแบตเตอรี่สำหรับจ่ายไฟให้กับหน่วยความจำของข้อมูลที่ยังไม่ได้เขียนก็จะไม่เสียหายเช่นกัน

ทางเลือกอื่นที่แน่นอนอาจเป็นการใช้พารามิเตอร์

synchronous_commit = ปิด

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

หากคุณไม่ปิดใช้งาน fsync อย่างสมบูรณ์ คุณสามารถระบุวิธีการซิงโครไนซ์ในพารามิเตอร์ได้ บทความจากดิสก์ ITS อ้างถึงยูทิลิตี้ pg_test_fsync แต่ไม่พบในบิลด์ PostgreSQL ของฉัน ตาม 1C ในกรณีของพวกเขาใน Windows วิธีการดังกล่าวแสดงให้เห็นว่าเหมาะสมที่สุด open_datasync(เห็นได้ชัดว่านี่เป็นวิธีการที่ใช้เป็นค่าเริ่มต้น)

หากใช้ธุรกรรมการเขียนขนาดเล็กจำนวนมาก (ในกรณีของ 1C นี่อาจเป็นการอัปเดตไดเร็กทอรีจำนวนมากที่อยู่นอกธุรกรรม) การรวมกันของพารามิเตอร์ commit_delay (เวลาหน่วงเวลาเสร็จสิ้นธุรกรรมในหน่วยไมโครวินาที ค่าเริ่มต้น 0) และ commit_siblings (ค่าเริ่มต้น 5) สามารถช่วย. เมื่อเปิดใช้งานตัวเลือก การทำธุรกรรมให้เสร็จสิ้นอาจล่าช้าโดย commit_delay ถ้า ช่วงเวลานี้มีการดำเนินการธุรกรรม commit_siblings เป็นอย่างน้อย ในกรณีนี้ ผลลัพธ์ของธุรกรรมที่เสร็จสมบูรณ์ทั้งหมดจะถูกเขียนร่วมกันเพื่อเพิ่มประสิทธิภาพการเขียนดิสก์

พารามิเตอร์อื่นๆ ที่ส่งผลต่อประสิทธิภาพการทำงาน

wal_buffers- จำนวนหน่วยความจำใน shared_buffers สำหรับการเก็บบันทึกธุรกรรม คำแนะนำ: ด้วยหน่วยความจำที่มีอยู่ 1-4GB ให้ใช้ค่า 256KB-1MB เอกสารระบุว่าการใช้ค่า "-1" จะปรับค่าโดยอัตโนมัติขึ้นอยู่กับค่าของ shared_buffers

Random_page_cost- “ต้นทุน” ของการอ่านแบบสุ่ม ใช้ในการค้นหาข้อมูลโดยใช้ดัชนี ค่าเริ่มต้นคือ 4.0 หน่วยคือเวลาของการเข้าถึงข้อมูลตามลำดับ สำหรับดิสก์อาร์เรย์ที่รวดเร็ว โดยเฉพาะ SSD ควรลดค่าลง ในกรณีนี้ PostgreSQL จะใช้ดัชนีที่ใช้งานมากขึ้น

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

ขอแนะนำให้เปลี่ยนพารามิเตอร์จากส่วน QUERY TUNING โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับการห้ามไม่ให้ตัวกำหนดตารางเวลาใช้วิธีการค้นหาเฉพาะ เฉพาะในกรณีที่คุณมีความเข้าใจอย่างถ่องแท้ถึงสิ่งที่คุณกำลังทำอยู่ เป็นเรื่องง่ายมากที่จะเพิ่มประสิทธิภาพแบบสอบถามประเภทหนึ่งและทำลายประสิทธิภาพของแบบสอบถามประเภทอื่นๆ ทั้งหมด ประสิทธิผลของการเปลี่ยนพารามิเตอร์ส่วนใหญ่ในส่วนนี้ขึ้นอยู่กับข้อมูลในฐานข้อมูล การสืบค้นข้อมูลนี้ (เช่น เวอร์ชันของ 1C ที่ใช้ และอื่นๆ) และเวอร์ชันของ DBMS

บทสรุป

PostgreSQL เป็น DBMS ที่ทรงพลังในมือที่มีความสามารถ แต่ต้องมีการกำหนดค่าอย่างระมัดระวัง สามารถใช้ร่วมกับ 1C และได้รับประสิทธิภาพที่เหมาะสม และลักษณะอิสระของมันจะเป็นโบนัสที่ดีมาก

ยินดีวิจารณ์และเพิ่มเติมบทความนี้

ลิงค์ที่เป็นประโยชน์

http://postgresql.leopard.in.ua/ - เว็บไซต์หนังสือ " การทำงานกับการกำหนดค่าและการปรับขนาด PostgreSQL " ในความคิดของฉัน คำแนะนำที่สมบูรณ์และเข้าใจได้มากที่สุดสำหรับการกำหนดค่าและการจัดการ PostgreSQL

http://etersoft.ru/products/postgre - ที่นี่คุณสามารถดาวน์โหลด PostgreSQL รุ่นที่รองรับ 1C สำหรับ Windows และ Linux รุ่นต่างๆ และรุ่นต่างๆ สำหรับผู้ที่ไม่ได้สมัครสมาชิก ITS หรือต้องการเวอร์ชันสำหรับ เวอร์ชันลินุกซ์ซึ่งไม่ได้นำเสนอบน v8.1c.ru

http://www.postgresql.org/docs/9.2/static/ - เอกสารอย่างเป็นทางการเกี่ยวกับ PostgreSQL (เป็นภาษาอังกฤษ)

บทความจากดิสก์ ITS เกี่ยวกับการตั้งค่า PostgreSQL

ประวัติการแก้ไขบทความ

• 29/01/2558 - เผยแพร่เวอร์ชันเริ่มต้น
• 31/01/2558 - บทความนี้ได้รับการเสริมด้วยหัวข้อเกี่ยวกับ AUTOVACUUM โดยมีการเพิ่มลิงก์ไปยังเอกสารต้นฉบับ

ในอนาคตผมตั้งใจที่จะทดสอบการทำงานของ DBMS ในโหมดการเพิ่มและการเปลี่ยนแปลงข้อมูล

เราจะติดตั้งชุดประกอบจากบริษัท Postgres Professional ในหน้าที่มีเวอร์ชันสำหรับ 1C:Enterprise เราจะค้นหาข้อมูลเกี่ยวกับการติดตั้ง PostgreSQL เวอร์ชันล่าสุดบน CentOS 7

มาเชื่อมต่อที่เก็บข้อมูลและติดตั้ง PostgreSQL 9.6:

Sudo rpm -ivh http://1c.postgrespro.ru/keys/postgrespro-1c-centos96.noarch.rpm sudo yum makecache sudo yum ติดตั้ง postgresql-pro-1c-9.6

การตั้งค่า PostgreSQL ขั้นพื้นฐาน

เราเริ่มต้นฐานข้อมูลบริการด้วยการแปลภาษารัสเซีย:

Su postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data --locale=ru_RU.UTF-8 บริการออก postgresql-9.6 initdb

เริ่มบริการ PostgreSQL และเพิ่มลงในการเริ่มต้น:

Systemctl เปิดใช้งาน postgresql-9.6 systemctl เริ่มต้น postgresql-9.6 สถานะ systemctl postgresql-9.6

เราตั้งรหัสผ่านสำหรับผู้ใช้ postgres เพื่อให้สามารถเชื่อมต่อกับเซิร์ฟเวอร์จากระยะไกล:

Su - postgres psql เปลี่ยนผู้ใช้ postgres ด้วยรหัสผ่านที่เข้ารหัส "รหัสผ่านของคุณ"; \q ออก

Mcedit /var/lib/pgsql/9.6/data/pg_hba.conf

ในไฟล์ที่เปิดขึ้น ไม่แสดงข้อคิดเห็น และเปลี่ยนบรรทัด:

โฮสต์ทั้งหมด 127.0.0.1/32 ident บน โฮสต์ทั้งหมด 127.0.0.1/32 md5

โฮสต์ทั้งหมด 0.0.0.0/0 ident บน โฮสต์ทั้งหมด 0.0.0.0/0 md5

การเพิ่มประสิทธิภาพการตั้งค่า PostgreSQL (postgresql.conf) สำหรับ 1C: Enterprise

ต่อไปนี้คือการตั้งค่าสำหรับ PostgreSQL ที่ทำงานบนเครื่องเสมือน ESXi 6.5

ทรัพยากรที่จัดสรรสำหรับ VM:

โปรเซสเซอร์ - 8 vCPU;

หน่วยความจำ - 48GB;

ดิสก์สำหรับ OS - 50 GB บนฮาร์ดแวร์ LUN RAID1 จาก SAS HDD

ดิสก์สำหรับฐานข้อมูล - 170 GB บนซอฟต์แวร์ RAID1 จาก SSD

ดิสก์สำหรับบันทึก - 100 GB บนซอฟต์แวร์ RAID1 จาก SSD

หากต้องการแก้ไขการตั้งค่า ให้รันคำสั่ง:

Mcedit /var/lib/pgsql/9.6/data/postgresql.conf

ใส่ความเห็นไว้ว่าพารามิเตอร์ที่เราจะเปลี่ยนแปลงจะต้องเปิดใช้งาน

ซีพียู

autovacuum_max_workers = 4

autovacuum_max_workers = NCores/4..2 แต่ไม่น้อยกว่า 4

จำนวนกระบวนการดูดอัตโนมัติ กฎทั่วไปคือ ยิ่งมีการร้องขอการเขียนมากเท่าใด กระบวนการก็จะยิ่งมากขึ้นเท่านั้น บนฐานข้อมูลแบบอ่านอย่างเดียว กระบวนการเดียวก็เพียงพอแล้ว

ssl=ปิด

ปิดการเข้ารหัส สำหรับศูนย์ข้อมูลที่ปลอดภัย การเข้ารหัสไม่มีความหมาย แต่ส่งผลให้มีภาระงาน CPU เพิ่มขึ้น

หน่วยความจำ

shared_buffers = 12GB

shared_buffers = RAM/4

จำนวนหน่วยความจำที่จัดสรรโดย PgSQL สำหรับแคชเพจที่ใช้ร่วมกัน หน่วยความจำนี้ถูกใช้ร่วมกันระหว่างกระบวนการ PgSQL ทั้งหมด ระบบปฏิบัติการโดยจะแคชข้อมูลเอง ดังนั้นจึงไม่จำเป็นต้องจัดสรร RAM ที่มีอยู่ทั้งหมดสำหรับแคช

temp_buffers = 256MB

จำนวนหน้าสูงสุดสำหรับตารางชั่วคราว เหล่านั้น. นี่คือขีดจำกัดบนของขนาดของตารางชั่วคราวในแต่ละเซสชัน

work_mem = 64MB

work_mem = RAM/32..64 หรือ 32MB..128MB

ขีดจำกัดหน่วยความจำสำหรับการประมวลผลหนึ่งคำขอ หน่วยความจำนี้เป็นรายบุคคลสำหรับแต่ละเซสชัน ตามทฤษฎีแล้ว หน่วยความจำสูงสุดที่ต้องการจะเท่ากับ max_connections * work_mem ในทางปฏิบัติสิ่งนี้จะไม่เกิดขึ้นเนื่องจากเซสชันส่วนใหญ่จะรอเกือบตลอดเวลา เครื่องมือเพิ่มประสิทธิภาพใช้ค่าคำแนะนำนี้ โดยจะพยายามคาดการณ์ขนาดของหน่วยความจำที่ต้องการสำหรับการสืบค้น และหากค่านี้มากกว่า work_mem ก็จะแจ้งให้ผู้ดำเนินการสร้างตารางชั่วคราวทันที work_mem ไม่ใช่ข้อจำกัดในความหมายทั้งหมด: เครื่องมือเพิ่มประสิทธิภาพอาจพลาด และคำขอจะใช้หน่วยความจำมากขึ้น หรืออาจมากกว่านั้นหลายเท่า ค่านี้สามารถลดลงได้โดยการตรวจสอบจำนวนไฟล์ชั่วคราวที่สร้างขึ้น:

การบำรุงรักษา_งาน_mem = 2GB

Maintenance_work_mem = RAM/16..32 หรือ work_mem * 4 หรือ 256MB..4GB

ขีดจำกัดหน่วยความจำสำหรับงานบำรุงรักษา เช่น การรวบรวมสถิติ (วิเคราะห์) การรวบรวมขยะ (VACUUM) การสร้างดัชนี (สร้างดัชนี) และการเพิ่มคีย์นอก ขนาดของหน่วยความจำที่จัดสรรสำหรับการดำเนินการเหล่านี้ควรเทียบเคียงได้กับ ขนาดทางกายภาพดัชนีที่ใหญ่ที่สุดบนดิสก์

Efficient_cache_size = 36GB

Effic_cache_size = RAM - shared_buffers

การประมาณขนาดแคชของระบบไฟล์ การเพิ่มพารามิเตอร์จะเพิ่มแนวโน้มของระบบในการเลือกแผน IndexScan และนี่เป็นสิ่งที่ดี

แผ่นดิสก์

Efficiency_io_concurrency = 5

การประมาณคำร้องขอพร้อมกันไปยังระบบดิสก์ที่สามารถให้บริการได้ในคราวเดียว สำหรับดิสก์เดียว = 1 สำหรับ RAID - 2 หรือมากกว่า

Random_page_cost = 1.3

Random_page_cost = 1.5-2.0 สำหรับ RAID, 1.1-1.3 สำหรับ SSD

ค่าใช้จ่ายในการอ่านหน้าสุ่ม (ค่าเริ่มต้น 4) ยิ่งเวลาค้นหาของระบบดิสก์น้อยลง พารามิเตอร์นี้ควรมีขนาดเล็กลง (แต่ > 1.0) ค่าพารามิเตอร์ที่มีขนาดใหญ่เกินไปจะเพิ่มแนวโน้มของ PgSQL ในการเลือกแผนที่จะสแกนทั้งตาราง (PgSQL ถือว่าการอ่านทั้งตารางตามลำดับนั้นถูกกว่าการอ่านดัชนีแบบสุ่ม) และนั่นก็แย่

เครื่องดูดฝุ่นอัตโนมัติ=เปิด

กำลังเปิดเครื่องดูดอัตโนมัติ

autovacuum_naptime = 20 วินาที

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

bgwriter_delay = 20ms

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

bgwriter_lru_multiplier = 4.0

bgwriter_lru_maxpages = 400

ตัวเลือกที่ควบคุมความเข้มของการบันทึกของกระบวนการบันทึกเบื้องหลัง ในรอบหนึ่ง bgwriter เขียนไม่เกินสิ่งที่เขียนในรอบที่แล้ว คูณด้วย bgwriter_lru_multiplier แต่ไม่เกิน bgwriter_lru_maxpages

synchronous_commit = ปิด

ปิดใช้งานการซิงโครไนซ์ดิสก์ ณ เวลาที่กระทำ สร้างความเสี่ยงในการสูญเสียธุรกรรมสองสามรายการล่าสุด (ภายใน 0.5-1 วินาที) แต่รับประกันความสมบูรณ์ของฐานข้อมูล ไม่มีช่องว่างในห่วงโซ่การคอมมิต แต่มันเพิ่มผลผลิตอย่างมาก

wal_keep_segments = 256

wal_keep_segments = 32..256

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

wal_buffers = 16 เมกะไบต์

จำนวนหน่วยความจำที่ใช้ร่วมกันที่จะใช้เพื่อบัฟเฟอร์ข้อมูล WAL ที่ยังไม่ได้เขียนลงดิสก์ ค่าเริ่มต้น -1 ระบุขนาดเท่ากับ 1/32 (ประมาณ 3%) ของ แต่ไม่น้อยกว่า 64 KB และไม่เกินขนาดของเซ็กเมนต์ WAL เดียว (ปกติคือ 16 MB) ค่านี้สามารถตั้งค่าด้วยตนเองได้หากค่าที่เลือกโดยอัตโนมัติมีขนาดเล็กหรือใหญ่เกินไป แต่จำนวนบวกใดๆ ที่น้อยกว่า 32 KB จะถือเป็น 32 KB พารามิเตอร์นี้สามารถตั้งค่าได้เมื่อเริ่มต้นเซิร์ฟเวอร์เท่านั้น

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

default_statistics_target = 1,000

ตั้งค่าขีดจำกัดเป้าหมายสถิติเริ่มต้นที่ใช้กับคอลัมน์ที่ ALTER TABLE SET STATISTICS ไม่ได้ระบุขีดจำกัดแต่ละรายการ ยิ่งชุดค่าสูงเท่าไร การรัน ANALYZE ก็ยิ่งใช้เวลานานขึ้นเท่านั้น แต่คุณภาพของการประมาณการของผู้จัดกำหนดการก็จะยิ่งสูงขึ้นเท่านั้น ค่าเริ่มต้นสำหรับพารามิเตอร์นี้คือ 100

จุดตรวจ_สมบูรณ์_เป้าหมาย = 0.9

ระดับ “รอยเปื้อน” ของด่านตรวจ ความเร็วในการบันทึกระหว่างจุดตรวจจะถูกปรับเพื่อให้เวลาจุดตรวจเท่ากับเวลาที่ผ่านไปนับตั้งแต่อดีต คูณด้วยเป้าหมายจุดตรวจสอบ_สมบูรณ์

min_wal_size = 4G
max_wal_size = 8G

min_wal_size = 512MB .. 4G
max_wal_size = 2 * min_wal_size

ขนาดไฟล์ WAL ขั้นต่ำและสูงสุด คล้ายกับ checkpoint_segments

fsync=เปิด

การปิดใช้งานตัวเลือกส่งผลให้ประสิทธิภาพเพิ่มขึ้น แต่มีความเสี่ยงอย่างมากที่จะสูญเสียข้อมูลทั้งหมดหากปิดเครื่องกะทันหัน ข้อควรพิจารณา: หาก RAID มีแคชและอยู่ในโหมดเขียนกลับ ให้ตรวจสอบการมีอยู่และการทำงานของแบตเตอรี่แคชตัวควบคุม RAID! มิฉะนั้น ข้อมูลที่เขียนลงในแคช RAID อาจสูญหายเมื่อปิดเครื่อง และด้วยเหตุนี้ PgSQL จึงไม่รับประกันความสมบูรณ์ของข้อมูล

row_security = ปิด

ปิดใช้งานการควบคุมความละเอียดระดับบันทึก

Enable_nestloop = ปิด

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

ล็อค

max_locks_per_transaction = 256

จำนวนสูงสุดของการล็อคดัชนี/ตารางในหนึ่งธุรกรรม

การตั้งค่าสำหรับแพลตฟอร์ม 1C

standard_conforming_strings = ปิด

อนุญาตให้ใช้อักขระ \ เพื่อหลบหนี

Escape_string_warning = ปิด

อย่าเตือนเกี่ยวกับการใช้อักขระ \ ในการหลบหนี

ตั้งค่าความปลอดภัย

ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ PostgreSQL มองเห็นได้เฉพาะกับเซิร์ฟเวอร์ 1C: Enterprise ที่ติดตั้งบนเครื่องเดียวกัน

Listen_addresses = 'localhost'

หากติดตั้งเซิร์ฟเวอร์ 1C: Enterprise บนเครื่องอื่นหรือจำเป็นต้องเชื่อมต่อกับเซิร์ฟเวอร์ DBMS โดยใช้สแน็ปอิน PGAdmin แทน โลคัลโฮสต์ คุณต้องระบุที่อยู่ของเครื่องนี้

การจัดเก็บฐานข้อมูล

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

การหยุดเซิร์ฟเวอร์

Systemctl หยุด postgresql-9.6.1

เราถ่ายโอนบันทึกไปยัง SSD ขนาด 120GB:

Mv /var/lib/pgsql/9.6/data/pg_xlog /raid120 mv /var/lib/pgsql/9.6/data/pg_clog /raid120 mv /var/lib/pgsql/9.6/data/pg_log /raid120

Ln -s /raid120/pg_xlog /var/lib/pgsql/9.6/data/pg_xlog ln -s /raid120/pg_clog /var/lib/pgsql/9.6/data/pg_clog ln -s /raid120/pg_log /var/lib/ pgsql/9.6/data/pg_log

เราจะถ่ายโอนไดเร็กทอรีด้วยฐานข้อมูล:

Mv /var/lib/pgsql/9.6/data/base /raid200

Ln -s /raid200/base /var/lib/pgsql/9.6/data/base

มาเริ่มเซิร์ฟเวอร์และตรวจสอบสถานะกันดีกว่า

Systemctl เริ่ม postgresql-9.6 สถานะ systemctl postgresql-9.6

ใช้ case เป็นเซิร์ฟเวอร์ฐานข้อมูล PostgreSQL แพลตฟอร์มหน้าต่างไม่เป็นที่นิยมมากนัก แต่มักเกิดขึ้นเมื่อคุณต้องการประหยัดเงินในผลิตภัณฑ์จาก MS นอกจากนี้ยังมีแอปพลิเคชันพิเศษที่ทำงานได้ดีที่สุดกับ PostgreSQL สำหรับ 1c มี PostgreSQL บิลด์ที่ได้รับการแก้ไข ซึ่งตามที่นักพัฒนารับประกัน จะให้ระดับประสิทธิภาพและความทนทานต่อข้อผิดพลาดที่เทียบได้กับ MSSQL เป็นเช่นนั้นจริงหรือ เรามาตรวจสอบในทางปฏิบัติกัน :)

1. ติดตั้ง PostgreSQL

ดาวน์โหลด PostgreSQL 64 บิต 9.1.2-1.1C รุ่นล่าสุดจากเว็บไซต์ 1c แตกไฟล์เก็บถาวร เรียกใช้แพ็คเกจ msi ไฟล์ที่ไม่มี int จะมีขนาดไฟล์ไม่ใหญ่

คลิกเริ่ม
ปล่อยให้ตัวเลือกการติดตั้งเป็นค่าเริ่มต้น

ตั้งรหัสผ่านสำหรับผู้ใช้ โพสต์เกรสซึ่งจะเริ่มให้บริการ . คลิกถัดไป หากคุณกำลังติดตั้ง PostgreSQL เป็นครั้งแรก วิซาร์ดจะแจ้งให้คุณสร้างผู้ใช้ โพสต์เกรส

ในขั้นตอนของการเริ่มต้นฐานข้อมูล ให้เลือกการเข้ารหัส UTF8 ตั้งค่าล็อกอินและรหัสผ่านสำหรับผู้ใช้ postgres ภายใน ความสนใจ! รหัสผ่านผู้ใช้บริการ PostgreSQL และรหัสผ่านผู้ใช้ฐานข้อมูล PostgreSQL ภายในจะต้องไม่เหมือนกัน รหัสผ่านต้องมีความยาวอย่างน้อยสี่ตัวอักษร หากคุณวางแผนที่จะใช้งานเซิร์ฟเวอร์ 1C และ PostgreSQL บนเครื่องที่แตกต่างกัน คุณจะต้องกาเครื่องหมายที่ช่อง “รองรับการเชื่อมต่อจาก IP ใดๆ ไม่ใช่แค่ localhost” คลิกถัดไปและถัดไปอีกครั้ง :)

คลิกถัดไปอีกสองครั้งและรอให้การติดตั้งเสร็จสิ้น

จากนั้นไปที่ Start\All Programs\PostgreSQL 9.1.2-1.1C(x64) เรียกใช้ยูทิลิตีการดูแลระบบ pgAdmin III เรามาลองเชื่อมต่อกับฐานข้อมูลกัน ป้อนรหัสผ่านที่คุณระบุระหว่างการติดตั้ง
และเราได้รับข้อผิดพลาดต่อไปนี้: เกิดข้อผิดพลาดในการเชื่อมต่อกับเซิร์ฟเวอร์: FATAL: การตรวจสอบรหัสผ่านล้มเหลวสำหรับผู้ใช้ "postgres"

ค่อนข้างไม่คาดคิดเมื่อพิจารณาว่ารหัสผ่านถูกพิมพ์ถูกต้อง ฉันตัดสินใจที่จะคนจรจัดด้วย pg_hba.conf แต่เมื่อมองแวบแรกทุกอย่างก็เรียบร้อยดี

# ประเภทวิธีที่อยู่ผู้ใช้ฐานข้อมูล # การเชื่อมต่อภายใน IPv4: โฮสต์ postgres ทั้งหมด::1/128 md5 โฮสต์ postgres ทั้งหมด 127.0.0.1/32 md5 โฮสต์ postgres ทั้งหมด 192.168.1.0/24 md5

ฉันตัดสินใจเปลี่ยนวิธีการอนุญาตจาก md5 เป็นความเชื่อถือ ฉันเริ่มบริการใหม่แล้วลองเชื่อมต่อกับฐานข้อมูลอีกครั้ง คราวนี้ฉันได้รับข้อความนี้
อันที่จริง มีมากกว่าหนึ่งรายการบนเว็บไซต์ pgAdmin เวอร์ชันใหม่. แล้วเชื่อมต่อฐานข้อมูลได้สำเร็จ!!?!! ฉันจำได้ว่าก่อนหน้านี้ md5 ไม่ได้ทำให้เกิดปัญหาดังกล่าว แต่เห็นได้ชัดว่าข้อผิดพลาดนี้เกี่ยวข้องกันจริงๆ เวอร์ชั่นเก่า pgAdmin.
ตอนนี้เราสามารถสร้างฐานข้อมูลสำหรับความต้องการของ 1C หรือใช้ 1C เองก็ได้ :)

2. การติดตั้ง 1C องค์กร 8.2

สำหรับการติดตั้ง เราสังเกตส่วนประกอบต่อไปนี้: 1C:Enterprise, 1C:Enterprise Server, โมดูลส่วนขยายเว็บเซิร์ฟเวอร์, 1C:Enterprise การดูแลเซิร์ฟเวอร์
ในขั้นตอนการติดตั้ง "ติดตั้ง 1C Enterprise as a Service" เราตั้งรหัสผ่านสำหรับผู้ใช้ USR1C82
คลิกถัดไปและติดตามความคืบหน้าการติดตั้ง :) ถึงผู้ใช้ USR1CV82ต้องกำหนดสิทธิ์ต่อไปนี้ระหว่างการติดตั้ง:

เข้าสู่ระบบเป็นบริการ (เข้าสู่ระบบเป็นบริการ)เข้าสู่ระบบเป็นงานแบทช์ (เข้าสู่ระบบเป็นงานแบทช์) สามารถดูได้ที่ คอมพิวเตอร์เฉพาะที่ Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Right Assignments

มาดูอุปกรณ์กัน การดูแลเซิร์ฟเวอร์ 1C Enterpriseเราเห็นว่าคลัสเตอร์เพิ่มขึ้นและค้างอยู่ที่พอร์ต 1541 เซิร์ฟเวอร์ของเรายังปรากฏอยู่ในแท็บ "เซิร์ฟเวอร์ที่ใช้งานได้" ตอนนี้คุณสามารถเพิ่มฐานข้อมูลไปยังเซิร์ฟเวอร์ 1C ได้ โดยไปที่แท็บ “ ฐานข้อมูล"คลิกขวาแล้วเลือก ใหม่ - ฐานข้อมูล. ตั้งค่าพารามิเตอร์ที่จำเป็นเพื่อเชื่อมต่อกับเซิร์ฟเวอร์ PostgreSQL คลิกตกลง มาเปิดตัว 1C: Enterprise กันเถอะ เราเลือกที่จะเพิ่มฐานข้อมูลที่มีอยู่บนเซิร์ฟเวอร์
จากนั้นตั้งค่าพารามิเตอร์การเชื่อมต่อ คลิก "ถัดไป" และสุดท้าย "เสร็จสิ้น"
การดำเนินการสร้างฐานข้อมูลสามารถทำได้โดยตรงจาก 1C: Enterprise เมื่อต้องการทำเช่นนี้ เมื่อเริ่มต้น ให้เลือก "สร้างใหม่" ฐานข้อมูล».

ในการเชื่อมต่อไคลเอนต์ 1C กับเซิร์ฟเวอร์จากภายนอกและใช้งานเซิร์ฟเวอร์ฐานข้อมูลบนไฟร์วอลล์จะต้องเปิดพอร์ตต่อไปนี้:

ตัวแทนเซิร์ฟเวอร์ ( ตัวแทน) - tcp:1540 หัวหน้าผู้จัดการคลัสเตอร์ ( RMNGR) - tcp:1541 ช่วงของพอร์ตเครือข่ายสำหรับการกระจายกระบวนการของผู้ปฏิบัติงานแบบไดนามิก - tcp:1560-1591, tcp:5432 - Postgresql มาสร้างกฎผ่านอินเทอร์เฟซมาตรฐานหรือใช้คำสั่ง:

ไฟร์วอลล์ advfirewall netsh เพิ่มชื่อกฎ = "1Cv8-Server" dir = ในการกระทำ = อนุญาตโปรโตคอล = TCP localport = 1540,1541,5432,1560-1590 เปิดใช้งาน = ใช่โปรไฟล์ = ระยะไกลใด ๆ = ประเภทอินเทอร์เฟซใด ๆ = LAN

ตอนนี้เราสามารถเปิดไคลเอนต์ 1C:Enterprise จากคอมพิวเตอร์เครื่องอื่นและเพิ่มฐานข้อมูลที่มีอยู่ได้อย่างง่ายดาย ใหม่db. อย่าลืมเกี่ยวกับใบอนุญาตและการปกป้องซอฟต์แวร์/ฮาร์ดแวร์ ตอนนี้เราสามารถดาวน์โหลดการทดสอบ Gilev และวัดประสิทธิภาพของระบบของเราได้แล้ว

บน VirtualBox ที่มีหน่วยความจำ 1GB, Dual-Core 2.6 GHz, 319-release 1c การทดสอบ Gilev ให้ 11.42 คะแนน ซึ่งใกล้เคียงกับบน CentOS ที่ 16.362 มีมากกว่า 11.60 จุดเล็กน้อย การปรับการตั้งค่าให้เหมาะสมโดยใช้ EnterpriseDB Tuning Wizard ไม่ได้เพิ่มขึ้นอย่างเห็นได้ชัด (11.66 และ 11.62) แม้ว่าโดยทั่วไปอาจเป็นประโยชน์ก็ตาม :)

3. งานประจำบนเซิร์ฟเวอร์ PostgreSQL

สำรองข้อมูล

เปิดยูทิลิตี้การดูแลระบบ pgAdmin III และคลิกขวาที่ฐานข้อมูลที่ต้องการ เลือก "สำรองข้อมูล"
เลือกรูปแบบ (กำหนดเอง (ระดับการบีบอัดตั้งแต่ 0 ถึง 9), Tar, แบบธรรมดา, แค็ตตาล็อก) ในแง่ของระดับการบีบอัด “รูปแบบที่กำหนดเอง” ของระดับการบีบอัดใด ๆ จะบีบอัดได้ดีที่สุด ตามด้วย “ไดเร็กทอรี” จากนั้น “ธรรมดา” และสุดท้ายคือ “tar” เราระบุการเข้ารหัส UTF8 ชื่อบทบาทคือ postgresql เราปล่อยให้ตัวเลือกเพิ่มเติมทั้งหมดเป็นค่าเริ่มต้น คลิกปุ่ม "สำรองข้อมูล" ช่อง "ข้อความ" จะแสดงรายการการดำเนินการที่ดำเนินการทั้งหมดพร้อมรหัสที่สมบูรณ์ ถ้า 0 แสดงว่าสำเร็จ คุณสามารถดูวิธีเรียกใช้การดำเนินการที่คล้ายกันได้จากบรรทัดคำสั่งที่นี่

F)\pgAdmin III\1.16\pg_dump.exe" --โฮสต์ 192.168.1.200 --พอร์ต 5432 --ชื่อผู้ใช้ "postgres" --role "postgres" --ไม่มีรหัสผ่าน --รูปแบบที่กำหนดเอง --blobs --compress 9 --การเข้ารหัส UTF8 --verbose --file "G:\Backups\gilev_dump.backup" "newdb"

ตามสคริปต์อัตโนมัติ สำเนาสำรองซึ่งเราเพิ่มลงในตัวกำหนดเวลาอาจมีลักษณะดังนี้:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --username "postgres" --role "postgres" --no-password --format กำหนดเอง --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump_%date:~0.2%_%date:~3.2%_%date:~6.4% .backup" "newdb"

การกู้คืน.

หากต้องการกู้คืน ให้เลือกฐานข้อมูลที่เราต้องการกู้คืนข้อมูล สำเนาสำรองเว้นว่างไว้จะดีกว่า คลิกขวาและเลือก "การกู้คืน" ตั้งค่าไฟล์สำรองข้อมูล ชื่อบทบาท: postgres คลิก “กู้คืน”
การใช้บรรทัดคำสั่ง:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_restore.exe" --โฮสต์ 192.168.1.200 --พอร์ต 5432 --ชื่อผู้ใช้ "postgres" --dbname "testdb" --role "postgres" --no -รหัสผ่าน --verbose "G:\Backups\gilev_dump_26_09_2012.backup"

โดยที่ testdb เป็นฐานข้อมูลว่างซึ่งมีการกู้คืนไฟล์เก็บถาวรสำรอง

การดำเนินการบำรุงรักษา:

คำสั่งสูญญากาศ:

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

เครื่องดูดฝุ่น— ทำเครื่องหมายพื้นที่ว่างในบันทึกเวอร์ชันเก่าว่าว่าง ตามกฎแล้วการใช้คำสั่งรูปแบบนี้จะไม่ลดขนาดของไฟล์ที่มีตาราง แต่ช่วยให้คุณป้องกันไม่ให้มันขยายใหญ่ขึ้นอย่างควบคุมไม่ได้โดยแก้ไขในระดับที่ยอมรับได้ เมื่อเรียกใช้ VACUUM สามารถเข้าถึงตารางที่กำลังประมวลผลแบบขนานได้ มีหลายอย่าง ตัวเลือกเพิ่มเติมการใช้สุญญากาศ: สุญญากาศเต็ม, แช่แข็งสุญญากาศ, วิเคราะห์สุญญากาศ

สูญญากาศเต็มพยายามลบเร็กคอร์ดเวอร์ชันเก่าทั้งหมด และลดขนาดของไฟล์ที่มีตาราง ตัวเลือกคำสั่งนี้จะล็อคตารางที่กำลังประมวลผลอย่างสมบูรณ์

แช่แข็งสูญญากาศ -หาก VACUUM FULL ลบ "ขยะ" ออกจากตารางและย้ายบันทึกเพื่อให้ตารางอยู่ในตำแหน่งที่กะทัดรัดบนดิสก์และประกอบด้วยแฟรกเมนต์จำนวนน้อยที่สุด ในขณะที่การบีบอัดใช้เวลานานและบล็อกบันทึก ดังนั้น VACUUM FREEZE ก็จะลบ "ขยะ" ออกจาก ตาราง แต่ตัวบันทึกเองไม่เคลื่อนไหว จึงเร็วกว่าและไม่บล็อกการเขียน ปัจจุบันตัวเลือกนี้ถูกแทนที่ด้วย autovacuum - การรวบรวมขยะอัตโนมัติ postgresql.confพร้อมตัวเลือกเพิ่มเติมมากมายที่ขยายฟังก์ชันการทำงาน:

เครื่องดูดฝุ่นอัตโนมัติ=เปิด# เปิดใช้งานการรวบรวมขยะอัตโนมัติ
log_autovacuum_min_duration = -1# การตั้งค่าเป็นศูนย์จะบันทึกการกระทำของ autovacuum ทั้งหมด ลบหนึ่ง (โดยค่าเริ่มต้น) ห้ามไม่ให้ส่งออกไปยังบันทึก เช่น หากคุณตั้งค่าไว้
เท่ากับ 250 ms จากนั้นการดำเนินการดูดอัตโนมัติและการวิเคราะห์ทั้งหมดที่ทำงานเป็นเวลา 250 ms ขึ้นไปจะถูกบันทึก การเปิดใช้งานการตั้งค่านี้อาจมีประโยชน์สำหรับการติดตามเครื่องดูดฝุ่นอัตโนมัติ
ตัวเลือกนี้สามารถตั้งค่าได้ในไฟล์ postgresql.conf หรือในเท่านั้น บรรทัดคำสั่งเซิร์ฟเวอร์
autovacuum_naptime = 10 นาที# เวลาเป็นวินาทีหลังจากที่ฐานข้อมูลได้รับการตรวจสอบความจำเป็นในการรวบรวมขยะ โดยค่าเริ่มต้น สิ่งนี้จะเกิดขึ้นหนึ่งครั้งต่อนาที
autovacuum_vacuum_threshold= 1800 # เกณฑ์สำหรับจำนวนบันทึกที่ถูกลบและแก้ไขในตารางใดๆ เมื่อเกินปริมาณขยะที่เกิดขึ้น (VACUUM)
autovacuum_analyze_threshold= 900 # เกณฑ์สำหรับจำนวนบันทึกที่แทรก ลบ และแก้ไขในตารางใดๆ เกินกว่าที่กระบวนการวิเคราะห์ (วิเคราะห์) จะเริ่มต้นขึ้น
autovacuum_vacuum_scale_factor= 0.2 # เปอร์เซ็นต์ของบันทึกที่เปลี่ยนแปลงและถูกลบโดยสัมพันธ์กับตาราง ซึ่งเกินกว่าที่การรวบรวมขยะจะถูกทริกเกอร์
autovacuum_analyze_scale_factor= 0.1 # เหมือนกับตัวแปรก่อนหน้า แต่สัมพันธ์กับการวิเคราะห์
การวิเคราะห์สุญญากาศ— หากฐานข้อมูลมีตารางที่ข้อมูลไม่เปลี่ยนแปลงหรือลบ แต่เพิ่มเท่านั้น คุณสามารถใช้คำสั่ง ANALYZE แยกต่างหากสำหรับตารางดังกล่าวได้ นอกจากนี้ยังควรใช้คำสั่งนี้สำหรับตารางแยกต่างหากหลังจากเพิ่มบันทึกจำนวนมากลงไป

วิเคราะห์คำสั่ง:

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

คำสั่ง REINDEX (การจัดทำดัชนีใหม่):

ใช้เพื่อสร้างดัชนีที่มีอยู่ใหม่ มันสมเหตุสมผลที่จะใช้มันในกรณี

- ความเสียหายต่อดัชนี;

- เพิ่มขนาดอย่างต่อเนื่อง

กรณีที่ 2 ต้องมีคำอธิบายบางอย่าง ดัชนีประกอบด้วยบล็อกที่มีบันทึกเวอร์ชันเก่าเช่นเดียวกับตาราง PostgreSQL ไม่สามารถใช้บล็อกเหล่านี้ซ้ำได้เสมอไป ดังนั้นไฟล์ดัชนีจะค่อยๆ ใหญ่ขึ้น หากข้อมูลในตารางเปลี่ยนแปลงบ่อย ข้อมูลก็จะเติบโตได้ค่อนข้างเร็ว หากคุณสังเกตเห็นพฤติกรรมนี้ของดัชนี คุณควรกำหนดค่าให้รันคำสั่ง REINDEX เป็นระยะ โปรดทราบ: คำสั่ง REINDEX เช่น VACUUM FULL จะล็อกตารางโดยสมบูรณ์ ดังนั้นจึงต้องดำเนินการเมื่อเซิร์ฟเวอร์โหลดน้อยที่สุด

คำถามที่ DBMS - Postgresql หรือ MS SQL สำหรับ 1C ใดเหมาะสมที่สุด - เป็นหัวข้อของบทความมากมาย ในบทความนี้ เราจะดูขั้นตอนการเพิ่มประสิทธิภาพสำหรับทั้งสองอย่าง DBMS ของผู้จำหน่ายแต่ละรายมีทั้งคำแนะนำการกำหนดค่าและคำแนะนำจาก 1C ควรสังเกตว่าขึ้นอยู่กับอุปกรณ์ การกำหนดค่าเซิร์ฟเวอร์ และจำนวนผู้ใช้ที่ตั้งค่าโหลดที่แตกต่างกัน รายละเอียดของกระบวนการเพิ่มประสิทธิภาพ DBMS สำหรับ 1C และคำแนะนำในการใช้งานอาจมีการเปลี่ยนแปลง

การตั้งค่า PostgreSQL สำหรับ 1C

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

• ขั้นแรก เราปิดใช้งานการประหยัดพลังงาน (มิฉะนั้นความล่าช้าในการตอบสนองจากฐานข้อมูลอาจเพิ่มขึ้นอย่างไม่อาจคาดเดาได้) และห้ามการแลกเปลี่ยนหน่วยความจำที่ใช้ร่วมกัน
• เรากำหนดค่าพารามิเตอร์พื้นฐานของเซิร์ฟเวอร์ DBMS (คำแนะนำสำหรับการกำหนดค่ามีการอธิบายไว้ในรายละเอียดที่เพียงพอทั้งบนเว็บไซต์อย่างเป็นทางการของผู้ขายและโดย 1C ดังนั้นเราจะเน้นเฉพาะสิ่งที่สำคัญที่สุดเท่านั้น)
• คำแนะนำมาตรฐานของ บริษัท 1C แนะนำให้ปิดการใช้งานกลไก HyperThreading แต่การทดสอบ Postgres-pro บนเซิร์ฟเวอร์ที่เปิดใช้งาน SMT (มัลติเธรดพร้อมกัน) กลับแสดงผลลัพธ์ที่แตกต่างออกไป

การตั้งค่า shared_buffers เป็น RAM/4 เป็นคำแนะนำเริ่มต้น แต่ตัวอย่าง Sql Server แนะนำว่ายิ่งจัดสรรหน่วยความจำให้มากเท่าใด ประสิทธิภาพก็จะยิ่งดีขึ้นเท่านั้น (โดยที่ปิดใช้งานการล้างเพจ) นั่นคือยิ่งหน้าข้อมูลอยู่ใน RAM มากเท่าใด การเข้าถึงดิสก์ก็จะน้อยลงเท่านั้น คำถามเกิดขึ้น: ทำไมจึงมีแคชขนาดเล็กเช่นนี้? คำตอบนั้นง่ายมาก: หาก shared_buffers มีขนาดใหญ่ เพจที่ไม่ได้ใช้บางเพจจะถูกสลับไปที่ดิสก์ แต่จะติดตามช่วงเวลาที่การรีเซ็ตหยุดและตัวบ่งชี้พารามิเตอร์เหมาะสมที่สุดได้อย่างไร เพื่อให้บรรลุและเข้าถึงตัวบ่งชี้ shared_buffers ที่เหมาะสมที่สุด มูลค่าของมันจะต้องเพิ่มขึ้นในการผลิตทุกวัน (ถ้าเป็นไปได้) โดยเพิ่มขึ้นทีละระดับ และดูว่าเพจใดที่จะเริ่มถูกล้างลงดิสก์ (การสลับจะเพิ่มขึ้น)

นอกจากนี้ "พารามิเตอร์ขนาดใหญ่" ยังได้รับผลกระทบในทางลบจากการทำงานกับเพจขนาดเล็กจำนวนมาก ซึ่งโดยค่าเริ่มต้นจะมีขนาด 8Kb การทำงานร่วมกับพวกเขาทำให้ต้นทุนค่าโสหุ้ยเพิ่มขึ้น สิ่งนี้สามารถทำอะไรได้บ้างเพื่อปรับให้เหมาะสมสำหรับ 1C PostgreSQL 9.4 เปิดตัวพารามิเตอร์ huge_pages ซึ่งสามารถเปิดใช้งานได้ แต่เฉพาะบน Linux เท่านั้น ตามค่าเริ่มต้น หน้าขนาดใหญ่จะรวมอยู่ในขนาดเริ่มต้นที่ 2,048 kB นอกจากนี้ จะต้องเปิดใช้งานการสนับสนุนเพจเหล่านี้ในระบบปฏิบัติการ ดังนั้น ด้วยการเพิ่มประสิทธิภาพโครงสร้างการจัดเก็บข้อมูล คุณสามารถบรรลุตัวบ่งชี้ shared_buffers ที่ใหญ่ขึ้นได้

work_mem = RAM/32..64 หรือ 32MB..128MB กำหนดจำนวนหน่วยความจำสำหรับแต่ละเซสชันที่จะใช้สำหรับการเรียงลำดับภายใน การรวม ฯลฯ ก่อนที่จะใช้ไฟล์ชั่วคราว หากเกินปริมาณนี้ เซิร์ฟเวอร์จะใช้ไฟล์ชั่วคราวบนดิสก์ ซึ่งสามารถลดความเร็วในการประมวลผลคำขอได้อย่างมาก พารามิเตอร์นี้ใช้เมื่อดำเนินการตัวดำเนินการ: ORDER BY, DISTINCT, การรวมการรวม ฯลฯ

คำนวณเพิ่มเติม พารามิเตอร์นี้สามารถทำได้ดังนี้: (หน่วยความจำที่ใช้ร่วมกัน shared_buffers - หน่วยความจำสำหรับโปรแกรมอื่น) / จำนวนการเชื่อมต่อที่ใช้งานอยู่ ค่านี้สามารถลดลงได้โดยการตรวจสอบจำนวนไฟล์ชั่วคราวที่สร้างขึ้น สถิติเกี่ยวกับขนาดและจำนวนไฟล์ชั่วคราวดังกล่าวสามารถรับได้จากมุมมองระบบ pg_stat_database

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

การติดตั้ง PostgreSQL

การติดตั้ง 1C บน PostgreSQL บน Windows นั้นเป็นกระบวนการที่ค่อนข้างง่าย เมื่อรันแพ็คเกจการติดตั้ง คุณต้องระบุการเข้ารหัส UTF-8 อันที่จริงนี่เป็นความแตกต่างที่น่าสนใจเพียงอย่างเดียวและไม่จำเป็นต้องกำหนดค่า PostgreSQL สำหรับ 1C 8.3 จาก Windows เพิ่มเติม การติดตั้งและกำหนดค่า PostgreSQL สำหรับ 1C บน Linux OS อาจทำให้เกิดปัญหาหลายประการ เพื่อเอาชนะสิ่งเหล่านี้ เป็นตัวอย่าง ลองพิจารณาใช้งาน (โดยใช้ชุดการแจกจ่ายจากผู้จำหน่ายชั้นนำของรัสเซีย PostgreSQL-Pro และบริษัท 1C) PostgreSQL บนเซิร์ฟเวอร์ Ubuntu 16.04 x64

การติดตั้งชุดการแจกจ่าย 1C สำหรับ PostgreSQL DBMS

1. ดาวน์โหลดตำแหน่งที่ระบุของชุดการแจกจ่าย PostgreSQL DBMS:

2. อัปโหลด PostgreSQL ไปยังเซิร์ฟเวอร์

3. คุณสามารถแตกไฟล์ติดตั้ง PostgreSQL DBMS ได้ด้วยคำสั่ง:

tar -xvf postgresql-9.4.2-1.1C_amd64_deb.tar.bz2

4. ก่อนที่จะติดตั้งชุดแจกจ่าย PostgreSQL DBMS ให้ตรวจสอบการมีอยู่ของภาษาที่ต้องการในระบบ (โดยค่าเริ่มต้น ru_RU.UTF-8):

5.หากระบบที่ PostgreSQL ใช้งานได้ถูกติดตั้งในภาษาอื่นที่ไม่ใช่ภาษารัสเซีย คุณจะต้องสร้างภาษาใหม่:

locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg- กำหนดค่าสถานที่ใหม่

6.หากภาษาที่ต้องการยังคงมีอยู่ ให้ติดตั้งตามค่าเริ่มต้น:

locale –a nano /etc/default/locale แทนที่เนื้อหาด้วย LANG=ru_RU.UTF-8

7.หลังจากรีบูต ให้ติดตั้งแพ็คเกจที่จำเป็นสำหรับ PostgreSQL เวอร์ชันของเรา:

apt-get ติดตั้ง libxslt1.1 ssl-cert

8. แพ็คเกจ PostgreSQL เวอร์ชัน 9.4.2-1.1C เชื่อมโยงกับแพ็คเกจ libicu เวอร์ชัน libicu48 เวอร์ชันที่ต้องการไม่อยู่ในที่เก็บอีกต่อไป แต่คุณสามารถดาวน์โหลดได้

9. ดาวน์โหลดและวางในไดเร็กทอรีที่เก็บไฟล์ที่ดาวน์โหลดสำหรับ PostgreSQL

10. เมื่อไปที่ไดเร็กทอรีที่มีไฟล์ PostgreSQL เราจะทำการติดตั้งโดยพิมพ์คำสั่งต่อไปนี้ตามลำดับ:

ซีดี<Путь к папке с файлами>dpkg -i libicu48_4.8.1.1-3ubuntu0.6_amd64.deb dpkg -i libpq5_9.4.2-1.1C_amd64.deb dpkg -i postgresql-client-common_154.1.1C_all.deb dpkg -i postgresql-common_154.1.1C_all.deb dp กก -i postgresql-client-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-contrib-9.4_9.4.2-1.1C_amd64.deb

11.เสร็จแล้ว ติดตั้งชุดการแจกจ่าย PostgreSQL DBMS แล้ว

การติดตั้งการกระจาย PostgreSQL-Pro

ในการติดตั้งเซิร์ฟเวอร์ คุณต้องรันคำสั่งต่อไปนี้ติดต่อกัน:

sudo sh -c "echo "deb http:// 1c.postgrespro.ru/deb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/postgrespro-1c.list" wget --เงียบ -O - ​​​​http:// 1c.postgrespro.ru/keys/GPG-KEY-POSTGRESPRO-1C-92 | sudo apt-key add - && sudo apt-get อัปเดต sudo apt-get ติดตั้ง postgresql-pro-1c-9.4

หากต้องการเข้าถึงเซิร์ฟเวอร์ ให้แก้ไขพารามิเตอร์ในไฟล์ pg_hba.conf

ซีดี<Путь до каталога pg_hba.conf>cp pg_hba.conf pg_hba.conf.old bash -c "echo "local all postgres trust"> pg_hba.conf" bash -c "echo "โฮสต์ทั้งหมด md5 ทั้งหมด" >> pg_hba.conf"

ตัวไฟล์เองมีโครงสร้างดังต่อไปนี้:

ไฟล์ได้รับการบันทึกไว้อย่างดีแต่ ภาษาอังกฤษ. มาดูพารามิเตอร์หลักโดยย่อ:

• ท้องถิ่นการเชื่อมต่อท้องถิ่นผ่านระบบปฏิบัติการยูนิกซ์เท่านั้น
• เจ้าภาพการเชื่อมต่อ TCP/IP
• โฮสต์สแอลการเชื่อมต่อ SSL ที่เข้ารหัสผ่าน TCP/IP (เซิร์ฟเวอร์ต้องสร้างด้วยการรองรับ SSL และต้องตั้งค่าพารามิเตอร์ ssl ด้วย)
• โฮสต์นอสเซิลการเชื่อมต่อที่ไม่ได้เข้ารหัสผ่าน TCP/IP

• เชื่อมั่นยอมรับโดยไม่มีการรับรองความถูกต้อง
• ปฏิเสธปฏิเสธโดยไม่มีการรับรองความถูกต้อง
• รหัสผ่านขอรหัสผ่านข้อความที่ชัดเจน
• md5ขอรหัสผ่านในรูปแบบ MD5
• ลาปการตรวจสอบชื่อผู้ใช้และรหัสผ่านโดยใช้เซิร์ฟเวอร์ LDAP
• รัศมีการตรวจสอบชื่อผู้ใช้และรหัสผ่านโดยใช้เซิร์ฟเวอร์ RADIUS
• แพมตรวจสอบชื่อผู้ใช้และรหัสผ่านโดยใช้บริการปลั๊กอิน

ข้อมูลโดยละเอียดและรายละเอียดเพิ่มเติมสามารถพบได้ในเอกสารประกอบสำหรับผลิตภัณฑ์ PostgreSQL

root@NODE2:/home/asd# service --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# service postgresql start root@NODE2:/home/asd# service --status-all | grep postgres [ + ] postgresql

หลังจากเสร็จสิ้นการติดตั้งพื้นฐานแล้ว คุณจะต้องกำหนดค่า ไฟล์การกำหนดค่าเซิร์ฟเวอร์ postgresql.conf ตามข้อมูลเฉพาะของ PostgreSQL, เซิร์ฟเวอร์ 1C และการกำหนดค่าเซิร์ฟเวอร์ Ubuntu

การเพิ่มประสิทธิภาพ 1C สำหรับ MS SQL Server

ติดตั้ง อัพเดทล่าสุดสำหรับเซิร์ฟเวอร์ SQL

ระบบปฏิบัติการจะสงวนพื้นที่และเติมด้วยศูนย์ ซึ่งใช้เวลานานพอสมควรในเหตุการณ์ต่อไปนี้:

• การสร้างฐานข้อมูล
• การเพิ่มไฟล์ข้อมูล บันทึกธุรกรรม ไปยังฐานข้อมูลที่มีอยู่
• การเพิ่มขนาดของไฟล์ที่มีอยู่ (รวมถึงการดำเนินการ Autogrow)
• เรากู้คืนฐานข้อมูลหรือกลุ่มของไฟล์

กำลังตัดสินใจอยู่ ปัญหานี้การเพิ่มบทบาท (ภายใต้เซิร์ฟเวอร์ที่กำลังทำงานอยู่) ให้กับรายการ การเมืองท้องถิ่นความปลอดภัย "การดำเนินงานบำรุงรักษาปริมาณ"

ถ้าเป็นไปได้ จำเป็นต้องกระจายฐานข้อมูล TempDB (มีการใช้งานอย่างเข้มข้นเป็นพิเศษในโหมดการล็อคที่มีการจัดการ RCSI) และบันทึกธุรกรรมบนดิสก์ที่แตกต่างกัน

บนเซิร์ฟเวอร์ที่ทำงาน เซิร์ฟเวอร์ SQLควรตั้งค่าโหมดประหยัดพลังงานเป็น "ประสิทธิภาพสูง"

โฟลเดอร์ที่มีไฟล์ฐานข้อมูลไม่ควรถูกบีบอัด

บนแท็บ "หน่วยความจำ" สำหรับเซิร์ฟเวอร์ เราตั้งค่าระดับขั้นต่ำเป็น 50% ของหน่วยความจำทั้งหมด เราคำนวณค่าสูงสุดโดยใช้สูตรใดสูตรหนึ่ง:

• หน่วยความจำสูงสุด = ปริมาตรรวม - ขนาดตาม OS - ขนาดสำหรับ 1C (ถ้ามีเคยวัดหน่วยความจำที่ใช้กับเคาน์เตอร์มาก่อน) หรือ
• หน่วยความจำสูงสุด = ขนาดรวม – (1024* ขนาดรวม/16384)

เราจำกัดพารามิเตอร์ DOP “ระดับสูงสุดของความขนาน” และตั้งค่าเป็น “1”

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

เราจัดทำดัชนีตารางใหม่เป็นระยะและจัดเรียงข้อมูลดัชนี

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

เราได้รับการปรับปรุงในการทำงานกับ TempDB ในระหว่าง I/O โดยการสร้างไฟล์ข้อมูลเพิ่มเติม หากมีตัวประมวลผลแบบลอจิคัลน้อยกว่า 8 ตัว ขอแนะนำให้คุณสร้างไฟล์ข้อมูลสำหรับตัวประมวลผลแบบลอจิคัลแต่ละตัว หากมีตัวประมวลผลแบบลอจิคัลมากกว่า 8 ตัว ขอแนะนำให้สร้างไฟล์ข้อมูล 8 ไฟล์ และเพิ่มขึ้นทีละ 1 ตัวจากผลคูณของ 4 ต้องแน่ใจว่าได้ประมาณภาระงานบน TempDB

1 พ.ย. 2555 ข้อดีของการใช้แจกฟรี ซอฟต์แวร์ชัดเจน. น่าเสียดายที่ข้อเสียก็ชัดเจนเช่นกัน - ไม่มีการสนับสนุนอย่างเป็นทางการ เอกสารมักจะขัดแย้งกัน ไม่สมบูรณ์ และกระจัดกระจายไปทั่ว แหล่งที่มาที่แตกต่างกัน. บทความนี้จะช่วยให้คุณเข้าใจกระบวนการติดตั้ง PosgreSQL สำหรับ 1C:Enterprise 8 หลีกเลี่ยงข้อผิดพลาดที่ไม่ได้อธิบายไว้ในเอกสารอย่างเป็นทางการ

ส่วนประกอบที่จำเป็นสำหรับการติดตั้ง

PostgreSQL DBMS มีการแจกจ่ายฟรีและรวมอยู่ในแพ็คเกจการส่งมอบของแอปพลิเคชันเซิร์ฟเวอร์ 1C แอปพลิเคชันเซิร์ฟเวอร์ 1C:Enterprise 8 มีสองเวอร์ชัน: 32 บิตและ 64 บิต Postgre สามารถจัดการได้ทั้งสองอย่าง

ดังนั้นเราจึงมีชุดการจัดจำหน่ายอยู่ในมือ:

• Postgre: postgresql-9_1_2-1_1Cx64.zip กรุณาจัดทำโดย 1C
• การเผยแพร่แอปพลิเคชันเซิร์ฟเวอร์ 1C:Enterprise สำหรับ Windows x64 เวอร์ชัน 8.2.16.368

ดูเหมือนว่าไม่มีอะไรจะง่ายไปกว่านี้แล้ว - เพียงแค่เปิดและติดตั้ง อย่างง่ายดาย! แต่การติดตั้งในโหมดมาตรฐานจะให้ข้อ จำกัด เล็กน้อย: คลัสเตอร์จะอยู่ในโฟลเดอร์ "Program Files" ไม่ใช่ทุกคนจะชอบมัน ลองพิจารณาสองตัวเลือกการติดตั้งแบบง่ายและขั้นสูง

บทความนี้แบ่งออกเป็น 5 ส่วน:

1) การติดตั้งเซิร์ฟเวอร์ 1C

2) ติดตั้ง PostgreSQL ในรูปแบบมาตรฐาน ซึ่งเพียงพอที่จะรัน 1C โดยไม่ต้องตั้งค่าเพิ่มเติม

3) ติดตั้ง PostgreSQL และเลือกโฟลเดอร์ที่เก็บข้อมูลคลัสเตอร์

4) การสร้างฐานข้อมูล 1C ใหม่

5) การระบุโฟลเดอร์สำหรับจัดเก็บไฟล์ฐานข้อมูลบนเซิร์ฟเวอร์ DBMS

อย่าลืมอ่านบทความทั้งหมดก่อนการติดตั้ง!

การติดตั้งแอปพลิเคชันเซิร์ฟเวอร์ 1C

เราเปิดตัว setup.exe จากโฟลเดอร์พร้อมชุดแจกจ่ายเซิร์ฟเวอร์ 1C

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

หลังจากติดตั้งแอปพลิเคชันเซิร์ฟเวอร์ ระบบจะแจ้งให้คุณติดตั้งไดรเวอร์คีย์ป้องกัน HASP เราเห็นด้วย:

เรากำลังรอข้อความ:

หากข้อความแตกต่างออกไป มีแนวโน้มว่าจะมี "ส่วนท้าย" เหลืออยู่ในระบบจากการติดตั้งไดรเวอร์ HASP ครั้งก่อน ลบทั้งหมดแล้วลองอีกครั้ง

เสร็จแล้วเราได้ติดตั้งแอปพลิเคชันเซิร์ฟเวอร์ 1C:Enterprise 8 เรียบร้อยแล้ว

การติดตั้ง PostgreSQL ในรูปแบบมาตรฐาน เพียงพอที่จะรัน 1C โดยไม่ต้องตั้งค่าเพิ่มเติม

เรียกใช้ "postgresql-9.1.2-1.1C(x64).msi"

คุณไม่จำเป็นต้องเปลี่ยนตัวเลือกการติดตั้ง 1C จะทำงาน ไกลออกไป.

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

หน้าต่างการติดตั้งถัดไป

เราเริ่มต้นคลัสเตอร์ หากเซิร์ฟเวอร์ฐานข้อมูลและเซิร์ฟเวอร์แอปพลิเคชัน 1C ของเราเปิดอยู่ คอมพิวเตอร์ที่แตกต่างกันจากนั้นทำเครื่องหมายที่ช่อง “รองรับการเชื่อมต่อจาก IP ใด ๆ” ไม่เช่นนั้นเราจะไม่แตะต้องมัน อย่าลืมระบุการเข้ารหัส UTF8 สร้างผู้ใช้ระดับสูงของ DBMS ไกลออกไป…

สำหรับงานเริ่มแรก เราไม่ต้องการอะไรเพิ่มเติม ให้ยกเลิกการทำเครื่องหมายที่ช่องและทำการติดตั้งให้เสร็จสิ้น

ผลลัพธ์ของความพยายามของเราคือ PostgreSQL ที่พร้อมใช้งาน หากเราพอใจว่าฐานข้อมูลจะอยู่ใน Program Files\PostgreSQL\9.1.2-1.1C\data เราจะจบเพียงแค่นั้น เปิดฐานข้อมูลและเพลิดเพลินกับกระบวนการ อย่างไรก็ตาม บ่อยครั้งกว่านั้นที่ฐานข้อมูล "โกหก" บนดิสก์อาร์เรย์ที่ออกแบบมาเป็นพิเศษและไม่ได้เปิดอยู่ ดิสก์ระบบ. หากต้องการกำหนดค่าตำแหน่งข้อมูล โปรดอ่านส่วนต่อไปนี้ก่อนการติดตั้ง

การติดตั้ง Postgre ด้วยการเลือกตำแหน่งที่เก็บข้อมูลคลัสเตอร์

เราดำเนินการติดตั้ง Postgre และดำเนินการตามขั้นตอนทั้งหมดจนกว่าเราจะได้รับแจ้งให้เริ่มต้นคลัสเตอร์:

ยกเลิกการเลือก "เริ่มต้นคลัสเตอร์ฐานข้อมูล" แล้วคลิก "ถัดไป"

ใช่ เรามั่นใจ

ยกเลิกการเลือก “Run Stack Builder on exit” และทำการติดตั้งให้เสร็จสิ้น

1. จำเป็นต้องให้สิทธิ์แบบเต็มแก่โฟลเดอร์ที่เราติดตั้ง PostgreSQL ซึ่งโดยปกติจะเป็น C:\Program Files\PostgreSQL

2. เรียกใช้ cmd ในฐานะผู้ดูแลระบบ หากคุณทำเช่นนี้ใน win7 ให้เรียกใช้ในฐานะผู้ดูแลระบบ

3. สร้างโฟลเดอร์ที่จะจัดเก็บคลัสเตอร์ ตัวอย่างเช่น d:\postgredata

md d:\postgredata

4. เราเริ่มต้นคลัสเตอร์ด้วยตนเองโดยระบุเส้นทางที่จะตั้งอยู่

“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\initdb.exe” -D d:\postgredata --locale=Russian_Russia --encoding=UTF8 -U postgres

5. ลบบริการ PostgreSQL ที่ติดตั้งระหว่างการติดตั้ง

sc ลบ pgsql-9.1.2-1.1C-x64

โดยที่ pgsql-9.1.2-1.1C-x64 เป็นชื่อของบริการ หากคุณไม่ทราบชื่อแน่ชัด คุณสามารถดูคุณสมบัติของบริการ “PostgreSQL Database Server...” ได้ (เริ่ม - แผงควบคุม - เครื่องมือการดูแลระบบ - บริการ)

6. สร้าง บริการใหม่บ่งบอกถึงคลัสเตอร์ของเรา

“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl” ลงทะเบียน -N pgsql -U postgresql -P รหัสผ่าน -D d:/postgredata

7. ไปที่บริการกันดีกว่า เริ่ม – แผงควบคุม – การดูแลระบบ – บริการ และเริ่มบริการของเรา

การสร้างฐานข้อมูล 1C ใหม่บนเซิร์ฟเวอร์ด้วย PostgreSQL

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

เราเปิดตัวไคลเอนต์ 1C

คลิก "เพิ่ม..."

เราตั้งชื่อฐานข้อมูลโดยระบุว่า "บน 1C: เซิร์ฟเวอร์องค์กร" จากนั้น

เซิร์ฟเวอร์คลัสเตอร์ 1C:องค์กร– localhost หากเรากำลังสร้างฐานข้อมูลบนคอมพิวเตอร์เครื่องเดียวกับที่ติดตั้งเซิร์ฟเวอร์ 1C หรือชื่อของแอปพลิเคชันเซิร์ฟเวอร์ 1C หากอยู่บนเครื่องอื่น

ชื่อของฐานข้อมูลในคลัสเตอร์- ในอนาคตชื่อนี้จะถูกระบุเมื่อเชื่อมต่อจากคอมพิวเตอร์เครื่องอื่น

ประเภท DBMS– เลือก PostgreSQL

เซิร์ฟเวอร์ฐานข้อมูล- ระบุชื่อของเซิร์ฟเวอร์ PostgreSQL หากเราสร้างฐานข้อมูลบนเซิร์ฟเวอร์ เราก็ระบุ localhost ด้วย

ชื่อฐานข้อมูล– ด้วยชื่อนี้ ฐานข้อมูลจะถูกสร้างขึ้นใน PostgreSQL

ผู้ใช้, รหัสผ่าน– ชื่อของผู้ใช้ที่เราระบุเป็น superuser เมื่อติดตั้ง PostgreSQL อย่าลืมทำเครื่องหมายในช่อง "สร้างฐานข้อมูลหากไม่มีอยู่"

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

การระบุโฟลเดอร์จัดเก็บฐานข้อมูล

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

เมื่อคุณเชื่อมต่อครั้งแรก Postgre จะขอรหัสผ่านสำหรับผู้ใช้ postgres (ซึ่งเราสร้างขึ้นระหว่างการติดตั้ง)

เราสร้าง TableSpace ใหม่ ซึ่งจะเป็นโฟลเดอร์ที่จะจัดเก็บฐานข้อมูลของเรา

ระบุตำแหน่งการจัดเก็บสำหรับไฟล์ฐานข้อมูล ตกลง.

ตอนนี้เราเปิดคุณสมบัติของฐานข้อมูลที่สร้างขึ้นก่อนหน้านี้ซึ่งเป็นตำแหน่งที่เราต้องการเปลี่ยน

เปลี่ยนคุณสมบัติ Tablespace หลังจากคลิก "ตกลง" ไฟล์ฐานข้อมูลจะถูกย้ายโดยอัตโนมัติ พร้อม! เราหวังว่าบทความนี้จะเป็นประโยชน์กับคุณ หากเป็นเช่นนั้น ให้แสดงความคิดเห็นและแบ่งปันลิงก์ไปยังหน้านี้ ขอบคุณ!