Nút cổ chai I / O của Linux với bộ chuyển dữ liệu

Tôi có một máy 24 lõi với RAM 94,6GiB chạy máy chủ Ubuntu 10.04. Hộp đang có% iowait cao, không giống như một máy chủ khác mà chúng tôi có (4 lõi) chạy cùng loại và số lượng quy trình. Cả hai máy được kết nối với máy chủ tệp VNX Raid, máy 24 lõi thông qua 4 thẻ FC và máy còn lại thông qua thẻ ethernet 2 gigabit. Máy 4 lõi hiện đang vượt trội so với máy 24 lõi, có mức sử dụng CPU cao hơn và% iowait thấp hơn.

Trong 9 ngày thời gian hoạt động,% iowait trung bình ở mức 16% và thường xuyên trên 30%. Hầu hết thời gian sử dụng CPU rất thấp, khoảng 5% (do iowait cao). Có bộ nhớ trống rộng rãi.

Một điều tôi không hiểu là tại sao tất cả các dữ liệu dường như đi qua sdc của thiết bị thay vì trực tiếp chuyển qua các bộ chuyển dữ liệu:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.11    0.39    0.75   16.01    0.00   76.74

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               0.00         0.00         0.00       1232          0
sdb               0.00         0.00         0.00       2960          0
sdc               1.53        43.71        44.54   36726612   37425026
dm-0              0.43        27.69         0.32   23269498     268696
dm-1              1.00         1.86         7.74    1566234    6500432
dm-2              0.96         1.72         5.97    1442482    5014376
dm-3              0.49         9.57         0.18    8040490     153272
dm-4              0.00         0.00         0.00       1794         24
dm-5              0.00         0.00         0.00        296          0

Một mảnh khác của câu đố là các nhiệm vụ thường xuyên chuyển sang chế độ ngủ không thể liên tục (ở trên cùng), cũng có thể là do sự nắm giữ của io.

Tôi có thể xem gì để giúp chẩn đoán vấn đề? Tại sao tất cả các dữ liệu đi qua / dev / sdc? Điều đó có bình thường không?

CẬP NHẬT:

Kết nối mạng và khả năng đọc / ghi VNX đã được loại trừ là tắc nghẽn. Chúng ta có thể đạt tốc độ 800MB / giây với 4 NIC ngoại quan (vòng tròn). Các thẻ kênh sợi vẫn chưa được sử dụng. VNX có khả năng xử lý tốt các đĩa IO (RAID6, 30x2TB 7.2kRPM cho mỗi nhóm trong hai nhóm (tổng cộng 60 đĩa), khoảng 60% đọc).

Bỏ qua ở trên về dm và sdc, chúng đều là các đĩa bên trong và không phải là một phần của vấn đề.

Chúng tôi nghĩ rằng vấn đề có thể xảy ra với các mount nfs hoặc TCP (chúng tôi có 5 mount đến 5 phân vùng trên VNX), nhưng không biết chính xác là gì. Có lời khuyên nào không?

Trước hết, nếu CPU của bạn (và chết tiệt! Đó là rất nhiều 24) ăn dữ liệu nhanh hơn những gì có thể cung cấp lưu trữ dữ liệu, sau đó bạn nhận được iowait. Đó là khi kernel tạm dừng một quá trình trong khi chặn io (một lần đọc quá chậm hoặc ghi đồng bộ).
Vì vậy, hãy kiểm tra xem bộ lưu trữ có thể cung cấp đủ thông lượng cho 24 lõi.

Ví dụ: giả sử bộ lưu trữ của bạn có thể cung cấp thông lượng 500MB / s, rằng bạn được kết nối qua đường truyền 2 Gigabit Ethernet (trái phiếu), mạng sẽ giới hạn lưu lượng tối đa ở mức khoảng 100-180 MB / s. Nếu quy trình của bạn ăn dữ liệu ở tốc độ 50 MB / s và bạn chạy 4 luồng trên máy 4 lõi của mình: 4 x 50 MB / s = 200 MB / s đã tiêu thụ. Nếu mạng có thể duy trì 180MB / s thì bạn sẽ không có độ trễ nhiều và CPU của bạn sẽ được tải. Mạng ở đây là một nút cổ chai nhỏ.
Bây giờ nếu bạn mở rộng quy mô này lên tới 24 lõi và 24 luồng, bạn sẽ cần 1200 MB / s, ngay cả khi bạn thay đổi hệ thống dây điện để cho phép thông lượng như vậy, hệ thống lưu trữ của bạn không cung cấp hơn 500 MB / s, nó sẽ trở thành nút cổ chai.

Khi nói đến io chờ đợi, nút cổ chai có thể ở khắp mọi nơi. Không chỉ trên các lớp vật lý, mà còn trong bộ đệm không gian phần mềm và nhân. Nó thực sự phụ thuộc vào các mô hình sử dụng. Nhưng vì các nút thắt phần mềm khó xác định hơn nhiều, nên thường kiểm tra thông lượng lý thuyết trên phần cứng trước khi điều tra các ngăn xếp phần mềm.

Như đã nói, một iowait xảy ra khi một quá trình thực hiện đọc và dữ liệu cần có thời gian để đến hoặc khi nó thực hiện ghi đồng bộ và xác nhận sửa đổi dữ liệu mất thời gian. Trong quá trình ghi đồng bộ, quá trình vào chế độ ngủ không bị gián đoạn để dữ liệu không bị hỏng. Có một công cụ tiện dụng để xem cuộc gọi nào làm cho quá trình bị treo : latencytop. Nó không phải là duy nhất của loại hình này, nhưng bạn có thể thử nó.

Lưu ý: đối với thông tin của bạn, dm là viết tắt của trình ánh xạ thiết bị chứ không phải chuyển động dữ liệu.

Trước hết, thánh địa là rất nhiều sắt! :)

Thật không may vì thiết lập của bạn nghe có vẻ rất phức tạp, tôi không nghĩ ai sẽ có thể cung cấp ngay lập tức "Có vấn đề của bạn!" trả lời, trừ khi họ đã làm một cái gì đó với một thiết lập cực kỳ giống hoặc giống hệt nhau và gặp phải cùng một vấn đề. Vì vậy, trong khi văn bản này được SU gắn nhãn là "Trả lời", có lẽ bạn nên xem nó giống như "Đề xuất" hơn. Và tôi không thể đưa nó vào bình luận vì quá nhiều từ. :S

Không có kiến ​​thức về cách phần cứng của bạn được ánh xạ tới các thiết bị, thật khó để nói tại sao I / O lại đi một nơi chứ không phải một nơi khác. Làm thế nào để bạn có các thiết bị gắn kết? Các chương trình của bạn đang truy cập sd*trực tiếp vào thiết bị hay tất cả các hệ thống tệp của bạn được gắn trên dmthiết bị và tất cả các truy cập tệp xảy ra ở đó?

Những điều khác tôi phải hỏi về:

• Đó là loại RAID gì? Nếu bạn đang tính toán các bit chẵn lẻ với RAID5 hoặc RAID6, thì phần cứng máy chủ đột kích sẽ được chăm sóc ... nếu không, các máy chủ xử lý đang làm điều đó .... không tối ưu và có thể gây ra độ trễ I / O nếu thực hiện trong phần mềm.

• Bạn đã tách một trong những khác biệt chính giữa hai máy chủ trong tin nhắn của bạn. Một là sử dụng kênh sợi và một là sử dụng ethernet. Kênh sợi quang sẽ cung cấp độ trễ và băng thông tốt hơn, nhưng có lẽ đó cũng là một vấn đề: nếu nó cung cấp nhiều thông lượng, nó có thể khiến máy chủ RAID rất bận rộn ... và tắc nghẽn dẫn đến bộ đệm / bộ đệm bị lấp đầy, điều này làm tăng độ trễ, điều này gây ra sự chờ đợi I / O cao hơn.

Nó gần như là bạn có thể có một vấn đề phình to bộ đệm với các mảng đĩa của bạn - bạn biết không? Bộ điều khiển RAID phần cứng thường có rất nhiều bộ nhớ cache trên bo mạch, phải không? Vì vậy, khi I / O cho phương tiện truyền thông được xếp hàng và bộ đệm chứa đầy các trang bẩn, cuối cùng toàn bộ điều này đã bão hòa (nếu bộ lưu trữ cơ học không thể theo kịp tải) và độ trễ đi qua mái nhà ... chắc chắn bạn có thể tạo ra nhiều tải hơn với 24 lõi + FC so với 4 lõi + GbE :) Kiểm tra máy chủ RAID và xem các ổ đĩa bận đến mức nào ... rất nhiều "I / O" có thể chỉ là các gói điều khiển, v.v. Tôi không chắc chắn FC hoạt động như thế nào nhưng nếu nó giống như TCP thì bạn sẽ thấy truyền lại nếu độ trễ quá cao.

Giống như nếu bạn hỏi ai đó một câu hỏi qua điện thoại và họ không trả lời trong vài giây, bạn nói "Xin chào?" - các giao thức mạng (và FC chỉ là một giao thức mạng) làm điều tương tự, chỉ trong một khoảng thời gian ngắn hơn. Nhưng tất nhiên là thêm "Xin chào?" là đắt tiền trong bối cảnh của mạng vì nó thêm nhiều dữ liệu hơn vào một đường ống đã bị tắc nghẽn.

Cuối cùng, một mẹo chung:

Khi gỡ lỗi độ trễ / IO chờ / vấn đề thông lượng, luôn luôn đo . Đo lường ở khắp mọi nơi. Đo tại dây, đo những gì bản thân chương trình đang làm, đo ở đầu xử lý, đo trên máy chủ RAID, v.v. Đừng chỉ nhìn vào nó từ một góc độ - hãy thử xem xét từng thành phần riêng lẻ của hệ thống chịu trách nhiệm xử lý, đọc hoặc ghi bất kỳ dữ liệu nào trong đường ống. Tách một giao dịch hoặc một đơn vị công việc riêng biệt và phân tích chính xác đường đi qua phần cứng của bạn và đo tại mỗi thành phần riêng biệt để xem liệu có tắc nghẽn hoặc nơi có độ trễ không đáng có, v.v. Một người bạn của tôi gọi là "lột trở lại hành tây "và từ đó tôi đã sử dụng cụm từ này để chỉ nhiệm vụ gỡ lỗi một luồng dữ liệu.

Một bổ sung nhỏ. Bạn có thể muốn xem xét điều chỉnh mức khối và lên lịch I / O trong trường hợp này. Tôi không quen thuộc với Ubuntu, nhưng có một số nút hiệu suất lưu trữ tốt để điều chỉnh. Điều này chắc chắn áp dụng trong trường hợp lưu trữ và cơ sở dữ liệu SAN.

• Hãy nhìn vào bộ lập lịch I / O của hệ thống . CFQ là mặc định, nhưng noop và thời hạn là những lựa chọn phổ biến cho khối lượng công việc cơ sở dữ liệu.
• Xem liên kết này để biết một số thông số điều chỉnh khác có thể giúp đỡ.
• Bạn đề cập đến NFS và khối lưu trữ. Nếu khối, hệ thống tập tin nào đang được sử dụng? Chờ I / O nghe có vẻ như là một tình huống chặn ghi từ đây. Các rào cản ghi được kích hoạt? Kể lại hệ thống tập tin của bạn với nobarrier. ( Gợi ý cho Ubuntu )

Một số liên kết Lỗi Máy chủ có liên quan ...

Linux - điều chỉnh bộ điều khiển RAID phần cứng trong thế giới thực (scsi và cciss)

Cảm ơn tất cả các ý tưởng và đầu vào. Vấn đề liên quan đến sự kết hợp của cấu hình liên kết ethernet không tối ưu, kết hợp với mô đun I / O bị lỗi trên chính VNX. Tỷ lệ I / O hiện đang ở gần nơi chúng ta mong đợi. Thật thú vị khi lưu ý rằng các bài kiểm tra đọc và đọc tệp dd và điểm chuẩn iozone không thể phát hiện ra điều này, và có thể đọc và viết gần như nhanh như mong đợi.

Tôi sẽ chỉnh sửa với nhiều thông tin sớm hơn, nhưng trước tiên tôi muốn nói rằng bạn không nên để đầu ra dm- * của iuler làm bạn bối rối. Thiết bị ánh xạ thiết bị là một thiết bị passthru trong nhân giống như md * (md0, md1, v.v.) vì vậy bạn thực sự chỉ quan tâm đến các thiết bị bên dưới của mình. Tất cả dữ liệu truyền đến các đĩa của bạn đều đi qua dm / md trên đường và tổng số thực tế (byte, giây, v.v.) là chính xác, nhưng việc sử dụng là sai lệch.

Ngoài ra, đó là một lượng bộ nhớ rất lớn. Những điều thú vị bắt đầu xảy ra ở mức cao (bản thân tôi chạy 2x64 và 2x96), đặc biệt nếu bạn có một quá trình chiếm hơn một nửa số ram. Đọc bài viết này để biết thêm thông tin . Bài viết đề cập đến mysql nhưng xin lưu ý rằng nó không phải làcụ thể mysql. Mọi quy trình phần mềm sẽ phải chịu các hình phạt đối với bộ nhớ truy cập của bộ xử lý vật lý khác - nghĩ rằng 48gb thuộc về một Proc, 48 cho người khác. Quá trình chỉ có thể thuộc về một Proc và để đạt được bộ nhớ procs khác (sau khi hết 48 GB), họ phải quyết định lưu trữ một số 48 trong số đó để trao đổi hoặc trả một mức giá lớn để có được & từ bộ nhớ khác của Proc. Bài báo đề nghị chạy lệnh numactl để buộc phần mềm không trao đổi và thay vào đó phải trả tiền phạt. Cá nhân tôi đã thấy những cải tiến lớn từ điều này. Nói cách khác - kiểm tra xem một số I / O của bạn sẽ hoán đổi! Sử dụng miễn phí -m (hoặc tương tự) cho việc này. Nếu bạn có nhiều bộ nhớ trống, nhưng một số lượng trao đổi không tầm thường (cộng thêm 10%), đây rất có thể là vấn đề của bạn.

Nhìn vào điều này từ góc độ lưu trữ, bạn có cách nào để đo độ trễ scsi không? Thời gian chờ của hệ điều hành bao gồm rất nhiều thứ nằm ngoài sự kiểm soát của bộ lưu trữ, nhưng khi tôi vào hộp lưu trữ của mình và thấy độ trễ IO ở mức 2ms, tôi biết rằng bất kể máy chủ đang nhận được nội bộ gì, các lệnh scsi đều được phản hồi một cách nhanh chóng và tôi có thể loại bỏ lưu trữ như một biến.