ฉันขอแนะนำให้คุณอ่านรายงานของ Nikolai Samokhvalov เรื่อง "แนวทางอุตสาหกรรมในการปรับแต่ง PostgreSQL: การทดลองกับฐานข้อมูล"
Shared_buffers = 25% – มันมากหรือน้อย? หรือถูกต้อง? คุณจะรู้ได้อย่างไรว่าคำแนะนำนี้ซึ่งค่อนข้างล้าสมัยมีความเหมาะสมในกรณีเฉพาะของคุณ
ถึงเวลาแก้ไขปัญหาการเลือกพารามิเตอร์ postgresql.conf "เหมือนผู้ใหญ่" ไม่ใช่ด้วยความช่วยเหลือของ "เครื่องรับสัญญาณอัตโนมัติ" ที่ตาบอดหรือคำแนะนำที่ล้าสมัยจากบทความและบล็อก แต่ขึ้นอยู่กับ:
- การทดลองที่ตรวจสอบอย่างเข้มงวดในฐานข้อมูลดำเนินการโดยอัตโนมัติในปริมาณมากและภายใต้เงื่อนไขที่ใกล้เคียงกับ "การต่อสู้" มากที่สุด
- ความเข้าใจอย่างลึกซึ้งเกี่ยวกับคุณสมบัติของ DBMS และ OS
ใช้แนนซี่ CLI () เราจะดูตัวอย่างที่เฉพาะเจาะจง - shared_buffers ที่โด่งดัง - ในสถานการณ์ที่แตกต่างกัน ในโปรเจ็กต์ที่แตกต่างกัน และพยายามหาวิธีเลือกการตั้งค่าที่เหมาะสมที่สุดสำหรับโครงสร้างพื้นฐาน ฐานข้อมูล และโหลดของเรา
เราจะพูดถึงการทดลองกับฐานข้อมูล นี่เป็นเรื่องราวที่กินเวลานานกว่าหกเดือนเล็กน้อย
เล็กน้อยเกี่ยวกับฉัน ประสบการณ์กับ Postgres มากกว่า 14 ปี บริษัทโซเชียลเน็ตเวิร์กจำนวนหนึ่งได้ก่อตั้งขึ้น Postgres เคยเป็นและถูกใช้ทุกที่
รวมถึงกลุ่ม RuPostgres บน Meetup อันดับที่ 2 ของโลก เรากำลังเข้าใกล้ 2 คนอย่างช้าๆ RuPostgres.org
และที่พีซีของการประชุมต่างๆ รวมถึง Highload ฉันรับผิดชอบฐานข้อมูล โดยเฉพาะ Postgres ตั้งแต่เริ่มต้น
และในช่วงไม่กี่ปีที่ผ่านมา ฉันได้เริ่มต้นการให้คำปรึกษากับ Postgres อีกครั้งใน 11 โซนเวลาจากที่นี่
และเมื่อฉันทำสิ่งนี้เมื่อไม่กี่ปีก่อน ฉันหยุดพักการทำงานด้วยตนเองกับ Postgres บ้าง น่าจะเป็นตั้งแต่ปี 2010 ฉันรู้สึกประหลาดใจที่กิจวัตรการทำงานของ DBA เปลี่ยนไปเพียงเล็กน้อย แต่ยังต้องใช้แรงงานคนมากเพียงใด และฉันก็คิดทันทีว่ามีบางอย่างผิดปกติที่นี่ ฉันจำเป็นต้องทำให้ทุกอย่างเป็นอัตโนมัติมากขึ้น
และเนื่องจากทั้งหมดอยู่ในระยะไกล ลูกค้าส่วนใหญ่จึงอยู่ในระบบคลาวด์ และเห็นได้ชัดว่ามีหลายอย่างที่เป็นไปโดยอัตโนมัติแล้ว เพิ่มเติมเกี่ยวกับเรื่องนี้ในภายหลัง นั่นคือทั้งหมดนี้ทำให้เกิดแนวคิดว่าควรมีเครื่องมือจำนวนหนึ่ง เช่น แพลตฟอร์มบางประเภทที่จะทำให้การดำเนินการ DBA เกือบทั้งหมดเป็นแบบอัตโนมัติเพื่อให้สามารถจัดการฐานข้อมูลจำนวนมากได้
รายงานนี้จะไม่รวม:
- “สัญลักษณ์แสดงหัวข้อย่อยสีเงิน” และคำสั่งเช่น - ตั้งค่า shared_buffers 8 GB หรือ 25% แล้วคุณจะสบายดี shared_buffers จะไม่มีมากนัก
- ฮาร์ดคอร์ "อวัยวะภายใน"
อะไรจะเกิดขึ้น?
- จะมีหลักการเพิ่มประสิทธิภาพที่เรานำไปใช้และพัฒนา จะมีแนวคิดทุกประเภทที่เกิดขึ้นระหว่างทางและเครื่องมือต่างๆ ที่เราสร้างขึ้นเป็นส่วนใหญ่ใน Open Source เช่น เราสร้างพื้นฐานใน Open Source นอกจากนี้เรายังมีตั๋ว การสื่อสารทั้งหมดเป็นแบบโอเพ่นซอร์ส คุณสามารถดูสิ่งที่เรากำลังทำอยู่สิ่งที่จะเกิดขึ้นในรุ่นถัดไป ฯลฯ
- นอกจากนี้ยังจะมีประสบการณ์ในการใช้หลักการเหล่านี้ เครื่องมือเหล่านี้ในบริษัทหลายแห่ง ตั้งแต่สตาร์ทอัพขนาดเล็กไปจนถึงบริษัทขนาดใหญ่
ทั้งหมดนี้พัฒนาไปอย่างไร?
ประการแรก งานหลักของ DBA นอกเหนือจากการสร้างความมั่นใจในการสร้างอินสแตนซ์ การใช้งานการสำรองข้อมูล ฯลฯ คือการค้นหาปัญหาคอขวดและเพิ่มประสิทธิภาพการทำงาน
ตอนนี้ก็จัดแบบนี้ครับ เราดูการตรวจสอบ เราเห็นบางอย่าง แต่เราขาดรายละเอียดบางอย่างไป เราเริ่มขุดอย่างระมัดระวังมากขึ้นโดยปกติด้วยมือของเราและเข้าใจว่าจะทำอย่างไรกับมันไม่ทางใดก็ทางหนึ่ง
และมีสองแนวทาง Pg_stat_statements เป็นโซลูชันเริ่มต้นสำหรับระบุการสืบค้นที่ช้า และการวิเคราะห์บันทึก Postgres โดยใช้ pgBadger
แต่ละวิธีมีข้อเสียร้ายแรง ในแนวทางแรก เราได้โยนพารามิเตอร์ทั้งหมดออกไป และถ้าเราเห็นตารางกลุ่ม SELECT * FROM โดยที่คอลัมน์เท่ากับ "?" หรือ “$” ตั้งแต่ Postgres 10 เราไม่รู้ว่านี่คือการสแกนดัชนีหรือการสแกนแบบ seq ขึ้นอยู่กับพารามิเตอร์เป็นอย่างมาก หากคุณแทนที่ค่าที่ไม่ค่อยพบที่นั่น จะเป็นการสแกนดัชนี หากคุณแทนที่ค่าที่ใช้พื้นที่ 90% ของตารางตรงนั้น การสแกน seq จะชัดเจน เนื่องจาก Postgres รู้สถิติ และนี่คือข้อเสียเปรียบครั้งใหญ่ของ pg_stat_statements แม้ว่างานบางอย่างอยู่ระหว่างดำเนินการก็ตาม
ข้อเสียที่ใหญ่ที่สุดของการวิเคราะห์บันทึกคือคุณไม่สามารถจ่าย "log_min_duration_statement = 0" ได้ตามกฎ และเราจะพูดถึงเรื่องนี้ด้วย ดังนั้นคุณจะไม่เห็นภาพรวมทั้งหมด และการสืบค้นบางอย่างซึ่งเร็วมากอาจใช้ทรัพยากรจำนวนมาก แต่คุณจะไม่เห็นมันเนื่องจากอยู่ต่ำกว่าเกณฑ์ของคุณ
DBA แก้ไขปัญหาที่พบได้อย่างไร
ตัวอย่างเช่น เราพบปัญหาบางอย่าง ปกติเค้าทำอะไรกัน? หากคุณเป็นนักพัฒนา คุณจะต้องทำอะไรบางอย่างที่มีขนาดไม่เท่ากัน หากคุณเป็น DBA แสดงว่าคุณมีการแสดงละคร และจะมีได้เพียงคนเดียวเท่านั้น และเขาช้ากว่าหกเดือน และคุณคิดว่าคุณจะไปผลิต และแม้แต่ DBA ที่มีประสบการณ์ก็ตรวจสอบการผลิตด้วยแบบจำลอง และมันเกิดขึ้นที่พวกเขาสร้างดัชนีชั่วคราว ตรวจสอบให้แน่ใจว่ามันช่วยได้ วางมัน และมอบให้กับนักพัฒนา เพื่อให้พวกเขาสามารถใส่มันลงในไฟล์การโยกย้าย นี่เป็นเรื่องไร้สาระที่กำลังเกิดขึ้นตอนนี้ และนี่คือปัญหา
- ปรับแต่งการกำหนดค่า
- ปรับชุดดัชนีให้เหมาะสม
- เปลี่ยนแบบสอบถาม SQL เอง (นี่เป็นวิธีที่ยากที่สุด)
- เพิ่มความจุ (วิธีที่ง่ายที่สุดในกรณีส่วนใหญ่)
มีเรื่องมากมายเกิดขึ้นกับสิ่งเหล่านี้ มีการจัดการมากมายใน Postgres มีเรื่องน่ารู้มากมาย มีดัชนีมากมายใน Postgres ขอขอบคุณผู้จัดงานสัมมนาครั้งนี้ด้วย และทั้งหมดนี้จำเป็นต้องรู้ และนี่คือสิ่งที่ทำให้ผู้ที่ไม่ใช่ DBA รู้สึกเหมือนกับว่า DBA กำลังฝึกฝนมนต์ดำ นั่นคือคุณต้องศึกษาเป็นเวลา 10 ปีจึงจะเริ่มเข้าใจทั้งหมดนี้ได้ตามปกติ
และฉันก็เป็นนักสู้กับมนต์ดำนี้ ฉันต้องการทำทุกอย่างเพื่อให้มีเทคโนโลยีและไม่มีสัญชาตญาณในเรื่องทั้งหมดนี้
ตัวอย่างชีวิตจริง
ฉันสังเกตเห็นสิ่งนี้อย่างน้อยสองโครงการ รวมทั้งโครงการของฉันเองด้วย โพสต์ในบล็อกอื่นบอกเราว่าค่า 1 สำหรับ default_statistict_target นั้นดี เอาล่ะ เรามาลองใช้งานจริงกันดีกว่า
และนี่ เราใช้เครื่องมือของเราในอีกสองปีต่อมา ด้วยความช่วยเหลือของการทดลองในฐานข้อมูลที่เรากำลังพูดถึงในวันนี้ เราสามารถเปรียบเทียบสิ่งที่เป็นอยู่และสิ่งที่เป็นอยู่ได้
และสำหรับสิ่งนี้ เราจำเป็นต้องสร้างการทดลองขึ้นมา ประกอบด้วยสี่ส่วน
- ประการแรกคือสภาพแวดล้อม เราต้องการชิ้นส่วนฮาร์ดแวร์ และเมื่อฉันมาที่บริษัทแห่งหนึ่งและเซ็นสัญญา ฉันบอกให้พวกเขาจัดหาฮาร์ดแวร์แบบเดียวกับที่ใช้งานจริงให้ฉัน สำหรับอาจารย์ของคุณแต่ละคน ฉันต้องมีฮาร์ดแวร์แบบนี้อย่างน้อยหนึ่งชิ้น ไม่ว่าจะเป็นอินสแตนซ์เครื่องเสมือนใน Amazon หรือ Google หรือฉันต้องการฮาร์ดแวร์ชิ้นเดียวกันทุกประการ นั่นคือฉันต้องการสร้างสภาพแวดล้อมขึ้นมาใหม่ และในแนวคิดเรื่องสภาพแวดล้อม เราได้รวม Postgres เวอร์ชันหลักไว้ด้วย
- ส่วนที่สองเป็นเป้าหมายของการวิจัยของเรา นี่คือฐานข้อมูล สามารถสร้างได้หลายวิธี ฉันจะแสดงให้คุณเห็นว่า
- ส่วนที่สามคือภาระ นี่เป็นช่วงเวลาที่ยากที่สุด
- และส่วนที่สี่คือสิ่งที่เราตรวจสอบคือสิ่งที่เราจะเปรียบเทียบกับอะไร สมมติว่าเราสามารถเปลี่ยนพารามิเตอร์ตั้งแต่หนึ่งตัวขึ้นไปในการกำหนดค่า หรือสร้างดัชนี เป็นต้น
เรากำลังเปิดตัวการทดลอง นี่คือ pg_stat_statements ด้านซ้ายคือสิ่งที่เกิดขึ้น ทางด้านขวา - เกิดอะไรขึ้น
ทางด้านซ้าย default_statistics_target = 100 ทางด้านขวา = 1 เราเห็นว่าสิ่งนี้ช่วยเราได้ โดยรวมแล้วทุกอย่างดีขึ้น 000%
แต่ถ้าเราเลื่อนลงมาก็จะมีกลุ่มคำขอจาก pgBadger หรือจาก pg_stat_statements มีสองตัวเลือก เราจะเห็นว่าคำขอบางรายการลดลง 88% และนี่คือแนวทางทางวิศวกรรม เราสามารถขุดเข้าไปข้างในได้อีกเพราะเราสงสัยว่าทำไมมันถึงจม คุณต้องเข้าใจว่าเกิดอะไรขึ้นกับสถิติ เหตุใดสถิติที่สะสมไว้มากขึ้นจึงนำไปสู่ผลลัพธ์ที่แย่ลง
หรือเราไม่สามารถขุดได้ แต่ทำ "ALTER TABLE ... ALTER COLUMN" แล้วส่งคืน 100 ที่เก็บข้อมูลกลับไปที่สถิติของคอลัมน์นี้ จากนั้นด้วยการทดลองอื่น เรามั่นใจได้ว่าแพตช์นี้ช่วยได้ ทั้งหมด. นี่เป็นแนวทางทางวิศวกรรมที่ช่วยให้เราเห็นภาพรวมและตัดสินใจโดยอาศัยข้อมูลมากกว่าสัญชาตญาณ
ตัวอย่างบางส่วนจากพื้นที่อื่น มีการทดสอบ CI ในการทดสอบมาหลายปีแล้ว และไม่มีโครงการใดที่มีความคิดที่ถูกต้องจะมีชีวิตอยู่ได้หากไม่มีการทดสอบอัตโนมัติ
ในอุตสาหกรรมอื่นๆ: ในการบิน ในอุตสาหกรรมยานยนต์ เมื่อเราทดสอบอากาศพลศาสตร์ เราก็มีโอกาสที่จะทำการทดลองด้วย เราจะไม่ปล่อยบางสิ่งจากภาพวาดสู่อวกาศโดยตรง หรือเราจะไม่นำรถเข้าสู่สนามแข่งในทันที เช่น มีอุโมงค์ลม.
เราสามารถสรุปได้จากการสังเกตของอุตสาหกรรมอื่นๆ
ประการแรก เรามีสภาพแวดล้อมที่พิเศษ ใกล้จะผลิตแต่ไม่ปิดครับ คุณสมบัติหลักคือควรมีราคาถูก ทำซ้ำได้ และเป็นอัตโนมัติที่สุดเท่าที่จะเป็นไปได้ และจะต้องมีเครื่องมือพิเศษในการทำการวิเคราะห์อย่างละเอียดด้วย
เป็นไปได้มากว่าเมื่อเราปล่อยเครื่องบินและบิน เรามีโอกาสศึกษาพื้นผิวปีกทุกๆ มิลลิเมตรน้อยกว่าในอุโมงค์ลม เรามีเครื่องมือวินิจฉัยเพิ่มเติม เราสามารถบรรทุกของหนักๆ ได้มากกว่าที่เราไม่สามารถแบกขึ้นเครื่องบินได้ เช่นเดียวกับ Postgres ในบางกรณี เราอาจเปิดใช้งานการบันทึกข้อความค้นหาแบบเต็มในระหว่างการทดสอบ และเราไม่ต้องการทำเช่นนี้ในการผลิต เราอาจวางแผนที่จะเปิดใช้งานสิ่งนี้โดยใช้ auto_explain
และอย่างที่ฉันบอกไป ระบบอัตโนมัติระดับสูงหมายความว่าเรากดปุ่มแล้วทำซ้ำ ควรจะเป็นเช่นนี้เพื่อให้มีการทดลองมากมายเพื่อให้สามารถสตรีมได้
Nancy CLI - รากฐานของ "ห้องปฏิบัติการฐานข้อมูล"
ดังนั้นเราจึงทำสิ่งนี้ นั่นคือฉันได้พูดคุยเกี่ยวกับแนวคิดเหล่านี้ในเดือนมิถุนายนเมื่อเกือบหนึ่งปีที่แล้ว และเรามีสิ่งที่เรียกว่า Nancy CLI ใน Open Source แล้ว ซึ่งเป็นรากฐานในการสร้างห้องปฏิบัติการฐานข้อมูล
— อยู่ในโอเพ่นซอร์สบน Gitlab คุณสามารถพูดได้คุณสามารถลองได้ ฉันให้ลิงค์ในสไลด์ คุณสามารถคลิกที่มันและมันจะอยู่ที่นั่น ทุกประการ
แน่นอนว่ายังมีอีกมากที่ยังอยู่ระหว่างการพัฒนา มีความคิดมากมายที่นั่น แต่นี่คือสิ่งที่เราใช้เกือบทุกวัน และเมื่อเรามีความคิด - ทำไมเมื่อเราลบ 40 บรรทัดทั้งหมดมันลงมาที่ IO จากนั้นเราก็สามารถทำการทดลองและดูรายละเอียดเพิ่มเติมเพื่อทำความเข้าใจกับสิ่งที่เกิดขึ้นแล้วลองแก้ไขได้ทันที นั่นคือเรากำลังทำการทดลอง ตัวอย่างเช่น เราปรับแต่งบางอย่างและดูว่าจะเกิดอะไรขึ้นในที่สุด และเราไม่ทำเช่นนี้ในการผลิต นี่คือสาระสำคัญของความคิด
งานนี้ทำได้ที่ไหน? สิ่งนี้สามารถทำงานได้ในเครื่อง เช่น คุณสามารถทำได้ทุกที่ หรือแม้แต่เรียกใช้บน MacBook ก็ได้ เราต้องการนักเทียบท่า ลุยเลย นั่นคือทั้งหมดที่ คุณสามารถรันมันได้ในบางกรณีบนชิ้นส่วนของฮาร์ดแวร์ หรือในเครื่องเสมือน ได้ทุกที่
และยังมีโอกาสที่จะทำงานจากระยะไกลใน Amazon ใน EC2 Instance ได้อีกด้วย และนี่คือโอกาสที่ยอดเยี่ยมมาก ตัวอย่างเช่น เมื่อวานเราทำการทดลองมากกว่า 500 ครั้งบนอินสแตนซ์ i3 โดยเริ่มจากอินสแตนซ์ที่อายุน้อยที่สุดและลงท้ายด้วย i3-16-xlarge และการทดลอง 500 ครั้งมีค่าใช้จ่าย 64 ดอลลาร์ แต่ละอันกินเวลา 15 นาที นั่นคือเนื่องจากมีการใช้สปอตที่นั่นจึงมีราคาถูกมาก - ส่วนลด 70% ซึ่งเป็นการเรียกเก็บเงินต่อวินาทีของ Amazon คุณสามารถทำอะไรได้มากมาย คุณสามารถทำวิจัยได้จริง
และรองรับ Postgres เวอร์ชันหลักสามเวอร์ชัน การทำเวอร์ชั่นเก่าและเวอร์ชั่น 12 ใหม่ให้เสร็จก็ไม่ใช่เรื่องยากเช่นกัน
เราสามารถกำหนดวัตถุได้สามวิธี นี้:
- ไฟล์ดัมพ์/sql
- วิธีหลักคือการโคลนไดเร็กทอรี PGDATA ตามกฎแล้วจะนำมาจากเซิร์ฟเวอร์สำรอง หากคุณมีการสำรองข้อมูลไบนารีปกติ คุณสามารถสร้างโคลนจากที่นั่นได้ หากคุณมีระบบคลาวด์ สำนักงานระบบคลาวด์อย่าง Amazon และ Google จะทำสิ่งนี้ให้คุณ นี่เป็นวิธีที่สำคัญที่สุดในการโคลนการผลิตจริง นี่คือวิธีที่เราเปิดเผย
- และวิธีการสุดท้ายเหมาะสำหรับการวิจัยเมื่อคุณต้องการทำความเข้าใจว่าบางอย่างทำงานอย่างไรใน Postgres นี่คือ pgbench คุณสามารถสร้างได้โดยใช้ pgbench มันเป็นเพียงตัวเลือก "db-pgbench" เพียงตัวเดียว คุณบอกเขาว่าขนาดไหน และทุกอย่างจะถูกสร้างขึ้นบนคลาวด์ตามที่ระบุไว้
และโหลด:
- เราสามารถดำเนินการโหลดได้ในเธรด SQL เดียว นี่เป็นวิธีดั้งเดิมที่สุด
- และเราสามารถจำลองโหลดได้ และเราสามารถจำลองมันได้ก่อนอื่นด้วยวิธีต่อไปนี้ เราจำเป็นต้องรวบรวมบันทึกทั้งหมด และมันเจ็บปวด ฉันจะแสดงให้คุณเห็นว่าทำไม และเราเล่นโดยใช้ pgreplay ซึ่งมีอยู่ใน Nancy
- หรืออีกทางเลือกหนึ่ง ภาระงานหัตถกรรมที่เรียกว่าซึ่งเราทำโดยใช้ความพยายามจำนวนหนึ่ง การวิเคราะห์ภาระงานปัจจุบันของเราในระบบการต่อสู้ เราได้ดึงคำขอกลุ่มอันดับต้นๆ ออกมา และการใช้ pgbench ทำให้เราสามารถจำลองภาระนี้ในห้องปฏิบัติการได้
- ไม่ว่าเราจะต้องทำ SQL บางอย่าง เช่น ตรวจสอบการโยกย้าย สร้างดัชนีที่นั่น ดำเนินการ ANALAZE ที่นั่น และเรามาดูสิ่งที่เกิดขึ้นก่อนสุญญากาศและหลังสุญญากาศ โดยทั่วไปแล้ว SQL ใดๆ
- ไม่ว่าเราจะเปลี่ยนพารามิเตอร์ตั้งแต่หนึ่งตัวขึ้นไปในการกำหนดค่า เราสามารถบอกให้เราตรวจสอบ เช่น 100 ค่าใน Amazon สำหรับฐานข้อมูลเทราไบต์ของเรา และในอีกไม่กี่ชั่วโมงคุณก็จะได้ผลลัพธ์ ตามกฎแล้ว คุณจะใช้เวลาหลายชั่วโมงในการปรับใช้ฐานข้อมูลเทราไบต์ แต่มีแพตช์อยู่ระหว่างการพัฒนา เรามีซีรีส์ที่เป็นไปได้ เช่น คุณสามารถใช้ pgdata เดียวกันบนเซิร์ฟเวอร์เดียวกันและตรวจสอบได้อย่างสม่ำเสมอ Postgres จะรีสตาร์ทและแคชจะถูกรีเซ็ต และคุณสามารถขับโหลดได้
- ไดเร็กทอรีมาพร้อมกับไฟล์ต่างๆ มากมาย โดยเริ่มจาก pg snapshotsstat***. และสิ่งที่น่าสนใจที่สุดคือ pg_stat_statements, pg_stat_kcacke นี่คือส่วนขยายสองรายการที่วิเคราะห์คำขอ และ pg_stat_bgwriter ไม่เพียงแต่มีสถิติของ pgwriter เท่านั้น แต่ยังรวมถึงจุดตรวจสอบและวิธีที่แบ็กเอนด์แทนที่บัฟเฟอร์สกปรกด้วย และมันน่าสนใจที่จะได้เห็น ตัวอย่างเช่น เมื่อเราตั้งค่า shared_buffers เป็นเรื่องน่าสนใจมากที่เห็นว่าทุกคนมาแทนที่กันมากเพียงใด
- บันทึกของ Postgres ก็มาถึงเช่นกัน บันทึกสองรายการ – บันทึกการเตรียมการและบันทึกการเล่นโหลด
- คุณสมบัติที่ค่อนข้างใหม่คือ FlameGraphs
- นอกจากนี้ หากคุณใช้ตัวเลือก pgreplay หรือ pgbench ในการเล่นโหลด เอาต์พุตของตัวเลือกเหล่านั้นจะเป็นค่าดั้งเดิม และคุณจะเห็นเวลาแฝงและ TPS จะสามารถเข้าใจว่าพวกเขาเห็นมันได้อย่างไร
- ข้อมูลระบบ.
- การตรวจสอบ CPU และ IO ขั้นพื้นฐาน นี่เป็นมากกว่าสำหรับอินสแตนซ์ EC2 ใน Amazon เมื่อคุณต้องการเปิดใช้อินสแตนซ์ที่เหมือนกัน 100 รายการในเธรดและเรียกใช้การทำงานที่แตกต่างกัน 100 ครั้งที่นั่น คุณจะมีการทดลอง 10 รายการ และคุณต้องตรวจสอบให้แน่ใจว่าคุณจะไม่เจอกรณีที่มีข้อบกพร่องซึ่งถูกใครบางคนกดขี่อยู่แล้ว ฮาร์ดแวร์อื่นๆ ทำงานอยู่บนฮาร์ดแวร์ชิ้นนี้ และคุณมีทรัพยากรเหลือเพียงเล็กน้อย เป็นการดีกว่าที่จะละทิ้งผลลัพธ์ดังกล่าว และด้วยความช่วยเหลือของ sysbench จาก Alexey Kopytov เราทำการตรวจสอบสั้นๆ หลายประการที่จะเกิดขึ้นและสามารถเปรียบเทียบกับรายการอื่นได้ เช่น คุณจะเข้าใจว่า CPU ทำงานอย่างไรและ IO ทำงานอย่างไร
อะไรคือปัญหาทางเทคนิคตามตัวอย่างของบริษัทต่างๆ?
สมมติว่าเราต้องการทำซ้ำการโหลดจริงโดยใช้บันทึก เป็นความคิดที่ดีหากเขียนบน Open Source pgreplay เราใช้มัน. แต่เพื่อให้ทำงานได้ดี คุณต้องเปิดใช้งานการบันทึกการสืบค้นแบบเต็มด้วยพารามิเตอร์และเวลา
มีภาวะแทรกซ้อนบางประการเกี่ยวกับระยะเวลาและการประทับเวลา เราจะล้างครัวทั้งหมดนี้ให้หมด คำถามหลักคือคุณสามารถจ่ายได้หรือไม่?
ปัญหาคือมันอาจจะไม่พร้อมใช้งาน ก่อนอื่น คุณต้องเข้าใจว่าสตรีมใดจะถูกเขียนลงในบันทึก หากคุณมี pg_stat_statements คุณสามารถใช้แบบสอบถามนี้ (ลิงก์จะมีอยู่ในสไลด์) เพื่อทำความเข้าใจว่าจะมีการเขียนประมาณกี่ไบต์ต่อวินาที
เราดูที่ความยาวของคำขอ เรากำลังละเลยความจริงที่ว่าไม่มีพารามิเตอร์ แต่เรารู้ความยาวของคำขอ และเรารู้ว่ามีการดำเนินการกี่ครั้งต่อวินาที ด้วยวิธีนี้เราสามารถประมาณจำนวนไบต์ต่อวินาทีได้โดยประมาณ เราอาจทำผิดพลาดเป็นสองเท่า แต่เราจะเข้าใจลำดับด้วยวิธีนี้อย่างแน่นอน
เราจะเห็นว่าคำขอนี้ดำเนินการ 802 ครั้งต่อวินาที และเราเห็นว่า bytes_per วินาที – 300 kB/s จะถูกเขียนบวกหรือลบ และตามกฎแล้วเราสามารถจ่ายกระแสดังกล่าวได้
แต่! ความจริงก็คือว่ามีระบบการบันทึกที่แตกต่างกัน และค่าเริ่มต้นของบุคคลมักจะเป็น "syslog"
และถ้าคุณมี syslog คุณก็อาจมีภาพแบบนี้ เราจะใช้ pgbench เปิดใช้งานการบันทึกแบบสอบถาม และดูว่าเกิดอะไรขึ้น
โดยไม่ต้องบันทึก - นี่คือคอลัมน์ทางด้านซ้าย เราได้ 161 TPS ด้วย syslog - นี่คือใน Ubuntu 000 บน Amazon เราได้รับ 16.04 TPS และถ้าเราเปลี่ยนเป็นวิธีการบันทึกอื่นอีกสองวิธี สถานการณ์ก็จะดีขึ้นมาก คือเราคาดว่าราคาจะลดลงแต่ไม่เท่าเดิม
และบน CentOS 7 ซึ่ง Journald ก็มีส่วนร่วมด้วย โดยเปลี่ยนบันทึกเป็นรูปแบบไบนารี่เพื่อให้ค้นหาได้ง่าย ฯลฯ ซึ่งนั่นถือเป็นฝันร้ายเลย TPS ลดลง 44 ครั้ง
และนี่คือสิ่งที่ผู้คนอาศัยอยู่ด้วย และบ่อยครั้งในบริษัทต่างๆ โดยเฉพาะบริษัทขนาดใหญ่ การเปลี่ยนแปลงนี้ทำได้ยากมาก หากคุณสามารถหลีกหนีจาก syslog ได้ โปรดหลีกหนีจากมัน
- ประเมิน IOPS และขั้นตอนการเขียน
- ตรวจสอบระบบบันทึกของคุณ
- หากภาระที่คาดการณ์ไว้มีขนาดใหญ่เกินไป ให้พิจารณาสุ่มตัวอย่าง
เรามี pg_stat_statements อย่างที่บอก มันต้องมีแน่ๆ และเราสามารถรับและอธิบายคำขอแต่ละกลุ่มด้วยวิธีพิเศษในไฟล์ได้ จากนั้นเราสามารถใช้คุณสมบัติที่สะดวกมากใน pgbench - นี่คือความสามารถในการแทรกหลายไฟล์โดยใช้ตัวเลือก "-f"
มันเข้าใจ "-f" มาก และคุณสามารถบอกได้ด้วยความช่วยเหลือของ "@" ในตอนท้ายว่าแต่ละไฟล์ควรมีการแชร์อะไรบ้าง นั่นคือเราสามารถพูดได้ว่า ทำเช่นนี้ใน 10% ของกรณี และนี่คือ 20% และสิ่งนี้จะนำเราเข้าใกล้สิ่งที่เราเห็นในการผลิตมากขึ้น
เราจะเข้าใจสิ่งที่เรามีในการผลิตได้อย่างไร? แบ่งปันอะไรและอย่างไร? นี่เป็นเพียงเล็กน้อยกัน เรามีสินค้าอีกหนึ่งรายการ . ยังเป็นฐานในโอเพ่นซอร์ส และตอนนี้เรากำลังพัฒนามันอย่างแข็งขัน
เขาเกิดมาด้วยเหตุผลที่แตกต่างกันเล็กน้อย ด้วยเหตุผลที่ติดตามไม่เพียงพอ คือมาดูที่ฐานดูปัญหาที่มีอยู่ และตามกฎแล้ว คุณจะต้องตรวจสุขภาพด้วย หากคุณเป็น DBA ที่มีประสบการณ์ คุณจะต้องทำ health_check เราดูที่การใช้ดัชนี ฯลฯ ถ้าคุณมี OKmeter ก็เยี่ยมมาก นี่คือการตรวจสอบที่ยอดเยี่ยมสำหรับ Postgres OKmeter.io – โปรดติดตั้ง ทุกอย่างทำได้ดีมากที่นั่น มันจ่ายแล้ว
ถ้าคุณไม่มี คุณก็มักจะมีไม่มาก ในการตรวจสอบ โดยปกติจะมี CPU, IO และมีการสำรองไว้ แค่นั้นเอง และเราต้องการมากกว่านี้ เราต้องดูว่า autovacuum ทำงานอย่างไร จุดตรวจสอบทำงานอย่างไร ใน io เราต้องแยกจุดตรวจสอบออกจาก bgwriter และจากแบ็กเอนด์ ฯลฯ
ปัญหาคือเมื่อคุณช่วยเหลือบริษัทขนาดใหญ่ พวกเขาไม่สามารถดำเนินการบางอย่างได้อย่างรวดเร็ว พวกเขาไม่สามารถซื้อ OKmeter ได้อย่างรวดเร็ว บางทีพวกเขาอาจจะซื้อมันภายในหกเดือน พวกเขาไม่สามารถจัดส่งพัสดุบางอย่างได้อย่างรวดเร็ว
และเราก็เกิดแนวคิดที่ว่าเราต้องการเครื่องมือพิเศษที่ไม่ต้องติดตั้งอะไรเลย กล่าวคือ คุณไม่จำเป็นต้องติดตั้งอะไรเลยในการผลิต ติดตั้งบนแล็ปท็อปของคุณหรือบนเซิร์ฟเวอร์สังเกตการณ์จากที่ที่คุณจะเรียกใช้ และจะวิเคราะห์สิ่งต่าง ๆ มากมาย: ระบบปฏิบัติการ ระบบไฟล์ และ Postgres เอง ทำให้มีการสืบค้นแบบเบา ๆ ที่สามารถเรียกใช้โดยตรงไปยังการใช้งานจริงและไม่มีอะไรจะล้มเหลว
เราเรียกมันว่า Postgres-checkup ในแง่การแพทย์ นี่คือการตรวจสุขภาพเป็นประจำ หากเป็นเรื่องเกี่ยวกับยานยนต์ มันก็เหมือนกับการบำรุงรักษา คุณบำรุงรักษารถยนต์ของคุณทุกๆ หกเดือนหรือหนึ่งปี ขึ้นอยู่กับยี่ห้อ คุณบำรุงรักษาฐานของคุณหรือไม่? นั่นคือคุณทำการวิจัยเชิงลึกเป็นประจำหรือไม่? มันจะต้องทำ หากคุณทำการสำรองข้อมูลให้ทำการตรวจสอบซึ่งมีความสำคัญไม่น้อย
และเรามีเครื่องมือดังกล่าว มันเริ่มปรากฏขึ้นอย่างแข็งขันเมื่อประมาณสามเดือนที่แล้วเท่านั้น เขายังเด็กอยู่แต่ยังมีอีกมาก
การรวบรวมกลุ่มข้อความค้นหาที่ "มีอิทธิพล" มากที่สุด - รายงาน K003 ใน Postgres-checkup
และมีกลุ่มรายงาน ก. สามรายงานจนถึงปัจจุบัน และมีรายงานดังกล่าว K003 มีอันดับสูงสุดจาก pg_stat_statements เรียงตาม Total_time
เมื่อเราจัดเรียงกลุ่มคำขอตามผลรวม_เวลา ที่ด้านบนสุดเราจะเห็นกลุ่มที่โหลดระบบของเรามากที่สุด กล่าวคือ ใช้ทรัพยากรมากขึ้น เหตุใดฉันจึงตั้งชื่อกลุ่มข้อความค้นหา เพราะเราโยนพารามิเตอร์ออกไป สิ่งเหล่านี้ไม่ใช่คำขออีกต่อไป แต่เป็นกลุ่มของคำขอ กล่าวคือ คำขอเหล่านั้นจะถูกแยกออก
และหากเราเพิ่มประสิทธิภาพจากบนลงล่าง เราจะแบ่งเบาทรัพยากรของเราและชะลอช่วงเวลาที่เราต้องอัปเกรด นี่เป็นวิธีประหยัดเงินที่ดีมาก
บางทีนี่อาจไม่ใช่วิธีที่ดีในการดูแลผู้ใช้เพราะเราอาจไม่เห็นกรณีที่หายาก แต่น่ารำคาญมากที่บุคคลหนึ่งรอ 15 วินาที โดยรวมแล้วมันหายากมากจนเราไม่เห็นพวกมัน แต่เรากำลังจัดการกับทรัพยากร
เกิดอะไรขึ้นในตารางนี้? เราถ่ายรูปไว้สองภาพ Postgres_checkup จะให้ค่าเดลต้าสำหรับแต่ละเมตริก เช่น เวลารวม การโทร แถว shared_blks_read ฯลฯ เพียงเท่านี้ เดลต้าก็ได้รับการคำนวณแล้ว ปัญหาใหญ่ของ pg_stat_statements คือจำไม่ได้ว่าถูกรีเซ็ตเมื่อใด หาก pg_stat_database จำได้ แสดงว่า pg_stat_statements จะจำไม่ได้ เห็นว่ามีจำนวน 1 แต่เราไม่รู้ว่านับมาจากไหน
และที่นี่เรารู้ ที่นี่เรามีสแนปชอตสองภาพ เรารู้ว่าเดลต้าในกรณีนี้คือ 56 วินาที ช่องว่างที่สั้นมาก จัดเรียงตามเวลาทั้งหมด จากนั้นเราก็สามารถแยกแยะความแตกต่างได้ กล่าวคือ เราแบ่งเมตริกทั้งหมดตามระยะเวลา หากเราแบ่งแต่ละเมตริกตามระยะเวลา เราจะได้จำนวนการโทรต่อวินาที
ถัดไป Total_time ต่อวินาทีเป็นตัวชี้วัดที่ฉันชอบ มีหน่วยวัดเป็นวินาที ต่อวินาที กล่าวคือ ระบบของเราใช้เวลากี่วินาทีในการดำเนินการคำขอกลุ่มนี้ต่อวินาที หากคุณเห็นมากกว่าหนึ่งวินาทีต่อวินาที นั่นหมายความว่าคุณต้องให้คอร์มากกว่าหนึ่งคอร์ นี่เป็นตัวชี้วัดที่ดีมาก คุณสามารถเข้าใจได้ว่าเพื่อนคนนี้ต้องการอย่างน้อยสามคอร์
นี่คือความรู้ของเรา ฉันไม่เคยเห็นอะไรแบบนี้มาก่อนเลย โปรดทราบ - นี่เป็นสิ่งที่ง่ายมาก - วินาทีต่อวินาที บางครั้ง เมื่อ CPU ของคุณเป็น 100% แล้วครึ่งชั่วโมงต่อวินาที นั่นก็คือคุณใช้เวลาครึ่งชั่วโมงในการทำคำขอนี้
ต่อไปเราจะเห็นแถวต่อวินาที เรารู้ว่ามันส่งคืนกี่แถวต่อวินาที
แล้วยังมีสิ่งที่น่าสนใจอีกด้วย จำนวน shared_buffers ที่เราอ่านต่อวินาทีจาก shared_buffers นั้นเอง มีการเข้าชมแล้วและเรานำแถวมาจากแคชของระบบปฏิบัติการหรือจากดิสก์ ตัวเลือกแรกนั้นเร็ว และตัวเลือกที่สองอาจจะเร็วหรือไม่ก็ได้ ขึ้นอยู่กับสถานการณ์
และวิธีที่สองของการสร้างความแตกต่างคือการแบ่งจำนวนคำขอในกลุ่มนี้ ในคอลัมน์ที่สอง คุณจะมีหนึ่งแบบสอบถามที่ถูกแบ่งต่อแบบสอบถามเสมอ แล้วมันก็น่าสนใจ - คำขอนี้มีกี่มิลลิวินาที เรารู้ว่าแบบสอบถามนี้ทำงานอย่างไรโดยเฉลี่ย คำขอแต่ละครั้งต้องใช้เวลา 101 มิลลิวินาที นี่คือตัวชี้วัดแบบดั้งเดิมที่เราต้องเข้าใจ
แบบสอบถามแต่ละรายการส่งคืนโดยเฉลี่ยกี่แถว เราเห็น 8 กลุ่มนี้กลับมา โดยเฉลี่ยแล้ว จะมีการดึงข้อมูลจากแคชและอ่านไปเท่าใด เราเห็นว่าทุกอย่างถูกแคชอย่างดี ฮิตติดลมบนกลุ่มแรก
และสตริงย่อยที่สี่ในแต่ละบรรทัดคือเปอร์เซ็นต์ของทั้งหมด เรามีสาย สมมุติว่า 1 และเราก็เข้าใจว่ากลุ่มนี้ช่วยอะไรได้ เราเห็นว่าในกรณีนี้กลุ่มแรกมีส่วนสนับสนุนน้อยกว่า 000% คือมันช้ามากจนเรามองไม่เห็นในภาพรวมเลย และกลุ่มที่สองคือ 000% สำหรับการโทร นั่นคือ 0,01% ของการโทรทั้งหมดเป็นกลุ่มที่สอง
Total_time ก็น่าสนใจเช่นกัน เราใช้เวลา 14% ของเวลาทำงานทั้งหมดกับคำขอกลุ่มแรก และสำหรับวินาที - 11% เป็นต้น
ฉันจะไม่ลงรายละเอียด แต่มีรายละเอียดปลีกย่อยอยู่ที่นั่น เราแสดงข้อผิดพลาดที่ด้านบน เนื่องจากเมื่อเราเปรียบเทียบ สแนปชอตอาจลอยอยู่ กล่าวคือ คำขอบางรายการอาจหลุดออกไปและไม่สามารถปรากฏในคำขอที่สองได้อีกต่อไป ในขณะที่คำขอใหม่บางคำขออาจปรากฏขึ้น และที่นั่นเราคำนวณข้อผิดพลาด ถ้าเห็น 0 ก็ถือว่าดี ไม่มีข้อผิดพลาด หากอัตราข้อผิดพลาดสูงถึง 20% ก็ไม่เป็นไร
จากนั้นเรากลับไปที่หัวข้อของเรา เราจำเป็นต้องสร้างภาระงาน เราไล่จากบนลงล่างและไปจนกว่าจะถึง 80% หรือ 90% โดยปกติจะเป็น 10-20 กลุ่ม และเราสร้างไฟล์สำหรับ pgbench เราใช้การสุ่มที่นั่น บางครั้งสิ่งนี้โชคไม่ดีที่ไม่ได้ผล และใน Postgres 12 จะมีโอกาสมากขึ้นในการใช้แนวทางนี้
จากนั้นเราจะได้ 80-90% ของเวลาทั้งหมดด้วยวิธีนี้ ฉันควรใส่อะไรต่อจาก "@"? เราดูการโทร ดูว่ามีดอกเบี้ยเท่าไหร่ และเข้าใจว่าเราเป็นหนี้ดอกเบี้ยมากมายที่นี่ จากเปอร์เซ็นต์เหล่านี้ เราสามารถเข้าใจวิธีสร้างสมดุลให้กับแต่ละไฟล์ได้ หลังจากนั้นเราใช้ pgbench และไปทำงาน
เรายังมี K001 และ K002.
K001 คือสตริงใหญ่หนึ่งสตริงที่มีสี่สตริงย่อย นี่เป็นลักษณะของภาระทั้งหมดของเรา ดูคอลัมน์ที่สองและแถวย่อยที่สอง เราจะเห็นว่าประมาณหนึ่งวินาทีครึ่งต่อวินาที เช่น ถ้ามีสองคอร์ก็คงจะดี จะมีความจุประมาณ 75% และมันจะทำงานเช่นนี้ ถ้าเรามี 10 คอร์ เราก็จะสงบโดยทั่วไป วิธีนี้ทำให้เราสามารถประเมินทรัพยากรได้
K002 คือสิ่งที่ฉันเรียกว่าคลาสคิวรี เช่น SELECT, INSERT, UPDATE, DELETE และแยก SELECT FOR UPDATE เพราะเป็นการล็อค
และที่นี่เราสามารถสรุปได้ว่า SELECT เป็นผู้อ่านทั่วไป - 82% ของการโทรทั้งหมด แต่ในขณะเดียวกัน - 74% ใน Total_time นั่นคือเรียกว่ามาก แต่ใช้ทรัพยากรน้อยลง
และเรากลับมาที่คำถาม: “เราจะเลือก shared_buffers ที่ถูกต้องได้อย่างไร” ฉันสังเกตเห็นว่าเกณฑ์มาตรฐานส่วนใหญ่ขึ้นอยู่กับแนวคิดนี้ มาดูกันว่าปริมาณงานจะเป็นอย่างไร กล่าวคือ ปริมาณงานจะเป็นอย่างไร โดยปกติจะวัดเป็น TPS หรือ QPS
และเราพยายามบีบธุรกรรมออกจากรถให้ได้มากที่สุดต่อวินาทีโดยใช้พารามิเตอร์การปรับแต่ง นี่คือ 311 ต่อวินาทีสำหรับการเลือก
แต่ไม่มีใครขับรถไปทำงานและกลับบ้านด้วยความเร็วสูงสุด นี่เป็นเรื่องโง่ เช่นเดียวกับฐานข้อมูล เราไม่จำเป็นต้องขับด้วยความเร็วสูงสุด และไม่มีใครทำ ไม่มีใครอยู่ในการผลิตซึ่งมี CPU 100% แม้ว่าอาจมีบางคนมีชีวิตอยู่ แต่ก็ไม่ดี
แนวคิดก็คือเรามักจะขับที่ 20 เปอร์เซ็นต์ของความจุ โดยไม่ควรเกิน 50% และเราพยายามปรับเวลาตอบสนองให้เหมาะสมสำหรับผู้ใช้ของเราเหนือสิ่งอื่นใด นั่นคือเราต้องหมุนปุ่มเพื่อให้มีเวลาแฝงขั้นต่ำที่ความเร็ว 20% ตามเงื่อนไข นี่เป็นแนวคิดที่เราพยายามใช้ในการทดลองของเราด้วย
และสุดท้าย คำแนะนำ:
- อย่าลืมทำ Database Lab
- หากเป็นไปได้ ให้ทำตามความต้องการเพื่อให้มันกางออกสักพัก - เล่นแล้วโยนทิ้งไป หากคุณมีเมฆ สิ่งนี้ก็ดำเนินไปโดยไม่บอกกล่าว นั่นคือ มีจุดยืนมากมาย
- อยากรู้อยากเห็น. และหากมีสิ่งผิดปกติ ให้ตรวจสอบกับการทดลองว่ามันทำงานอย่างไร แนนซี่สามารถใช้เพื่อฝึกฝนตัวเองเพื่อตรวจสอบว่าฐานทำงานอย่างไร
- และมุ่งเป้าไปที่เวลาตอบสนองขั้นต่ำ
- และอย่ากลัวแหล่งที่มาของ Postgres เมื่อคุณทำงานกับแหล่งข้อมูล คุณต้องรู้ภาษาอังกฤษ มีความคิดเห็นมากมาย มีการอธิบายทุกอย่างที่นั่น
- และตรวจสอบความสมบูรณ์ของฐานข้อมูลอย่างสม่ำเสมอ อย่างน้อยทุกๆ สามเดือน ด้วยตนเอง หรือการตรวจ Postgres
คำถาม
ขอบคุณมาก! สิ่งที่น่าสนใจมาก
สองชิ้น.
ใช่สองชิ้น เพียงแต่ฉันไม่ค่อยเข้าใจ เมื่อฉันกับแนนซี่ทำงาน เราสามารถปรับแต่งพารามิเตอร์เพียงตัวเดียวหรือทั้งกลุ่มได้หรือไม่
เรามีพารามิเตอร์การกำหนดค่าเดลต้า คุณสามารถเลี้ยวไปที่นั่นได้มากเท่าที่คุณต้องการในคราวเดียว แต่คุณต้องเข้าใจว่าเมื่อคุณเปลี่ยนแปลงอะไรมากมายคุณสามารถสรุปผลที่ผิดได้
ใช่. ทำไมฉันถึงถาม? เนื่องจากเป็นการยากที่จะทำการทดลองเมื่อคุณมีพารามิเตอร์เพียงตัวเดียว คุณกระชับมันขึ้น ดูว่ามันทำงานอย่างไร ฉันไล่เขาออกไป จากนั้นคุณเริ่มอันถัดไป
คุณสามารถกระชับได้ในเวลาเดียวกัน แต่แน่นอนว่าขึ้นอยู่กับสถานการณ์ด้วย แต่เป็นการดีกว่าที่จะทดสอบแนวคิดเดียว เมื่อวานเรามีไอเดีย เรามีสถานการณ์ที่ใกล้ชิดมาก มีการกำหนดค่าสองแบบ และเราไม่เข้าใจว่าทำไมถึงมีความแตกต่างใหญ่ และเกิดแนวคิดขึ้นว่าคุณจำเป็นต้องใช้การแบ่งขั้วเพื่อทำความเข้าใจและค้นหาความแตกต่างอย่างสม่ำเสมอ คุณสามารถทำให้พารามิเตอร์ครึ่งหนึ่งเหมือนเดิมได้ทันที จากนั้นหนึ่งในสี่ ฯลฯ ทุกอย่างมีความยืดหยุ่น
และยังมีอีกคำถามหนึ่ง โครงการนี้ยังใหม่และมีการพัฒนา เอกสารพร้อมแล้ว มีคำอธิบายโดยละเอียดหรือไม่?
ฉันสร้างลิงก์ไว้ที่นั่นโดยเฉพาะเพื่ออธิบายพารามิเตอร์ มันอยู่ที่นั่น. แต่หลายอย่างยังไม่มีเลย ฉันกำลังมองหาคนที่มีใจเดียวกัน และฉันก็พบพวกเขาเมื่อฉันแสดง นี่มันเจ๋งมาก มีคนทำงานร่วมกับฉันอยู่แล้วมีคนช่วยและทำอะไรบางอย่างที่นั่น และหากคุณสนใจหัวข้อนี้ แสดงความคิดเห็นเกี่ยวกับสิ่งที่ขาดหายไป
เมื่อเราสร้างห้องปฏิบัติการแล้ว อาจจะมีการตอบรับกลับมา มาดูกัน. ขอบคุณ!
สวัสดี! ขอบคุณสำหรับรายงาน! ฉันเห็นว่ามีการสนับสนุนของ Amazon มีแผนจะสนับสนุน GSP หรือไม่?
คำถามที่ดี. เราเริ่มทำมัน และเราแช่แข็งมันไว้ก่อนเพราะเราต้องการประหยัดเงิน นั่นคือมีการรองรับการใช้ run บน localhost คุณสามารถสร้างอินสแตนซ์ได้ด้วยตัวเองและทำงานภายในเครื่องได้ ยังไงก็ตามนั่นคือสิ่งที่เราทำ ฉันทำสิ่งนี้ที่ Getlab ที่นั่นที่ GSP แต่เรายังไม่เห็นประเด็นในการประสานข้อมูลดังกล่าว เนื่องจาก Google ไม่มีจุดราคาถูก มี ??? บ้างแต่ก็มีข้อจำกัด ประการแรก พวกเขามักจะมีส่วนลดเพียง 70% และคุณไม่สามารถเล่นกับราคาที่นั่นได้ ณ จุดนั้น เราเพิ่มราคา 5-10% เพื่อลดโอกาสที่คุณจะถูกเตะ นั่นคือคุณบันทึกจุดต่างๆ แต่สามารถนำจุดเหล่านั้นไปจากคุณได้ตลอดเวลา หากคุณเสนอราคาสูงกว่าคนอื่นเล็กน้อย คุณจะถูกฆ่าในภายหลัง Google มีลักษณะเฉพาะที่แตกต่างไปจากเดิมอย่างสิ้นเชิง และยังมีข้อจำกัดที่แย่มากอีกประการหนึ่งคือ พวกมันมีชีวิตอยู่ได้เพียง 24 ชั่วโมงเท่านั้น และบางครั้งเราต้องการทำการทดสอบเป็นเวลา 5 วัน แต่คุณสามารถทำได้เฉพาะจุด บางจุดอาจอยู่ได้นานหลายเดือน
สวัสดี! ขอบคุณสำหรับรายงาน! คุณกล่าวถึงการตรวจสุขภาพ คุณจะคำนวณข้อผิดพลาด stat_statements ได้อย่างไร
คำถามที่ดีมาก ฉันสามารถแสดงและบอกคุณได้อย่างละเอียด โดยสรุป เราจะดูว่าชุดของกลุ่มคำขอลอยไปอย่างไร มีกี่กลุ่มที่หลุดออกไปและมีกลุ่มใหม่ปรากฏขึ้นกี่กลุ่ม จากนั้นเราจะดูที่เมตริก XNUMX รายการ ได้แก่ เวลาทั้งหมดและการโทร จึงมีข้อผิดพลาด XNUMX รายการ และเราดูการมีส่วนร่วมของกลุ่มลอย มีสองกลุ่มย่อยคือผู้ที่จากไปและผู้ที่มาถึง เรามาดูกันว่าการมีส่วนร่วมของพวกเขาคืออะไรในภาพรวม
คุณไม่กลัวว่ามันจะพลิกกลับตรงนั้นสองหรือสามครั้งในระหว่างช่วงเวลาระหว่างการถ่ายภาพใช่ไหม
คือได้ลงทะเบียนใหม่หรืออะไร?
ตัวอย่างเช่น คำขอนี้ถูกจองไว้แล้วครั้งหนึ่ง จากนั้นมาและถูกจองอีกครั้ง จากนั้นมาอีกครั้งและถูกจองอีกครั้ง และคุณคำนวณบางอย่างที่นี่ แล้วทั้งหมดอยู่ที่ไหน?
เป็นคำถามที่ดี เราจะต้องดู
ฉันทำสิ่งที่คล้ายกัน มันง่ายกว่าแน่นอนฉันทำคนเดียว แต่ฉันต้องรีเซ็ต รีเซ็ต stat_statements และหาว่า ณ เวลาที่ทำสแนปชอตว่ามีเศษส่วนน้อยกว่าจำนวนหนึ่ง ซึ่งยังไปไม่ถึงเพดานว่าจะสะสม stat_statements ได้มากน้อยเพียงใด และความเข้าใจของฉันก็คือ เป็นไปได้มากว่าไม่มีอะไรถูกแทนที่
ใช่ ๆ.
แต่ฉันไม่เข้าใจวิธีการอื่นที่จะทำได้อย่างน่าเชื่อถือ
น่าเสียดายที่ฉันจำไม่ได้แน่ชัดว่าเราใช้ข้อความค้นหาที่นั่นหรือ queryid ด้วย pg_stat_statements และมุ่งเน้นไปที่ข้อความนั้น หากเรามุ่งเน้นไปที่ queryid ในทางทฤษฎีแล้วเรากำลังเปรียบเทียบสิ่งที่เทียบเคียงได้
ไม่ เขาสามารถถูกบังคับออกได้หลายครั้งระหว่างการถ่ายภาพสแนปช็อตแล้วกลับมาอีกครั้ง
ด้วยไอดีเดียวกันเหรอ?
ใช่
เราจะศึกษาเรื่องนี้ คำถามที่ดี. เราจำเป็นต้องศึกษามัน แต่สำหรับตอนนี้ที่เราเห็นเขียนว่า 0...
แน่นอนว่านี่เป็นกรณีที่หายาก แต่ฉันก็ตกใจเมื่อพบว่า stat_statemetns สามารถแทนที่ที่นั่นได้
สามารถมีได้หลายอย่างใน Pg_stat_statements เราพบว่าหากคุณเปิด track_utility = ไว้ ชุดของคุณก็จะถูกติดตามเช่นกัน
ใช่แน่นอน
และถ้าคุณมีจาวาไฮเบอร์เนตซึ่งเป็นแบบสุ่ม ตารางแฮชจะเริ่มอยู่ที่นั่น และทันทีที่คุณปิดแอปพลิเคชั่นที่โหลดมาก คุณจะมีกลุ่ม 50-100 กลุ่ม และทุกอย่างก็มีเสถียรภาพไม่มากก็น้อย วิธีหนึ่งในการแก้ไขปัญหานี้คือการเพิ่ม pg_stat_statements.max
ใช่ แต่คุณต้องรู้ว่าเท่าไหร่ และเราต้องจับตาดูเขาให้ดี นั่นคือสิ่งที่ฉันทำ. นั่นคือฉันมี pg_stat_statements.max และฉันเห็นว่าตอนที่ถ่ายภาพนั้นฉันยังไม่ถึง 70% เอาล่ะ เราไม่ได้สูญเสียอะไรไป มารีเซ็ตกันเถอะ และเราก็บันทึกอีกครั้ง หากสแนปชอตถัดไปน้อยกว่า 70 เป็นไปได้มากว่าคุณไม่ได้สูญเสียสิ่งใดอีก
ใช่. ค่าเริ่มต้นคือ 5 และนี่ก็เพียงพอแล้วสำหรับหลายๆ คน
ปกติแล้วใช่
วิดีโอ:
ป.ล. ในนามของฉันเอง ฉันจะเสริมว่าหาก Postgres มีข้อมูลที่เป็นความลับและไม่สามารถรวมไว้ในสภาพแวดล้อมการทดสอบได้ คุณสามารถใช้ . โครงการมีประมาณดังนี้:
ที่มา: will.com