10

ในบทความ Computer World นี้ระบุว่า PostgreSQL สามารถขยายได้ถึงขีด จำกัด หลักที่ 64 สิ่งนี้หมายความว่าสำหรับตัวประมวลผลแบบมัลติคอร์หนึ่งคอร์ 64 คอร์หรือไม่? หรือโปรเซสเซอร์หลายตัวที่มีคอร์น้อยลง?

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

ความคิดใด ๆ ที่จะได้รับการชื่นชมมาก ขอบคุณ!

database postgresql scalability

— O_O
แหล่งที่มา

1

PostgreSQL ไม่สนใจว่าจะเป็นซีพียู 8-core 8 ตัว, ซีพียู 2-core 32 ตัวหรืออะไรก็ตาม มันสนใจเฉพาะตัวประมวลผลเชิงตรรกะเท่านั้น นอกจากนี้ 64 คอร์ยังเป็นค่าประมาณและขึ้นอยู่กับฮาร์ดแวร์อื่น ๆ ของคุณ 64 คอร์จะไม่ทำอะไรที่ดีถ้าคุณมี RAM เพียง 4GB สำหรับฐานข้อมูล 1TB บนฮาร์ดไดรฟ์ SATA 7200rpm ไม่มีข้อ จำกัด ทางเทคนิคอย่างหนักเกี่ยวกับตัวเลขหลักเพียงว่าเพิ่งได้รับการทดสอบและพิสูจน์แล้วว่าสามารถขยายได้ถึง 64

— Craig Ringer

7

ไม่มันเป็นสถิติที่แม่นยำมาก "หน่วยประมวลผลเชิงตรรกะ" เป็นแกนหลัก และแกนกลางก็คือมันไม่สำคัญว่ามันจะแพร่กระจายไปยังโปรเซสเซอร์ทางกายภาพอย่างไร

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

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

_{* 2017 ปรับปรุง: บางคำสั่ง (หรือ subqueries) อาจจะดำเนินการในแบบคู่ขนาน}

— Oli
แหล่งที่มา

1

Needless to say this also means you should put your money in faster cores than quantity of cores unless you want to cluster things in a more complicated method.

<- ฉันเห็นด้วยกับคำสั่งนี้เฉพาะถ้าจำนวนของคอร์มากกว่าจำนวนของลูกค้าที่เกิดขึ้นพร้อมกันและจำนวนของลูกค้าที่เกิดขึ้นพร้อมกันนั้นไม่น่าจะเพิ่มขึ้น มันค่อนข้างสำคัญที่ประสิทธิภาพจะมีแกนกลางสำหรับแบ็กเอนด์ Postgres แต่ละตัว ...

— voretaq7

@ voretaq7 ฉันเห็นด้วยเป็นส่วนใหญ่ แต่ CPU ที่มี TPS ที่สูงกว่าสามารถ (เห็นได้ชัด) สามารถจัดการธุรกรรมได้มากขึ้นในเวลาที่กำหนดดังนั้นลูกค้าจึงมาก จะมีจุดที่น่าสนใจซึ่งขึ้นอยู่กับประเภทโหลดและงบประมาณของคุณ

— Oli

1

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

— dyasny

2

@ voretaq7: ไม่ใช่เรื่องแปลกที่จะเชื่อมต่อกับ postgresql ผ่านกลไกการรวมการเชื่อมต่อบางอย่าง ในหมู่ผู้อื่นนี้จะทำเพราะการเชื่อมต่อกับ postgresql ค่อนข้างแพง การรวมกำไรสามารถลดจำนวนการเชื่อมต่อไปยังฐานข้อมูลพร้อมกันอย่างมาก ดังนั้นฉันมักจะชอบซีพียูเร็วมากกว่า # ของคอร์ แต่เช่นเคย: ขึ้นอยู่กับปัจจัยหลายอย่าง ...

— m.sr

2

@ m.sr เห็นด้วย - กลไกการรวมการเชื่อมต่อเป็นเรื่องธรรมดามาก "สิ่งที่ฉลาดที่สุด" เหล่านี้จะทำให้การเชื่อมต่อกับ Postgres และความสมดุลในหมู่พวกเขาเร็วขึ้น (หนึ่งในแอพภายในของเราทำโดยให้แต่ละกระบวนการของ Apache เชื่อมต่อกับ Postgres - การทำแผนที่ที่สะดวกสำหรับกรณีใช้งานของเรา อัตราส่วนต่อผู้ใช้) IMHO ถ้าเชื่อมต่อร่วมกันของคุณจะทำให้คำสั่งคิวขึ้นมากกว่าวางไข่แบ็กเอนด์ก็ไม่ได้ทำคุณโปรดปรานใด ๆ แต่ข้อดีและข้อเสียของการที่จะเป็นที่น่าสนใจอื่น ๆ อีกมากมายที่จะเจาะลึกเกี่ยวกับผู้ดูแลระบบฐานข้อมูล ดังนั้นฉันถาม!

— voretaq7

12

Postgres สามารถปรับขนาดตัวประมวลผลได้มากเท่าที่คุณต้องการติดตั้งและระบบปฏิบัติการของคุณสามารถจัดการ / จัดการได้อย่างมีประสิทธิภาพ คุณสามารถติดตั้ง Postgres บนเครื่องหลัก 128 เครื่อง (หรือแม้กระทั่งเครื่องที่มีตัวประมวลผลทางกายภาพ 128 เครื่อง) และมันจะทำงานได้ดี มันอาจทำงานได้ดีกว่าบนเครื่อง 64 คอร์หากตัวกำหนดตารางการทำงานของ OS สามารถจัดการกับแกนหลักหลาย ๆ

Postgres ได้รับการแสดงขนาด เส้นตรงได้ถึง 64 แกน (ที่มีคำเตือน: เรากำลังพูดถึงเกี่ยวกับประสิทธิภาพการอ่านในการกำหนดค่าที่เฉพาะเจาะจง (ดิสก์, RAM, OS, ฯลฯ ) - โรเบิร์ตฮาสมีบทความบล็อกกับกราฟที่ดีที่ ฉันทำซ้ำด้านล่าง:

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

กราฟนี้สำคัญกับอะไร

ความสัมพันธ์นั้นเป็นแบบเส้นตรง (หรือเกือบจะเป็นอย่างนั้น) ตราบใดที่จำนวนลูกค้าน้อยกว่าหรือเท่ากับจำนวนแกนแล้วเริ่มสิ่งที่ดูเหมือนว่าจะลดลงในเชิงเส้นของประสิทธิภาพในขณะที่คุณมีการเชื่อมต่อลูกค้ามากกว่าคุณ ทำแกนเพื่อรันแบ็กเอนด์ Postgres เพราะแบ็กเอนด์เริ่มต่อสู้เพื่อ CPU (ค่าเฉลี่ยการโหลดสูงกว่า 1.0 ฯลฯ ... )

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

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

— voretaq7
แหล่งที่มา

2

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

— voretaq7

2

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

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

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

ฉันชี้เฉพาะสิ่งนี้เพราะ OP กำลังพูดถึงคำถามเกี่ยวกับความสามารถในการปรับขนาดได้ซึ่งโดยทั่วไปคำตอบนั้นเหมาะสมกว่า "โปรแกรม X สามารถใช้แกนประมวลผล Y"

— ทิม
แหล่งที่มา

1

ในกรณีนี้พวกเขาหมายถึงโปรเซสเซอร์หลายตัวที่มีคอร์น้อยลง ... การพูดคุยบางอย่างเป็นการพิสูจน์ในอนาคต บางคนพูดการตลาด

— ewwhite
แหล่งที่มา

PostgreSQL ปรับขนาด 64 คอร์หรือไม่

กราฟนี้สำคัญกับอะไร