ZFS cực kỳ chậm lại sau vài tháng

Tôi đã có một máy chủ đa năng, cung cấp thư, DNS, web, cơ sở dữ liệu và một số dịch vụ khác cho một số người dùng.

Nó có Xeon E3-1275 với tốc độ 3,40 GHz, RAM 16 GB ECC. Chạy Linux kernel 4.2.3, với ZFS-on-Linux 0.6.5.3.

Bố cục đĩa là 2 ổ Seagate ST32000641AS 2 TB và 1x Samsung 840 Pro 256 GB SSD

Tôi đã có 2 HD trong máy nhân bản RAID-1 và SSD hoạt động như một thiết bị lưu trữ và ghi nhật ký, tất cả được quản lý trong ZFS.

Khi tôi lần đầu tiên thiết lập hệ thống, nó rất nhanh. Không có điểm chuẩn thực sự, chỉ là ... nhanh chóng.

Bây giờ, tôi nhận thấy sự chậm chạp cực độ, đặc biệt là trên hệ thống tập tin chứa tất cả các maildir. Thực hiện sao lưu hàng đêm mất hơn 90 phút cho chỉ 46 GB thư. Đôi khi, sao lưu gây ra một tải cực đoan đến mức hệ thống gần như không phản hồi trong tối đa 6 giờ.

Tôi đã chạy zpool iostat zroot(nhóm của tôi được đặt tên zroot) trong những lần chậm lại này và thấy ghi theo thứ tự 100-200kbyte / giây. Không có lỗi IO rõ ràng, đĩa dường như không hoạt động đặc biệt khó khăn, nhưng đọc gần như chậm một cách bất thường.

Điều kỳ lạ là tôi đã có trải nghiệm chính xác trên một máy khác, với phần cứng thông số tương tự, mặc dù không có SSD, chạy FreeBSD. Nó hoạt động tốt trong nhiều tháng, sau đó bị chậm theo cách tương tự.

Sự nghi ngờ của tôi là thế này: Tôi sử dụng zfs-auto-snapshot để tạo các ảnh chụp nhanh của mỗi hệ thống tập tin. Nó tạo ra các ảnh chụp nhanh 15 phút, hàng giờ, hàng ngày và hàng tháng và giữ một số lượng nhất định của mỗi xung quanh, xóa các ảnh chụp cũ nhất. Điều đó có nghĩa là theo thời gian, hàng ngàn ảnh chụp nhanh đã được tạo và hủy trên mỗi hệ thống tệp. Đó là hoạt động cấp hệ thống tập tin duy nhất mà tôi có thể nghĩ đến với hiệu ứng tích lũy. Tôi đã thử phá hủy tất cả các ảnh chụp nhanh (nhưng vẫn duy trì quá trình chạy, tạo các ảnh mới) và nhận thấy không có thay đổi.

Có vấn đề với việc liên tục tạo và phá hủy ảnh chụp nhanh? Tôi thấy có cho họ một công cụ cực kỳ giá trị, và đã được dẫn đến để tin rằng chúng (ngoài không gian đĩa) ít nhiều chi phí bằng không.

Có điều gì khác có thể gây ra vấn đề này?

EDIT: đầu ra lệnh

Đầu ra của zpool list:

NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot  1.81T   282G  1.54T         -    22%    15%  1.00x  ONLINE  -

Đầu ra của zfs list:

NAME             USED  AVAIL  REFER  MOUNTPOINT
zroot            282G  1.48T  3.55G  /
zroot/abs       18.4M  1.48T  18.4M  /var/abs
zroot/bkup      6.33G  1.48T  1.07G  /bkup
zroot/home       126G  1.48T   121G  /home
zroot/incoming  43.1G  1.48T  38.4G  /incoming
zroot/mail      49.1G  1.48T  45.3G  /mail
zroot/mailman   2.01G  1.48T  1.66G  /var/lib/mailman
zroot/moin       180M  1.48T   113M  /usr/share/moin
zroot/mysql     21.7G  1.48T  16.1G  /var/lib/mysql
zroot/postgres  9.11G  1.48T  1.06G  /var/lib/postgres
zroot/site       126M  1.48T   125M  /site
zroot/var       17.6G  1.48T  2.97G  legacy

Đây không phải là một hệ thống rất bận rộn, nói chung. Các đỉnh trên biểu đồ bên dưới là các bản sao lưu hàng đêm:

Tôi đã quản lý để bắt hệ thống trong thời gian chậm lại (bắt đầu khoảng 8 giờ sáng nay). Một số hoạt động khá nhạy, nhưng mức trung bình tải hiện là 145 và zpool listchỉ bị treo. Biểu đồ:

Nhìn vào arc_meta_use và arc_meta_limit. Với nhiều tệp nhỏ, bạn có thể điền vào bộ đệm dữ liệu meta trong ram để nó phải xem đĩa để biết thông tin tệp và có thể làm chậm quá trình thu thập dữ liệu.

Tôi không chắc chắn làm thế nào để làm điều này trên Linux, kinh nghiệm của tôi là trên FreeBSD.