Tôi muốn tìm hiểu cấu hình / phần cứng tốt nhất có thể để cung cấp 40Gbps từ một máy chủ duy nhất trong câu hỏi này.

Tình hình

Chúng tôi có một máy chủ proxy chia sẻ video giúp giảm tải các đỉnh từ các máy chủ lưu trữ chậm phía sau nó. Tất cả lưu lượng chỉ là HTTP. Máy chủ hoạt động như một proxy ngược (các tệp không được lưu trong bộ nhớ cache trên máy chủ) và máy chủ web (các tệp được lưu trữ trên các ổ đĩa cục bộ).

Hiện tại có khoảng 100TB tệp và đang phát triển trên các máy chủ lưu trữ phụ trợ.

Cơ chế lưu trữ được triển khai độc lập và câu hỏi này không phải là về bộ nhớ đệm vì nó hoạt động rất tốt - hiện cung cấp 14Gbps, truyền đến các máy chủ phụ trợ chỉ 2Gbps. Vì vậy, việc sử dụng bộ nhớ cache là tốt.

Mục tiêu

Đạt được 40Gbps hoặc thậm chí nhiều hơn thông lượng từ một máy duy nhất.

Phần cứng 1

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

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

Hệ thống:

• irqbalancer dừng lại
• set_irq_affinity cho mỗi giao diện (thông qua tập lệnh trong tarball trình điều khiển ixgbe)
• ixgbe-4.3.15
• Hạn chót của lịch trình I / O
• iptables trống (mô-đun không tải)
• Hệ thống tập tin: XFS

Nginx:

• gửi đi
• chủ đề aio
• chỉ đạo 1 triệu
• tcp_nopush trên
• tcp_nodelay trên

Như đã thấy trên các biểu đồ, chúng tôi có thể đẩy 12,5Gbps. Thật không may, máy chủ đã không phản hồi.

Có 2 điều khiến tôi chú ý. Đầu tiên là số lượng IRQ cao. Trong trường hợp này, tôi không may có đồ thị từ / Proc / ngắt. Điều thứ hai là tải hệ thống cao, mà tôi nghĩ là do kswapd0 gặp vấn đề khi chỉ hoạt động với 16G RAM.

Phần cứng 2

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

SSD, Cấu hình hệ thống giống như phần cứng 1. Nginx được sendfile trên (aio / sendfile so với hơn nữa).

Điều này có vẻ tốt hơn, vì vậy bây giờ khi chúng ta có một máy chủ, hoạt động trong các đỉnh, chúng ta có thể thử một số tối ưu hóa.

Sendfile vs aio chủ đề

Tôi đã cố gắng vô hiệu hóa sendfile và sử dụng chủ đề aio thay thế.

• gửi đi
• chủ đề aio
• directio 1M (phù hợp với tất cả các tệp chúng tôi có)

đấu với

• gửi đi

Sau đó, lúc 15:00 tôi chuyển trở lại sendfile và tải lại nginx (vì vậy phải mất một lúc để hoàn thành các kết nối hiện có). Thật là tốt khi việc sử dụng ổ đĩa (được đo bằng iuler) đã giảm xuống. Không có gì thay đổi về lưu lượng truy cập (tiếc là zabbix đã quyết định không thu thập dữ liệu từ bond0).

gửi / tắt

Chỉ cần cố gắng để bật / tắt gửi. Không có gì thay đổi ngoại trừ ngắt lịch.

irqbalancer là máy chủ / cron / bị vô hiệu hóa

Như @lsd đã đề cập, tôi đã cố gắng thiết lập irqbalancer để được thực thi thông qua cron:

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

Thật không may, nó đã không giúp đỡ trong trường hợp của tôi. Một trong những card mạng bắt đầu hành xử kỳ lạ:

Tôi không thể tìm thấy những gì sai trong biểu đồ và khi nó xảy ra vào ngày hôm sau, tôi đăng nhập vào máy chủ và thấy rằng một lõi ở mức 100% (sử dụng hệ thống).

Tôi đã cố gắng để bắt đầu mất cân bằng như một dịch vụ, kết quả vẫn như vậy.

Sau đó, tôi quyết định sử dụng tập lệnh set_irq_affinity và nó đã khắc phục sự cố ngay lập tức và máy chủ đã đẩy 17Gbps một lần nữa.

Phần cứng 3

Chúng tôi đã nâng cấp lên phần cứng mới: 2U 24 (+2) ổ đĩa khung gầm (6xSFF), 2x Xeon E5-2620v4, RAM DDR4 64GB (mô-đun 4x16GB), SSD 13x, 2x Supermicro (với chip Intel). CPU mới cải thiện hiệu suất rất nhiều.

Thiết lập hiện tại vẫn còn - sendfile, v.v. Chỉ khác là chúng ta chỉ để một CPU duy nhất xử lý cả hai card mạng (thông qua tập lệnh set_irq_affinity).

Đã đạt đến giới hạn 20Gbps.

Mục tiêu tiếp theo? 30Gb / giây.

Hãy bắn vào tôi ý tưởng làm thế nào để cải thiện hiệu suất. Tôi sẽ rất vui khi thử nó trực tiếp và chia sẻ một số biểu đồ nặng ở đây.

Bất kỳ ý tưởng làm thế nào để đối phó với số lượng lớn SoftIRQ trên cpu?

Đây không phải là một câu hỏi về lập kế hoạch năng lực - Tôi đã có phần cứng và lưu lượng. Tôi luôn có thể phân chia lưu lượng truy cập cho một số máy chủ (điều mà tôi sẽ phải làm trong tương lai) và khắc phục vấn đề bằng tiền. Tuy nhiên, đây là một câu hỏi về tối ưu hóa hệ thống và điều chỉnh hiệu suất trong một kịch bản trực tiếp thực sự.

Tuyên bố miễn trừ trách nhiệm : Lời khuyên tương tự áp dụng cho tất cả các dịch vụ đẩy hơn 10Gbps. Bao gồm nhưng không giới hạn ở các bộ cân bằng tải, máy chủ bộ đệm, máy chủ web (HAProxy, Varnish, nginx, tomcat, ...)

Những gì bạn muốn làm là sai, đừng làm điều đó

Sử dụng CDN thay thế

CDN có nghĩa là để cung cấp nội dung tĩnh có thể lưu trữ. Sử dụng công cụ phù hợp cho công việc (akamai, MaxCDN, cloudflare, cloudfront, ...)

Bất kỳ CDN nào, thậm chí là miễn phí, sẽ làm tốt hơn bất cứ điều gì bạn có thể tự mình đạt được.

Thay đổi tỷ lệ theo chiều ngang

Tôi hy vọng một máy chủ duy nhất có thể xử lý hết tốc độ 1-5Gbps mà không cần chỉnh sửa nhiều (lưu ý: chỉ phục vụ các tệp tĩnh). Tốc độ 8-10Gbps thường nằm trong tầm với với điều chỉnh nâng cao.

Tuy nhiên, có nhiều giới hạn cứng đối với những gì một hộp có thể mất. Bạn nên thích quy mô theo chiều ngang.

Chạy một hộp duy nhất, thử mọi thứ, đo lường, điểm chuẩn, tối ưu hóa ... cho đến khi hộp đó đáng tin cậy và đáng tin cậy và khả năng của nó được xác định rõ, sau đó đặt nhiều hộp giống như nó với bộ cân bằng tải toàn cầu ở phía trước.

Có một vài tùy chọn cân bằng tải toàn cầu: hầu hết CDN có thể làm điều đó, DNS roundrobin, cân bằng tải ELB / Google ...

Chúng ta hãy bỏ qua các thực hành tốt và làm điều đó

Hiểu mô hình giao thông

            WITHOUT REVERSE PROXY

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

Có hai điều cần xem xét: băng thông và hướng (phát xạ hoặc tiếp nhận).

Các tệp nhỏ là 50/50 tx / rx vì các tiêu đề HTTP và chi phí TCP lớn hơn nội dung tệp.

Các tệp lớn là 90/10 tx / rx vì kích thước yêu cầu không đáng kể so với kích thước phản hồi.

            WITH REVERSE PROXY

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

Proxy ngược đang chuyển tiếp tất cả các tin nhắn theo cả hai hướng. Tải luôn là 50/50 và tổng lưu lượng được nhân đôi.

Nó trở nên phức tạp hơn với bộ nhớ đệm được kích hoạt. Yêu cầu có thể được chuyển hướng đến ổ cứng, có dữ liệu có thể được lưu trong bộ nhớ.

Lưu ý : Tôi sẽ bỏ qua khía cạnh bộ nhớ đệm trong bài viết này. Chúng tôi sẽ tập trung vào việc nhận 10-40 Gbps trên mạng. Để biết liệu dữ liệu đến từ bộ đệm và tối ưu hóa bộ đệm đó có phải là một chủ đề khác hay không, nó sẽ được đẩy qua dây.

Hạn chế của Monocore

Cân bằng tải là monocore (đặc biệt là cân bằng TCP). Thêm lõi không làm cho nó nhanh hơn nhưng nó có thể làm cho nó chậm hơn.

Tương tự đối với cân bằng HTTP với các chế độ đơn giản (ví dụ: IP, URL, dựa trên cookie. Proxy ngược lại đọc các tiêu đề một cách nhanh chóng, nó không phân tích cú pháp cũng như xử lý các yêu cầu HTTP theo nghĩa chặt chẽ).

Trong chế độ HTTPS, quá trình giải mã / mã hóa SSL chuyên sâu hơn mọi thứ khác cần thiết cho việc ủy ​​quyền. Lưu lượng SSL có thể và nên được phân chia trên nhiều lõi.

SSL

Cho rằng bạn làm mọi thứ qua SSL. Bạn sẽ muốn tối ưu hóa phần đó.

Mã hóa và giải mã 40 Gbps khi đang di chuyển là một thành tựu khá.

Sử dụng bộ xử lý thế hệ mới nhất với các hướng dẫn AES-NI (được sử dụng cho các hoạt động SSL).

Điều chỉnh thuật toán được sử dụng bởi các chứng chỉ. Có nhiều thuật toán. Bạn muốn cái nào hiệu quả nhất trên CPU của bạn (thực hiện đo điểm chuẩn) KHI được khách hàng hỗ trợ VÀ đủ an toàn (không cần mã hóa quá mức cần thiết).

IRQ và ghim lõi

Card mạng đang tạo ra các ngắt (IRQ) khi có dữ liệu mới để đọc và CPU được xử lý trước để xử lý ngay hàng đợi. Đây là một hoạt động chạy trong kernel và / hoặc trình điều khiển thiết bị và nó hoàn toàn đơn điệu.

Nó có thể là người tiêu dùng CPU lớn nhất với hàng tỷ gói tin đi ra theo mọi hướng.

Gán cho card mạng một số IRQ duy nhất và ghim nó xuống một lõi cụ thể (xem cài đặt linux hoặc BIOS).

Ghim proxy ngược vào các lõi khác. Chúng tôi không muốn hai điều này can thiệp.

Bộ chuyển đổi Ethernet

Các card mạng đang làm rất nhiều việc nặng. Tất cả các thiết bị và nhà sản xuất không bằng nhau khi nói đến hiệu suất.

Quên về bộ điều hợp tích hợp trên bo mạch chủ (không quan trọng nếu máy chủ hoặc bo mạch chủ tiêu dùng), chúng chỉ hút.

Giảm tải TCP

TCP là một giao thức rất chuyên sâu về xử lý (tổng kiểm tra, ACK, truyền lại, tập hợp lại các gói, ...) Hạt nhân đang xử lý hầu hết các công việc nhưng một số thao tác có thể được giảm tải cho card mạng nếu nó hỗ trợ.

Chúng tôi không chỉ muốn một thẻ tương đối nhanh , chúng tôi muốn một thẻ có tất cả chuông và còi.

Hãy quên Intel, Mellanox, Dell, HP, bất cứ điều gì. Họ không ủng hộ tất cả điều đó.

Chỉ có một lựa chọn trên bàn: SolarFlare - Vũ khí bí mật của các công ty HFT và CDN.

Thế giới bị chia làm hai loại: " Những người biết SolarFlare " và " những người không biết ". (bộ đầu tiên hoàn toàn tương đương với " những người thực hiện kết nối mạng 10 Gbps và quan tâm đến mọi bit "). Nhưng tôi lạc đề, hãy tập trung: D

Điều chỉnh hạt nhân TCP

Có các tùy chọn trong sysctl.confbộ đệm mạng kernel. Những gì các cài đặt này làm hoặc không làm. Tôi thực sự không biết.

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

Chơi với các cài đặt này là dấu hiệu rõ ràng của việc tối ưu hóa quá mức (nghĩa là vô dụng hoặc phản tác dụng].

Ngoại lệ, điều đó có thể có ý nghĩa với các yêu cầu cực đoan.

(Lưu ý: 40Gbps trên một hộp là tối ưu hóa quá mức. Lộ trình hợp lý là mở rộng theo chiều ngang.)

Một số giới hạn vật lý

Băng thông bộ nhớ

Một số con số về băng thông bộ nhớ (chủ yếu tính bằng GB / s): http://www.tweaktown.com/articles/6619/crucial-ddr4-memory-performance-overview-early-look-vs-ddr2-ddr3/index.html

Giả sử phạm vi là 150-300 Gbps cho băng thông bộ nhớ (giới hạn tối đa trong điều kiện lý tưởng).

Tất cả các gói phải ở trong bộ nhớ tại một số điểm. Chỉ cần nhập dữ liệu ở tốc độ đường truyền 40 Gbps là tải nặng trên hệ thống.

Sẽ có sức mạnh còn lại để xử lý dữ liệu? Chà, đừng để kỳ vọng của chúng ta quá cao vào điều đó. Chỉ nói thôi

Xe buýt PCI-Express

PCIe 2.0 là 4 Gb / s mỗi làn. PCIe 3.0 là 8 Gbps mỗi làn (không phải tất cả đều có sẵn cho thẻ PCI).

Một NIC 40 Gbps với một cổng Ethernet duy nhất hứa hẹn nhiều hơn so với bus PCIe nếu đầu nối có chiều dài nhỏ hơn 16 lần trên thông số kỹ thuật v3.0.

Khác

Chúng ta có thể vượt qua các giới hạn khác. Vấn đề là phần cứng có những hạn chế cứng vốn có đối với định luật vật lý.

Phần mềm không thể làm tốt hơn phần cứng mà nó đang chạy.

Mạng trục chính

Tất cả các gói này phải đi đâu đó cuối cùng, đi qua các thiết bị chuyển mạch và bộ định tuyến. Các bộ chuyển mạch và bộ định tuyến 10 Gbps [gần như] là một mặt hàng. 40 Gbps chắc chắn là không.

Ngoài ra, băng thông phải là đầu cuối để bạn có loại liên kết nào với người dùng?

Lần trước tôi đã kiểm tra với anh chàng trung tâm dữ liệu của mình cho một dự án phụ 10 triệu người dùng, anh ta khá rõ ràng rằng sẽ chỉ có 2 liên kết 10 Gbits với internet.

Ổ cứng

iostat -xtc 3

Số liệu được phân chia bằng cách đọc và viết. Kiểm tra hàng đợi (<1 là tốt), độ trễ (<1 ms là tốt) và tốc độ truyền (càng cao càng tốt).

Nếu đĩa chậm, giải pháp là đặt nhiều ổ SSD VÀ lớn hơn vào cuộc đột kích 10. (lưu ý rằng băng thông SSD tăng tuyến tính với kích thước SSD).

Lựa chọn CPU

IRQ và các nút cổ chai khác chỉ chạy trên một lõi, vì vậy hãy nhắm đến CPU có hiệu suất lõi đơn cao nhất (tức là tần số cao nhất).

Mã hóa / giải mã SSL cần các hướng dẫn AES-NI để chỉ sửa đổi CPU mới nhất.

SSL được hưởng lợi từ nhiều lõi vì vậy nhắm đến nhiều lõi.

Câu chuyện dài: CPU lý tưởng là CPU mới nhất có tần số cao nhất hiện có và nhiều lõi. Chỉ cần chọn đắt nhất và đó có thể là nó: D

gửi tài liệu()

Gửi thư

Đơn giản là sự tiến bộ lớn nhất của hạt nhân hiện đại cho máy chủ web hiệu suất cao.

Lưu ý cuối cùng

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
...

Một điều được ghim xuống một CPU. Đó là con đường để đi.

Một NIC dẫn đến thế giới bên ngoài. Một NIC dẫn đến mạng nội bộ. Việc phân chia trách nhiệm luôn tốt đẹp (mặc dù NIC 40 Gbps kép có thể quá mức cần thiết).

Đó là rất nhiều điều cần tinh chỉnh, một số trong đó có thể là chủ đề của một cuốn sách nhỏ. Hãy vui vẻ điểm chuẩn tất cả những điều đó. Hãy trở lại để công bố kết quả.

Tôi chưa thể bình luận vì danh tiếng, vì vậy phải thêm câu trả lời ...

Trong ví dụ đầu tiên, bạn nói:

Có 2 điều khiến tôi chú ý. Đầu tiên là số lượng IRQ cao. Trong trường hợp này, tôi không may có đồ thị từ / Proc / ngắt. Điều thứ hai là tải hệ thống cao, mà tôi nghĩ là do kswapd0 gặp vấn đề khi chỉ hoạt động với 16G RAM.

Hoàn toàn đồng ý rằng đây là những điểm quan trọng.

1. Hãy thử sử dụng tác nhân colld, có thể thu thập IRQ và lưu trữ bằng RRD.

2. Bạn có một biểu đồ sử dụng bộ nhớ?

   Nhìn bề ngoài, đây có vẻ như là một vấn đề của CPU,% softirq cao có thể chỉ trỏ ngón tay vào bộ nhớ, nếu có nhiều lỗi trang cứng hoặc mềm xảy ra. Tôi nghĩ rằng sự cho đi là sự leo thang đột ngột trong các IRQ, với chi phí CPU hệ thống vào khoảng 19:00.

Từ những gì tôi có thể thấy từ thông số kỹ thuật, mọi thứ trông giống nhau ngoài:

• kí ức
• các mô hình cpu - trừ khi tôi nhầm, các điểm chuẩn sẽ chỉ ra rằng chúng phải giống nhau và trong các trường hợp này, tôi thích hộp có lõi nhanh hơn.