Thiết lập nhân Linux cho GlusterFS

Bản dịch của bài báo đã được chuẩn bị vào đêm trước khi bắt đầu khóa học Quản trị viên Linux. Chuyên nghiệp".

Thiết lập nhân Linux cho GlusterFS

Thỉnh thoảng, ở đây và ở đó, các câu hỏi đặt ra về các khuyến nghị của Gluster liên quan đến việc điều chỉnh nhân và liệu có cần thiết cho việc này hay không.

Một nhu cầu như vậy hiếm khi phát sinh. Trên hầu hết các khối lượng công việc, hạt nhân hoạt động rất tốt. Mặc dù có một nhược điểm. Về mặt lịch sử, nhân Linux sẵn sàng tiêu tốn rất nhiều bộ nhớ nếu có cơ hội, bao gồm cả việc lưu vào bộ nhớ đệm là cách chính để cải thiện hiệu suất.

Trong hầu hết các trường hợp, điều này hoạt động tốt, nhưng dưới tải nặng, nó có thể dẫn đến sự cố.

Chúng tôi có nhiều kinh nghiệm với các hệ thống sử dụng nhiều bộ nhớ như CAD, EDA, v.v., những hệ thống này bắt đầu hoạt động chậm lại khi tải nặng. Và đôi khi chúng tôi gặp vấn đề ở Gluster. Sau khi quan sát cẩn thận việc sử dụng bộ nhớ và độ trễ của đĩa trong nhiều ngày, chúng tôi nhận thấy chúng quá tải, iowait lớn, lỗi kernel (kernel oops), treo, v.v.

Bài viết này là kết quả của nhiều thí nghiệm điều chỉnh được thực hiện trong các tình huống khác nhau. Nhờ những thông số này, không chỉ khả năng phản hồi tổng thể được cải thiện mà cả cụm cũng ổn định đáng kể.

Khi nói đến việc điều chỉnh bộ nhớ, điều đầu tiên cần xem xét là hệ thống con bộ nhớ ảo (VM, bộ nhớ ảo), hệ thống này có một số lượng lớn các tùy chọn có thể khiến bạn bối rối.

vm.swappiness

Thông số vm.swappiness xác định mức độ kernel sử dụng hoán đổi (swap, paging) so với RAM. Nó cũng được định nghĩa trong mã nguồn là "xu hướng đánh cắp bộ nhớ được ánh xạ". Tính trao đổi cao có nghĩa là hạt nhân sẽ có xu hướng hoán đổi các trang được ánh xạ nhiều hơn. Giá trị trao đổi thấp có nghĩa ngược lại: hạt nhân sẽ trang ít hơn từ bộ nhớ. Nói cách khác, giá trị càng cao vm.swappiness, càng nhiều hệ thống sẽ sử dụng trao đổi.

Việc sử dụng nhiều trao đổi là điều không mong muốn, vì các khối dữ liệu khổng lồ được tải và dỡ vào RAM. Nhiều người lập luận rằng giá trị hoán đổi phải lớn, nhưng theo kinh nghiệm của tôi, việc đặt giá trị này thành "0" sẽ mang lại hiệu suất tốt hơn.

Bạn có thể đọc thêm ở đây - lwn.net/Articles/100978

Tuy nhiên, một lần nữa, các cài đặt này nên được áp dụng cẩn thận và chỉ sau khi thử nghiệm một ứng dụng cụ thể. Đối với các ứng dụng phát trực tuyến được tải nhiều, thông số này phải được đặt thành "0". Khi được thay đổi thành "0", khả năng phản hồi của hệ thống sẽ được cải thiện.

vm.vfs_cache_áp lực

Cài đặt này kiểm soát bộ nhớ được sử dụng bởi hạt nhân cho các đối tượng inode và thư mục bộ nhớ đệm (dentry và inode).

Với giá trị mặc định là 100, hạt nhân sẽ cố gắng giải phóng bộ nhớ cache dentry và inode trên cơ sở "công bằng" cho bộ nhớ cache và bộ nhớ đệm hoán đổi. Việc giảm vfs_cache_pressure khiến kernel giữ lại bộ nhớ đệm inode và inode. Khi giá trị là "0", kernel sẽ không bao giờ xóa bộ nhớ cache dentry và inode do áp lực bộ nhớ và điều này có thể dễ dàng dẫn đến lỗi hết bộ nhớ. Việc tăng vfs_cache_pressure trên 100 khiến kernel ưu tiên xóa nha khoa và inode.

Khi sử dụng GlusterFS, nhiều người dùng có lượng dữ liệu lớn và nhiều tệp nhỏ có thể dễ dàng sử dụng một lượng RAM đáng kể trên máy chủ do bộ nhớ đệm inode/dentry, điều này có thể dẫn đến suy giảm hiệu suất do nhân phải xử lý cấu trúc dữ liệu trên hệ thống với 40 GB bộ nhớ . Việc đặt giá trị này trên 100 đã giúp nhiều người dùng đạt được bộ nhớ đệm hợp lý hơn và khả năng phản hồi của kernel được cải thiện.

vm.dirty_background_ratio và vm.dirty_ratio

Tham số đầu tiên (vm.dirty_background_ratio) xác định tỷ lệ phần trăm bộ nhớ có các trang bẩn, sau khi đạt đến mức cần bắt đầu xóa các trang bẩn trong nền vào đĩa. Cho đến khi đạt được tỷ lệ phần trăm này, không có trang nào được chuyển vào đĩa. Và khi thiết lập lại bắt đầu, nó sẽ chạy trong nền mà không làm gián đoạn các tiến trình đang chạy.

Tham số thứ hai (vm.dirty_ratio) xác định tỷ lệ phần trăm bộ nhớ có thể bị chiếm bởi các trang bẩn trước khi flash bắt buộc bắt đầu. Khi đạt đến ngưỡng này, tất cả các quy trình sẽ trở nên đồng bộ (bị chặn) và không được phép tiếp tục cho đến khi I/O mà chúng yêu cầu thực sự hoàn thành và dữ liệu có trên đĩa. Với I/O nặng, điều này gây ra sự cố vì không có bộ nhớ đệm dữ liệu và tất cả các quy trình thực hiện I/O đều bị chặn chờ I/O. Điều này dẫn đến một số lượng lớn các quy trình bị treo, tải cao, hệ thống không ổn định và hiệu suất kém.

Việc giảm các cài đặt này khiến dữ liệu được chuyển vào đĩa thường xuyên hơn và không được lưu trữ trong RAM. Điều này có thể giúp các hệ thống sử dụng nhiều bộ nhớ có thể sử dụng bộ nhớ đệm trang 45-90 GB vào ổ đĩa, dẫn đến độ trễ lớn cho các ứng dụng ngoại vi, làm giảm khả năng phản hồi và tương tác tổng thể.

"1"> /proc/sys/vm/pagecache

Bộ đệm trang là bộ đệm lưu trữ dữ liệu của tệp và chương trình thực thi, nghĩa là đây là những trang có nội dung thực của tệp hoặc khối thiết bị. Bộ đệm này được sử dụng để giảm số lần đọc đĩa. Giá trị "1" có nghĩa là 1% RAM được sử dụng cho bộ đệm và sẽ có nhiều lần đọc từ đĩa hơn là từ RAM. Không cần thiết phải thay đổi cài đặt này, nhưng nếu bạn hoang tưởng về việc kiểm soát bộ đệm của trang, bạn có thể sử dụng nó.

"hạn chót"> /sys/block/sdc/queue/scheduler

Bộ lập lịch I/O là một thành phần nhân Linux xử lý các hàng đợi đọc và ghi. Về lý thuyết, tốt hơn là sử dụng "noop" cho bộ điều khiển RAID thông minh, vì Linux không biết gì về hình dạng vật lý của đĩa, do đó, sẽ hiệu quả hơn nếu để bộ điều khiển biết rõ về hình dạng đĩa, xử lý yêu cầu nhanh nhất có thể. khả thi. Nhưng có vẻ như "thời hạn" cải thiện hiệu suất. Bạn có thể đọc thêm về bộ lập lịch trong tài liệu mã nguồn nhân Linux: linux/Documentation/block/*osched.txt. Và tôi cũng đã thấy thông lượng đọc tăng lên trong các hoạt động hỗn hợp (nhiều lần ghi).

"256" > /sys/block/sdc/queue/nr_requests

Số lượng yêu cầu I/O trong bộ đệm trước khi chúng được chuyển đến bộ lập lịch. Kích thước hàng đợi bên trong của một số bộ điều khiển (queue_depth) lớn hơn nr_requests của bộ lập lịch I/O, vì vậy bộ lập lịch I/O có ít cơ hội ưu tiên và hợp nhất các yêu cầu một cách hợp lý. Đối với lịch trình thời hạn và CFQ, sẽ tốt hơn khi nr_requests gấp 2 lần hàng đợi nội bộ của bộ điều khiển. Hợp nhất và sắp xếp lại các yêu cầu giúp bộ lập lịch phản ứng nhanh hơn khi tải nặng.

echo "16"> /proc/sys/vm/page-cluster

Tham số cụm trang kiểm soát số lượng trang được ghi vào trao đổi cùng một lúc. Trong ví dụ trên, giá trị được đặt thành "16" theo kích thước sọc RAID là 64 KB. Nó không hợp lý với swappiness = 0, nhưng nếu bạn đặt swappiness thành 10 hoặc 20 thì việc sử dụng giá trị này sẽ giúp ích cho bạn khi kích thước sọc RAID là 64K.

blockdev --setra 4096 /dev/<tên phát minh> (-sdb, hdc hoặc dev_mapper)

Cài đặt khối thiết bị mặc định cho nhiều bộ điều khiển RAID thường dẫn đến hiệu suất khủng khiếp. Việc thêm tùy chọn ở trên sẽ thiết lập tính năng đọc trước cho các cung 4096 * 512 byte. Ít nhất, đối với các hoạt động phát trực tuyến, tốc độ được tăng lên bằng cách lấp đầy bộ đệm đĩa trên chip bằng tính năng đọc trước trong khoảng thời gian được nhân sử dụng để chuẩn bị I/O. Bộ đệm có thể chứa dữ liệu sẽ được yêu cầu trong lần đọc tiếp theo. Quá nhiều tìm nạp trước có thể giết chết I/O ngẫu nhiên đối với các tệp lớn nếu nó sử dụng hết thời gian đĩa có thể hữu ích hoặc tải dữ liệu bên ngoài bộ đệm.

Dưới đây là một vài đề xuất khác ở cấp hệ thống tệp. Nhưng chúng vẫn chưa được thử nghiệm. Đảm bảo rằng hệ thống tệp của bạn biết kích thước của dải và số lượng đĩa trong mảng. Ví dụ: đây là mảng 5K sọc đột kích64 gồm sáu đĩa (thực tế là năm đĩa, vì một đĩa được sử dụng cho tính chẵn lẻ). Những đề xuất này dựa trên các giả định lý thuyết và được các chuyên gia RAID tổng hợp từ nhiều blog/bài viết khác nhau.

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

Đối với các tệp lớn, hãy cân nhắc tăng kích thước sọc được liệt kê ở trên.

Chú ý! Mọi thứ được mô tả ở trên đều mang tính chủ quan cao đối với một số loại ứng dụng. Bài viết này không đảm bảo bất kỳ cải tiến nào mà không có thử nghiệm trước của người dùng đối với các ứng dụng liên quan. Nó chỉ nên được sử dụng nếu cần cải thiện khả năng đáp ứng tổng thể của hệ thống hoặc nếu nó giải quyết các vấn đề hiện tại.

Tài liệu bổ sung:

Thiết lập nhân Linux cho GlusterFS

Đọc thêm

Nguồn: www.habr.com

Thêm một lời nhận xét