10/20 / 40Gbps nginx ไฟล์ขนาดใหญ่แคชเว็บเซิร์ฟเวอร์ [ถึง 20Gbps]


10

ฉันต้องการค้นหาการกำหนดค่า / ฮาร์ดแวร์ที่ดีที่สุดที่เป็นไปได้ในการส่งมอบ 40Gbps จากเซิร์ฟเวอร์เดียวในคำถามนี้

สถานการณ์

เรามีพร็อกซีเซิร์ฟเวอร์แชร์วิดีโอที่ช่วยลดยอดเขาจากเซิร์ฟเวอร์จัดเก็บข้อมูลช้าที่อยู่ด้านหลัง การรับส่งข้อมูลทั้งหมดเป็น HTTP เท่านั้น เซิร์ฟเวอร์ทำหน้าที่เป็นพร็อกซีย้อนกลับ (ไฟล์ที่ไม่ได้เก็บไว้ในเซิร์ฟเวอร์) และเว็บเซิร์ฟเวอร์ (ไฟล์ที่เก็บไว้ในไดรฟ์ในระบบ)

ขณะนี้มีบางอย่างเช่นไฟล์ 100TB และเติบโตบนเซิร์ฟเวอร์หน่วยเก็บข้อมูลส่วนหลัง

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

เป้าหมาย

รับ 40Gbps หรือปริมาณงานที่มากขึ้นจากเครื่องเดียว

ฮาร์ดแวร์ 1

HW: Supermicro SC825, X11SSL-F, Xeon E3-1230v5 (4C/8T@3.4GHz), 16GB DDR4 RAM, 2x Supermicro 10G STGN-i1S (LACP L3 + 4)

SSD: 1x 512GB Samsung, 2x 500GB Samsung, 2x480GB Intel 535, 1x 240GB Intel S3500

ระบบ:

  • irqbalancer หยุดทำงาน
  • set_irq_affinity สำหรับแต่ละอินเตอร์เฟส (ผ่านสคริปต์ใน tarx driver ixgbe)
  • ixgbe-4.3.15
  • กำหนดเวลา I / O กำหนดเวลา
  • iptables ว่างเปล่า (โมดูลที่ไม่ได้โหลด)
  • ระบบไฟล์: XFS

Nginx:

  • sendfile ปิด
  • หัวข้อ aio
  • directio 1 ล
  • tcp_nopush บน
  • tcp_nodelay บน

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

เท่าที่เห็นในกราฟเราสามารถผลักดัน 12.5Gbps น่าเสียดายที่เซิร์ฟเวอร์ไม่ตอบสนอง

มี 2 ​​สิ่งที่ทำให้ฉันสนใจ อันแรกคือ IRQ ปริมาณสูง ในกรณีนี้ฉันไม่มีกราฟจาก / proc / ขัดจังหวะ สิ่งที่สองคือโหลดระบบสูงซึ่งฉันคิดว่าเกิดจาก kswapd0 มีปัญหาในการทำงานกับ RAM 16G เท่านั้น

ฮาร์ดแวร์ 2

HW: Supermicro SC119TQ, X10DRW-i, 2x Xeon E5-2609v4 (8C/8T@1.70GHz), RAM DDR4 128GB, 2x Supermicro 10G STGN-i1S

SSD, การกำหนดค่าระบบเหมือนกับฮาร์ดแวร์ 1. Nginx เปิดใช้ sendfile (aio / sendfile เปรียบเทียบเพิ่มเติม)

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

ดูเหมือนจะดีกว่าตอนนี้เมื่อเรามีเซิร์ฟเวอร์ซึ่งทำงานได้ดีเราสามารถลองเพิ่มประสิทธิภาพได้

Sendfile vs aio threads

ฉันพยายามปิดการใช้งาน sendfile และใช้เธรด aio แทน

  • sendfile ปิด
  • หัวข้อ aio
  • directio 1M (ซึ่งตรงกับไฟล์ทั้งหมดที่เรามี)

VS

  • เปิดไฟล์

จากนั้นเวลา 15:00 นฉันเปลี่ยนกลับไปเป็น sendfile และโหลดใหม่ nginx (ดังนั้นจึงใช้เวลาสักครู่เพื่อสิ้นสุดการเชื่อมต่อที่มีอยู่) เป็นเรื่องดีที่การใช้งานไดรฟ์ (วัดโดย iostat) ลดลง ไม่มีอะไรเปลี่ยนแปลงกับปริมาณการใช้งาน (น่าเสียดายที่ zabbix ตัดสินใจที่จะไม่รวบรวมข้อมูลจาก bond0)

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

sendfile เปิด / ปิด

เพียงแค่พยายามเปลี่ยนเปิด / ปิดการส่ง ไม่มีอะไรเปลี่ยนแปลงยกเว้นการขัดจังหวะการกำหนดเวลาใหม่

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

irqbalancer เป็นเซิร์ฟเวอร์ / cron / ปิดใช้งาน

ดังที่ @lsd กล่าวว่าฉันพยายามตั้งค่า irqbalancer ให้ดำเนินการผ่าน cron:

*/5 * * * *   root    /usr/sbin/irqbalance --oneshot --debug 3 > /dev/null

น่าเสียดายที่มันไม่ได้ช่วยในกรณีของฉัน หนึ่งในการ์ดเครือข่ายเริ่มทำงานผิดปกติ:

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

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

ฉันพยายามเริ่ม irqbalance เป็นบริการผลลัพธ์ยังคงเหมือนเดิม

จากนั้นฉันตัดสินใจใช้สคริปต์ set_irq_affinity และแก้ไขปัญหาได้ทันทีและเซิร์ฟเวอร์ผลัก 17Gbps อีกครั้ง

ฮาร์ดแวร์ 3

เราได้อัพเกรดเป็นฮาร์ดแวร์ใหม่: 2U 24 (+2) ไดรฟ์แชสซี (6xSFF), 2x Xeon E5-2620v4, 64GB DDR4 RAM (โมดูล 4x16GB), 13x SSD, 2x Supermicro (พร้อมชิป Intel) CPU ใหม่ปรับปรุงประสิทธิภาพมากขึ้น

การตั้งค่าปัจจุบันยังคงอยู่ - sendfile ฯลฯ ความแตกต่างเพียงอย่างเดียวคือเราให้ CPU เพียงตัวเดียวจัดการการ์ดเครือข่ายทั้งสอง (ผ่านสคริปต์ set_irq_affinity)

ถึงขีด จำกัด 20Gbps แล้ว

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

เป้าหมายต่อไปหรือไม่ 30Gbps


รู้สึกอิสระที่จะยิงมาที่ฉันความคิดวิธีการปรับปรุงประสิทธิภาพ ฉันยินดีที่จะทดสอบมันแบบสดๆและแบ่งปันกราฟหนัก ๆ ที่นี่

ความคิดใดที่จะจัดการกับ SoftIRQs จำนวนมากบน cpu ได้บ้าง?

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



4
คุณพูดแบบนี้ไม่ได้เกี่ยวกับการวางแผนกำลังการผลิต แต่ดูเหมือนว่าฉันพยายามที่จะผลัก 40 Gbps ผ่านเซิร์ฟเวอร์เดียวเป็นการบ่งบอกถึงปัญหาด้านความจุ
ceejayoz

5
ที่น่าสนใจเพียงอย่างเดียวในงานเก่าพวกเขาปิดการให้บริการความไม่สมดุล แต่ยังคงทำงาน cron ที่วิ่งความไม่สมดุลทุก ๆ 15 นาที ดังนั้นเราจึงยังได้รับประโยชน์จากความไม่สมดุลไม่ใช่เพียงความถี่ของการบริการ
lsd

อัปเดต: เพิ่มการทดสอบเปิด / ปิด sendfile @lsd: ฉันจะพยายามใช้ irqbalance เป็นแบบสแตนด์อโลนผ่าน cron ในสัปดาห์หน้า เรามาดูกันว่าผลกระทบจะเป็นอย่างไร
Yarik Dot

1
คุณใช้ทำกราฟอะไร
จอห์นนี่ V

คำตอบ:


9

คำแถลงการณ์ปฏิเสธความรับผิดชอบ : คำแนะนำเดียวกันนี้ใช้กับบริการทั้งหมดที่ผลักดันมากกว่า 10Gbps รวม แต่ไม่ จำกัด เฉพาะการโหลดบาลานเซอร์แคชเซิร์ฟเวอร์เซิร์ฟเวอร์ (HAProxy, วานิช, nginx, ทอมแคท, ... )

สิ่งที่คุณต้องการทำผิดอย่าทำ

ใช้ CDN แทน

CDN มีวัตถุประสงค์เพื่อส่งมอบเนื้อหาคงที่ที่สามารถเข้าถึงได้ ใช้เครื่องมือที่เหมาะสมสำหรับงาน (akamai, MaxCDN, cloudflare, cloudfront, ... )

CDN ใด ๆ ก็ตามที่เป็นของฟรีจะทำได้ดีกว่าสิ่งที่คุณทำได้ด้วยตัวเอง

ปรับสเกลแนวนอนแทน

ฉันคาดว่าเซิร์ฟเวอร์เดียวจะจัดการ 1-5Gbps ออกไปนอกกล่องโดยไม่ต้องปรับแต่งมากนัก (หมายเหตุ: ให้บริการไฟล์คงที่เท่านั้น) 8-10Gbps มักจะอยู่ในอุ้งมือด้วยการจูนขั้นสูง

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

เรียกใช้กล่องเดียวลองทำสิ่งต่าง ๆ วัดมาตรฐานเพิ่มประสิทธิภาพ ... จนกว่ากล่องนั้นจะเชื่อถือได้และเชื่อถือได้และมีการกำหนดความสามารถเป็นอย่างดี

มีตัวเลือกการทำโหลดบาลานซ์ทั่วโลกอยู่สองสามตัว: CDN ส่วนใหญ่สามารถทำได้, DNS roundrobin, ELB / Google load balancer ...

ลองเพิกเฉยต่อแนวปฏิบัติที่ดีและทำมันต่อไป

ทำความเข้าใจกับรูปแบบการรับส่งข้อมูล

            WITHOUT REVERSE PROXY

[request ]  user ===(rx)==> backend application
[response]  user <==(tx)===     [processing...]

มีสองสิ่งที่ต้องพิจารณา: แบนด์วิดท์และทิศทาง (การปล่อยหรือการรับ)

ไฟล์ขนาดเล็กคือ 50/50 tx / rx เนื่องจากส่วนหัว HTTP และโอเวอร์เฮด TCP มีขนาดใหญ่กว่าเนื้อหาไฟล์

ไฟล์ขนาดใหญ่คือ 90/10 tx / rx เนื่องจากขนาดคำขอนั้นเล็กน้อยเมื่อเทียบกับขนาดการตอบกลับ

            WITH REVERSE PROXY

[request ]  user ===(rx)==> nginx ===(tx)==> backend application
[response]  user <==(tx)=== nginx <==(rx)===     [processing...]

reverse proxy กำลังถ่ายทอดข้อความทั้งหมดในทั้งสองทิศทาง โหลดอยู่เสมอ 50/50 และปริมาณการใช้งานทั้งหมดจะเพิ่มเป็นสองเท่า

มันซับซ้อนมากขึ้นเมื่อเปิดใช้งานการแคช คำขออาจถูกโอนไปยังฮาร์ดไดรฟ์ซึ่งข้อมูลอาจถูกแคชในหน่วยความจำ

หมายเหตุ : ฉันจะเพิกเฉยต่อแง่มุมแคชในโพสต์นี้ เราจะมุ่งเน้นไปที่การรับ 10-40 Gbps บนเครือข่าย การทราบว่าข้อมูลมาจากแคชและการเพิ่มประสิทธิภาพแคชนั้นเป็นอีกหัวข้อหนึ่งหรือไม่

ข้อ จำกัด Monocore

Load balancing เป็นแบบ monocore (โดยเฉพาะ TCP balancing) การเพิ่มคอร์ไม่ได้ทำให้เร็วขึ้น แต่ก็สามารถทำให้ช้าลงได้

เช่นเดียวกับการปรับสมดุล HTTP ด้วยโหมดง่าย ๆ (เช่น IP, URL, คุกกี้ตามพร็อกซีย้อนกลับอ่านส่วนหัวได้ทันทีไม่แยกวิเคราะห์หรือประมวลผลคำขอ HTTP ในความหมายที่เข้มงวด)

ในโหมด HTTPS การถอดรหัส / การเข้ารหัส SSL จะเข้มข้นกว่าทุกอย่างที่จำเป็นสำหรับการใช้พร็อกซี่ ปริมาณการใช้งาน SSL สามารถและควรแบ่งมากกว่าหลายแกน

SSL

ระบุว่าคุณทำทุกอย่างผ่าน SSL คุณจะต้องการเพิ่มประสิทธิภาพส่วนนั้น

การเข้ารหัสและถอดรหัส 40 Gbps ในทันทีนั้นเป็นความสำเร็จ

ใช้โปรเซสเซอร์รุ่นล่าสุดพร้อมกับคำแนะนำ AES-NI (ใช้สำหรับการดำเนินงาน SSL)

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

IRQ และการปักหมุดหลัก

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

มันเป็นผู้บริโภค CPU ที่ยิ่งใหญ่ที่สุดที่มีแพ็คเก็ตหลายพันล้านออกไปในทุกทิศทาง

กำหนดหมายเลข IRQ ของการ์ดเครือข่ายให้เป็นเอกลักษณ์และปักหมุดลงในแกนหลักที่เฉพาะเจาะจง (ดูการตั้งค่า linux หรือ BIOS)

ปักหมุดพร็อกซีย้อนกลับไปยังคอร์อื่น เราไม่ต้องการรบกวนสองสิ่งนี้

อะแดปเตอร์อีเธอร์เน็ต

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

ลืมเกี่ยวกับอะแดปเตอร์ในตัวบนเมนบอร์ด (ไม่สำคัญว่าเซิร์ฟเวอร์หรือเมนบอร์ดสำหรับผู้บริโภค) พวกเขาแค่ดูด

การถ่าย TCP

TCP เป็นโปรโตคอลที่เข้มข้นมากในแง่ของการประมวลผล (checksums, ACK, retransmission, reassembling packets, ... ) เคอร์เนลจัดการงานส่วนใหญ่ แต่การดำเนินการบางอย่างสามารถถ่ายลงในการ์ดเครือข่ายได้

เราไม่ต้องการเพียงแค่การ์ดที่ค่อนข้างเร็วเราต้องการการ์ดที่มีทั้งเสียงระฆังและเสียงดัง

ลืมเรื่อง Intel, Mellanox, Dell, HP ไปได้ทุกอย่าง พวกเขาไม่สนับสนุนทั้งหมด

มีเพียงตัวเลือกเดียวเท่านั้นบนโต๊ะ: SolarFlare - อาวุธลับของ บริษัท HFT และ CDN

โลกแบ่งออกเป็นสองคน: " คนที่รู้จัก SolarFlare " และ " คนที่ไม่รู้จัก " (ชุดแรกเทียบเท่าอย่างเคร่งครัดกับ " คนที่ทำเครือข่าย 10 Gbps และใส่ใจทุกบิต ") แต่ฉันพูดนอกเรื่องให้มุ่งเน้น: D

ปรับเคอร์เนล TCP

มีตัวเลือกsysctl.confสำหรับบัฟเฟอร์เครือข่ายเคอร์เนล การตั้งค่าเหล่านี้ทำอะไรหรือไม่ทำ ฉันไม่รู้จริงๆ

net.core.wmem_max
net.core.rmem_max
net.core.wmem_default
net.core.rmem_default

net.ipv4.tcp_mem
net.ipv4.tcp_wmem
net.ipv4.tcp_rmem

การเล่นโดยใช้การตั้งค่าเหล่านี้เป็นสัญญาณที่ชัดเจนของการปรับให้เหมาะสมมากที่สุด

เป็นพิเศษซึ่งอาจสมเหตุสมผลเนื่องจากข้อกำหนดที่รุนแรง

(หมายเหตุ: 40Gbps ในกล่องเดียวคือการปรับให้เหมาะสมมากเกินไปเส้นทางที่เหมาะสมคือการปรับขนาดในแนวนอน)

ข้อ จำกัด ทางกายภาพบางอย่าง

แบนด์วิดธ์หน่วยความจำ

ตัวเลขบางอย่างเกี่ยวกับแบนด์วิดท์หน่วยความจำ (ส่วนใหญ่เป็น GB / s): http://www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

สมมติว่าช่วงคือ 150-300 Gbps สำหรับแบนด์วิดท์หน่วยความจำ (ขีด จำกัด สูงสุดในสภาพที่เหมาะสมที่สุด)

แพ็คเก็ตทั้งหมดจะต้องอยู่ในหน่วยความจำในบางจุด เพียงการนำเข้าข้อมูลที่อัตราสาย 40 Gbps เป็นภาระที่หนักบนระบบ

จะมีพลังงานเหลือให้ดำเนินการกับข้อมูลอีกหรือไม่ ทีนี้อย่าคาดหวังสูงเกินไป แค่พูดว่า ^^

รถบัส PCI-Express

PCIe 2.0 คือ 4 Gb / s ต่อช่องทาง PCIe 3.0 คือ 8 Gbps ต่อเลน (ไม่สามารถใช้ได้กับการ์ด PCI ทั้งหมด)

NIC ขนาด 40 Gbps ที่มีพอร์ตอีเธอร์เน็ตเดี่ยวมีแนวโน้มมากกว่าบัส PCIe หากตัวเชื่อมต่อมีความยาวน้อยกว่า 16x สำหรับข้อกำหนด v3.0

อื่น ๆ

เราสามารถไปเกินขีด จำกัด อื่น ๆ ประเด็นก็คือฮาร์ดแวร์มีข้อ จำกัด อย่างหนักซึ่งเป็นไปตามกฎหมายของฟิสิกส์

ซอฟต์แวร์ไม่สามารถทำได้ดีกว่าฮาร์ดแวร์ที่ใช้งานอยู่

เครือข่ายกระดูกสันหลัง

แพ็กเก็ตทั้งหมดเหล่านี้จะต้องไปที่ไหนสักแห่งในที่สุดก็ข้ามสวิตช์และเราเตอร์ สวิตช์และเราเตอร์ 10 Gbps นั้นเป็นสินค้าเกือบทั้งหมด ความเร็ว 40 Gbps นั้นไม่แน่นอน

นอกจากนี้แบนด์วิดท์ต้องเป็นแบบ end-to-end ดังนั้นลิงก์ประเภทใดที่คุณมีให้กับผู้ใช้

ครั้งล่าสุดที่ฉันตรวจสอบกับคนที่แต่งตัวประหลาดศูนย์ข้อมูลของฉันสำหรับโครงการด้านผู้ใช้ 10M เล็ก ๆ น้อย ๆ เขาค่อนข้างชัดเจนว่าจะมีเพียง 2x 10 Gbits ลิงก์ไปยังอินเทอร์เน็ตมากที่สุด

ฮาร์ดไดรฟ์

iostat -xtc 3

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

หากดิสก์ช้าวิธีแก้ปัญหาคือการใส่ SSD ที่ใหญ่กว่าและใหญ่กว่าในการโจมตี 10 (โปรดทราบว่าแบนด์วิดท์ SSD เพิ่มขึ้นเป็นเส้นตรงด้วยขนาด SSD)

ตัวเลือก CPU

IRQ และคอขวดอื่น ๆ ทำงานบนแกนเดียวเท่านั้นดังนั้นเล็งไปที่ CPU ที่มีสมรรถนะแกนเดี่ยวสูงสุด (เช่นความถี่สูงสุด)

การเข้ารหัส / ถอดรหัส SSL ต้องการคำแนะนำ AES-NI เพื่อให้มีการแก้ไข CPU ล่าสุดเท่านั้น

SSL ได้รับประโยชน์จากหลายคอร์ดังนั้นมีจุดมุ่งหมายเพื่อหลายคอร์

เรื่องสั้นสั้น: ซีพียูในอุดมคติเป็นสิ่งใหม่ล่าสุดที่มีความถี่สูงสุดและมีหลายคอร์ เพียงเลือกที่แพงที่สุดและนั่นอาจเป็น: D

sendfile ()

เปิดไฟล์

ความก้าวหน้าที่ยิ่งใหญ่ที่สุดของเมล็ดทันสมัยสำหรับผู้ให้บริการเว็บประสิทธิภาพสูง

หมายเหตุสุดท้าย

1 SolarFlare NIC 40 Gbps (pin IRQ and core)
2 SolarFlare NIC 40 Gbps (pin IRQ and core)
3 nginx master process
4 nginx worker
5 nginx worker
6 nginx worker
7 nginx worker
8 nginx worker
...

สิ่งหนึ่งที่ตรึงไว้กับ CPU หนึ่งตัว นั่นคือวิธีที่จะไป

หนึ่ง NIC ที่นำไปสู่โลกภายนอก หนึ่ง NIC ที่นำไปสู่เครือข่ายภายใน ความรับผิดชอบในการแยกเป็นสิ่งที่ดีเสมอ (แม้ว่า NIC คู่ 40 Gbps อาจ overkill)

นั่นเป็นหลายสิ่งหลายอย่างที่จะต้องปรับบางอย่างอาจเป็นเรื่องของหนังสือเล่มเล็ก ๆ ขอให้สนุกการเปรียบเทียบทั้งหมด กลับมาเพื่อเผยแพร่ผลลัพธ์


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

1
Standing Ovation ....
James Pulley

เพียงแค่อัปเดตอย่างรวดเร็วของฮาร์ดไดรฟ์ - การใช้การจู่โจมในรูปแบบใด ๆ ในสถานการณ์นี้ (ไดรฟ์ ssd) ไม่ทำงานอย่างถูกต้อง เนื่องจาก SSD มีการสึกหรอที่แตกต่างกันจึงมีประสิทธิภาพที่แตกต่างกันและด้วย SSD ที่ช้าในการโจมตีประสิทธิภาพการโจมตีทั้งหมดอาจไม่ดีนัก สถานการณ์ที่ดีที่สุดซึ่งทำงานได้ดีที่สุดสำหรับเราคือการใช้ไดรฟ์เดี่ยวโดยไม่ต้องมีการจู่โจม HW / SW
Yarik Dot

0

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

ในตัวอย่างแรกคุณพูดว่า:

มี 2 ​​สิ่งที่ทำให้ฉันสนใจ อันแรกคือ IRQ ปริมาณสูง ในกรณีนี้ฉันไม่มีกราฟจาก / proc / ขัดจังหวะ สิ่งที่สองคือโหลดระบบสูงซึ่งฉันคิดว่าเกิดจาก kswapd0 มีปัญหาในการทำงานกับ RAM 16G เท่านั้น

เห็นด้วยอย่างแน่นอนว่าสิ่งเหล่านี้เป็นประเด็นสำคัญ

  1. ลองใช้เอเจนต์ collectd ซึ่งสามารถรวบรวม IRQ และเก็บโดยใช้ RRD

  2. คุณมีแผนภูมิการใช้หน่วยความจำหรือไม่?

    ขณะที่อยู่บนพื้นผิวสิ่งนี้ดูเหมือนว่าปัญหาของซีพียู softirq% สูงอาจแค่ชี้ไปที่หน่วยความจำหากมีข้อผิดพลาดของเพจที่แข็งหรือซอฟต์จำนวนมากเกิดขึ้น ฉันคิดว่าการให้ออกไปคือการเพิ่มขึ้นอย่างฉับพลันใน IRQs โดยมีค่าใช้จ่ายของ System CPU ประมาณ 19:00

จากสิ่งที่ฉันเห็นจากสเป็คทุกอย่างดูแตกต่างจาก:

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