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

Hầu hết các hệ thống Linux tôi quản lý tính năng bộ điều khiển RAID phần cứng (chủ yếu là HP Smart Array ). Tất cả họ đều đang chạy RHEL hoặc CentOS.

Tôi đang tìm kiếm các bộ điều chỉnh trong thế giới thực để giúp tối ưu hóa hiệu suất cho các thiết lập kết hợp bộ điều khiển RAID phần cứng với các đĩa SAS (Smart Array, Perc, LSI, v.v.) và bộ nhớ cache dựa trên pin hoặc flash. Giả sử RAID 1 + 0 và nhiều trục chính (4+ đĩa).

Tôi dành một lượng thời gian đáng kể để điều chỉnh cài đặt mạng Linux cho các ứng dụng giao dịch tài chính và độ trễ thấp. Nhưng nhiều tùy chọn trong số đó là tài liệu tốt (thay đổi bộ đệm gửi / nhận, sửa đổi cài đặt cửa sổ TCP, v.v.). Các kỹ sư đang làm gì về phía lưu trữ?

Trong lịch sử, tôi đã thực hiện các thay đổi đối với thang máy lên lịch I / O , gần đây đã chọn deadlinevà lập nooplịch để cải thiện hiệu suất trong các ứng dụng của mình. Khi các phiên bản RHEL đã phát triển, tôi cũng nhận thấy rằng các mặc định được biên dịch cho các thiết bị khối SCSI và CCISS cũng đã thay đổi. Điều này đã có tác động đến các cài đặt hệ thống lưu trữ được đề xuất theo thời gian. Tuy nhiên, đã được một lúc kể từ khi tôi thấy bất kỳ khuyến nghị rõ ràng. Và tôi biết rằng hệ điều hành mặc định không tối ưu. Ví dụ, có vẻ như bộ đệm đọc trước mặc định 128kb là cực kỳ nhỏ để triển khai trên phần cứng lớp máy chủ.

Các bài viết sau đây khám phá tác động hiệu suất của việc thay đổi giá trị bộ đệm đọc trước và giá trị nr numquests trên hàng đợi khối.

http://zackreed.me/articles/54-hp-smart-array-p410-controll-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with -linux-why-chỉnh-thực sự quan trọng
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

Ví dụ: đây là những thay đổi được đề xuất cho bộ điều khiển RAID mảng thông minh của HP:

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

Những gì khác có thể được điều chỉnh đáng tin cậy để cải thiện hiệu suất lưu trữ?
Tôi đặc biệt tìm kiếm các tùy chọn sysctl và sysfs trong các kịch bản sản xuất.

Tôi đã phát hiện ra rằng khi tôi phải điều chỉnh độ trễ thấp hơn so với thông lượng, tôi đã điều chỉnh nr numquests từ mặc định của nó (xuống mức thấp nhất là 32). Ý tưởng là các lô nhỏ hơn bằng với độ trễ thấp hơn.

Ngoài ra đối với read_ahead_kb tôi đã thấy rằng đối với việc đọc / ghi tuần tự, việc tăng giá trị này mang lại thông lượng tốt hơn, nhưng tôi thấy rằng tùy chọn này thực sự phụ thuộc vào khối lượng công việc và mẫu IO của bạn. Ví dụ: trên hệ thống cơ sở dữ liệu mà tôi đã điều chỉnh gần đây, tôi đã thay đổi giá trị này để khớp với kích thước trang db duy nhất giúp giảm độ trễ đọc. Tăng hoặc giảm vượt quá giá trị này đã chứng minh làm giảm hiệu suất trong trường hợp của tôi.

Đối với các tùy chọn hoặc cài đặt khác cho hàng đợi thiết bị khối:

max_sector_kb = Tôi đã đặt giá trị này khớp với những gì phần cứng cho phép chuyển một lần (kiểm tra giá trị của tệp max_hw_sector_kb (RO) trong sysfs để xem những gì được phép)

nomerges = điều này cho phép bạn vô hiệu hóa hoặc điều chỉnh logic tra cứu để hợp nhất các yêu cầu io. (tắt tính năng này có thể giúp bạn tiết kiệm một số chu kỳ cpu, nhưng tôi không thấy bất kỳ lợi ích nào khi thay đổi điều này cho các hệ thống của mình, vì vậy tôi để mặc định nó)

rq_affinity = Tôi chưa thử điều này, nhưng đây là lời giải thích đằng sau nó từ các tài liệu kernel

Nếu tùy chọn này là '1', lớp khối sẽ di chuyển hoàn thành yêu cầu đến "nhóm" cpu đã gửi yêu cầu ban đầu. Đối với một số khối lượng công việc, điều này giúp giảm đáng kể chu kỳ CPU do hiệu ứng bộ đệm.
Đối với các cấu hình lưu trữ cần tối đa hóa phân phối xử lý hoàn tất, cài đặt tùy chọn này thành '2' buộc hoàn thành phải chạy trên cpu yêu cầu (bỏ qua logic tổng hợp "nhóm") "

calendaruler = bạn nói rằng bạn đã thử thời hạn và noop. Tôi đã thử nghiệm cả noop và hạn chót, nhưng đã tìm thấy thời hạn cuối cùng cho thử nghiệm mà tôi đã thực hiện gần đây nhất cho một máy chủ cơ sở dữ liệu.

NOOP hoạt động tốt, nhưng đối với máy chủ cơ sở dữ liệu của chúng tôi, tôi vẫn có thể đạt được hiệu suất tốt hơn khi điều chỉnh lịch trình thời hạn.

Tùy chọn cho lịch trình thời hạn nằm dưới / sys / block / {sd, cciss, dm -} * / queue / iosched /:

fifo_batch = loại giống như nr numquests, nhưng cụ thể cho trình lập lịch biểu. Nguyên tắc chung là điều chỉnh điều này xuống cho độ trễ thấp hơn hoặc tăng cho thông lượng. Kiểm soát kích thước lô của các yêu cầu đọc và viết.

write_Exire = đặt thời gian hết hạn cho các đợt ghi mặc định là 5000ms. Một lần nữa giảm giá trị này làm giảm độ trễ ghi của bạn trong khi tăng giá trị tăng thông lượng.

read_Exire = đặt thời gian hết hạn cho mặc định lô đọc là 500ms. Quy tắc tương tự áp dụng ở đây.

front_merges = Tôi có xu hướng tắt cái này và nó được bật theo mặc định. Tôi không thấy sự cần thiết của bộ lập lịch để lãng phí các chu kỳ cpu khi cố gắng hợp nhất các yêu cầu IO.

write_starved = vì hạn chót hướng đến việc đọc mặc định ở đây là xử lý 2 đợt đọc trước khi một đợt ghi được xử lý. Tôi thấy mặc định là 2 là tốt cho khối lượng công việc của tôi.

Hơn bất cứ điều gì, mọi thứ phụ thuộc vào khối lượng công việc của bạn.

read_ahead_kbcó thể giúp bạn nếu việc đọc nhiều dữ liệu từ một số tệp trước thời hạn, như khi truyền phát video thực sự hữu ích. Đôi khi nó có thể làm bạn tổn thương nặng nề. Đúng, 128 KB mặc định có thể nghe nhỏ, nhưng với đủ đồng thời, nó bắt đầu nghe có vẻ lớn! Mặt khác, với một máy chủ như máy chủ mã hóa video chỉ chuyển đổi video từ định dạng sang định dạng khác, đó có thể là ý tưởng rất tốt để điều chỉnh.

nr_requests, khi bị quá tải, có thể dễ dàng làm ngập bộ điều khiển RAID của bạn, điều này lại làm giảm hiệu suất.

Trong thế giới thực, bạn cần xem độ trễ . Nếu bạn đang kết nối với SAN, hãy xem với iostat, sarhoặc bất cứ điều gì bạn thích để sử dụng, và xem nếu lần dịch vụ I / O yêu cầu là thông qua các mái nhà. Tất nhiên, điều này cũng có ích với các đĩa cục bộ: nếu độ trễ rất lớn, hãy xem xét điều chỉnh cài đặt thang máy I / O của bạn bằng cách hạ cấp max_Vquests và các cài đặt khác.

FYI read_ahead_kbvà blockdev --setrachỉ là những cách khác nhau để đặt cùng một cài đặt bằng các đơn vị khác nhau (kB so với các ngành):

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

Nên

blockdev --setra 65536 /dev/cciss/c0d0

trong ví dụ của bạn không có hiệu lực.