Tối ưu hóa ZFS ARC: Giới hạn, ngưỡng và các chỉ số cần đo lường

Theo mặc định, ZFS sẽ âm thầm chiếm khoảng một nửa RAM hệ thống của bạn để làm bộ nhớ đệm đọc (read cache), và trên loại máy chủ không phù hợp, điều này có thể dẫn đến hoạt động swap, các quá trình bị ngắt do hết bộ nhớ (OOM kills) hoặc cơ sở dữ liệu phải cạnh tranh với hệ thống tệp để giành bộ nhớ. Việc tối ưu hóa ARC của ZFS liên quan đến việc quyết định lượng RAM mà ARC thực sự được phép giữ lại, cũng như những gì bạn phải hy sinh để thiết lập giới hạn đó. Bài viết này trình bày cách ARC sử dụng bộ nhớ, những chỉ số cần đo lường trước khi thực hiện bất kỳ thay đổi nào, một số thông số đáng điều chỉnh, cùng các điểm khởi đầu hợp lý cho máy chủ tệp, hypervisor, cơ sở dữ liệu và các mục tiêu sao lưu. Đối với tính năng snapshot của ZFS, hãy tham khảo hướng dẫn về snapshot ZFS của chúng tôi.

Hãy đo lường ARC trước khi điều chỉnh bất kỳ thông số nào

Không thay đổi bất kỳ thông số nào cho đến khi bạn có số liệu cơ sở từ một khoảng thời gian bận rộn bình thường. Các bản chụp nhanh trong khoảng thời gian ít hoạt động sẽ dẫn bạn đi sai hướng. Sao lưu hàng đêm, báo cáo hàng tuần và các tác vụ hàng loạt thường là những lúc hành vi ARC trở nên thú vị, vì vậy hãy thu thập dữ liệu trong vài ngày.

Ba công cụ sau đây đáp ứng hầu hết nhu cầu của bạn:

• arcstat 1 cung cấp chế độ xem cuộn trực tiếp các bộ đếm trúng và trượt, hoạt động theo nhu cầu so với hoạt động lấy trước, và kích thước ARC hiện tại. Sử dụng công cụ này trong các bài kiểm tra tải và các khung thời gian sao lưu.
• arc_summary in ra một bản chụp nhanh duy nhất: kích thước ARC và mục tiêu, tỷ lệ phân chia MFU/MRU, tỷ lệ siêu dữ liệu và các thông số điều chỉnh đang hoạt động. Chạy arc_summary -s arc chỉ cho phần ARC.
• Các chỉ số thô tồn tại trong /proc/spl/kstat/zfs/arcstats trên Linux và dưới kstat.zfs.misc và vfs.zfs cây sysctl trên FreeBSD. Hãy trích xuất các thông số này từ hệ thống giám sát thay vì phân tích đầu ra đã được định dạng.

Các chỉ số cần ghi lại trước khi thực hiện bất kỳ thay đổi nào:

Có hai điều mà mọi người thường nhầm lẫn ở đây. Hãy theo dõi bộ nhớ khả dụng, không phải bộ nhớ trống; Linux thường báo cáo mức RAM trống thấp như một trạng thái ổn định và điều đó bản thân nó không phải là vấn đề. Dấu hiệu quan trọng là bộ nhớ khả dụng gần bằng không kết hợp với hoạt động hoán đổi liên tục (tài liệu giới thiệu về quản lý bộ nhớ Linux giải thích lý do tại sao). Và hãy coi tỷ lệ trúng (hit ratio) như một xu hướng, chứ không phải là mục tiêu. Tỷ lệ trúng 99% trên một hệ thống đang thực hiện hoán đổi là một thất bại trong việc tối ưu hóa, chứ không phải là thành công.

Bốn thông số ARC quan trọng

Hầu hết việc điều chỉnh trong môi trường sản xuất đều tập trung vào bốn thông số này. Hãy điều chỉnh các thông số sao cho phù hợp với áp lực mà bạn đã đo được trong giai đoạn cơ sở. Hoạt động hoán đổi chỉ ra zfs_arc_max. Khôi phục các điểm churn liên tục xóa bộ nhớ cache nóng chỉ ra zfs_arc_min. Tốc độ quét thư mục chậm cho thấy giới hạn metadata.

Hãy bắt đầu với thay đổi nhỏ nhất có thể giải quyết áp lực mà bạn đang gặp phải. Đối với zfs_arc_max, mức trần phù hợp phụ thuộc vào khối lượng công việc (sẽ được đề cập trong phần tiếp theo). Đối với zfs_arc_min, mức sàn từ 25% đến 50% zfs_arc_max là điểm khởi đầu hợp lý nếu bạn thực sự cần thiết lập giới hạn này. Đối với siêu dữ liệu, các giá trị mặc định gần đây của OpenZFS đã phân bổ 75% dung lượng ARC cho siêu dữ liệu thông qua zfs_arc_meta_limit_percent, mức này đã rất dồi dào cho hầu hết các khối lượng công việc; chỉ nên điều chỉnh khi các lỗi metadata xuất hiện rõ ràng trong arcstat.

Áp dụng thay đổi trên Linux và FreeBSD

Trên Linux, hãy kiểm tra một thay đổi trong khi hệ thống đang chạy bằng cách ghi vào tệp tham số sysfs. Không cần khởi động lại:

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

Điều này sẽ thiết lập zfs_arc_max thành 16 GiB ngay lập tức. Để thay đổi này vẫn tồn tại sau khi khởi động lại, hãy thêm nó vào /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

Trên FreeBSD, các thay đổi trong thời gian chạy sử dụng sysctl:

sysctl vfs.zfs.arc_max=17179869184

Duy trì cùng giá trị trong /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Thay đổi từng cài đặt một, theo các bước nhỏ khoảng 10% tổng dung lượng RAM. Theo dõi cửa sổ hiển thị vấn đề. Chỉ giữ lại thay đổi nếu swap duy trì ở mức 0 và độ trễ ổn định. Chỉ lưu lại thay đổi sau khi kiểm tra trong quá trình chạy thành công.

Điều chỉnh ARC theo khối lượng công việc

Tổng dung lượng RAM không phải là điểm khởi đầu phù hợp. Việc xác định kích thước ARC nên dựa trên sự kết hợp của các tải công việc trên hệ thống.

Máy chủ VM cần chia sẻ bộ nhớ với các máy khách của mình, do đó giới hạn từ 30% đến 40% là mức mặc định an toàn và 50% đã là quá cao đối với hầu hết các bản dựng. Các cơ sở dữ liệu như PostgreSQL và MySQL tự quản lý bộ đệm của riêng mình, vì vậy bạn nên dành bộ nhớ cho động cơ trước và để ARC sử dụng phần còn lại. Các mục tiêu sao lưu được hưởng lợi từ primarycache=metadata vì dữ liệu đang được đọc hiếm khi được sử dụng lại, và bạn không muốn quá trình sao lưu hàng đêm quét toàn bộ vùng nhớ và xóa phần còn lại của bộ đệm trong quá trình đó. Đối với mọi tải công việc, hoạt động trao đổi (swap) khi ARC bị khóa ở zfs_arc_max có nghĩa là giới hạn này quá cao; quy tắc đó không thay đổi.

Chẩn đoán sự cố và biết khi nào nên dừng lại

ARC có dung lượng quá nhỏ sẽ biểu hiện dưới dạng IOPS đọc cao, tỷ lệ truy cập yêu cầu thấp và duyệt thư mục chậm trong khi hệ thống vẫn còn RAM trống. ARC có dung lượng quá lớn thì ít rõ ràng hơn. Tỷ lệ truy cập có vẻ ổn, nhưng máy bắt đầu hoán đổi, tải trung bình tăng cao, các tiến trình bị chặn trong D trong khi kernel thu hồi các trang ARC theo yêu cầu, và trong trường hợp xấu nhất, OOM killer bắt đầu chọn các nạn nhân. Bộ nhớ cache trông vẫn ổn nhưng máy chủ hoạt động rất chậm.

Áp lực siêu dữ liệu xuất hiện khi demand_metadata_bytes cao hơn nhiều so với demand_data_bytes trong arc_summary. Đó là lúc metadata đang tranh giành không gian với dữ liệu, và giới hạn phần trăm metadata đáng được nâng lên.

So sánh những gì bạn thấy với cài đặt đầu tiên cần kiểm tra:

L2ARC không phải là miễn phí. Chỉ mục cho các mục L2ARC nằm trong ARC chính, và nếu chi phí này vượt quá khoảng một phần ba tổng dung lượng ARC, bộ nhớ đệm thứ cấp sẽ gây hại nhiều hơn lợi. Chỉ nên sử dụng L2ARC khi tập dữ liệu làm việc lớn hơn RAM nhưng vẫn vừa với thiết bị NVMe nhanh, và chỉ khi tỷ lệ trúng của ARC chính đã ở mức ổn định.

Thời điểm thích hợp để ngừng tối ưu hóa là khi độ trễ ổn định, việc trao đổi bộ nhớ (swap) duy trì ở mức 0 trong cùng khoảng thời gian tải cao đã gây ra vấn đề ban đầu, và các thay đổi tiếp theo không còn mang lại cải thiện nào. Tỷ lệ trúng cao không có ý nghĩa gì nếu máy chủ đang thực hiện trao đổi bộ nhớ. Sau điểm đó, hãy ngừng điều chỉnh cài đặt và chỉ xem xét lại chúng nếu vấn đề tương tự tái diễn dưới cùng tải công việc.

Nếu bạn cần một máy chủ có dung lượng RAM dư dả để chạy ZFS một cách hiệu quả mà không phải cạnh tranh bộ nhớ với các máy ảo (VM) hoặc cơ sở dữ liệu (bạn nên đọc bài viết về lượng RAM thực sự cần thiết trước tiên), hãy tham khảo các máy chủ chuyên dụng FDC.