Xóa các tệp 10M + khỏi ZFS, hiệu quả


30

Tôi đã viết một chương trình lỗi đã vô tình tạo ra khoảng 30 triệu tệp trong / tmp. (Lỗi này đã được giới thiệu vài tuần trước và nó đang tạo ra một vài thư mục con mỗi giây.) Tôi có thể đổi tên / tmp thành / tmp2, và bây giờ tôi cần xóa các tệp. Hệ thống là FreeBSD 10, hệ thống tập tin gốc là zfs.

Trong khi đó, một trong những ổ đĩa trong gương bị trục trặc và tôi đã thay thế nó. Ổ đĩa có hai đĩa SSD 120 GB.

Đây là câu hỏi: thay thế ổ đĩa cứng và phục hồi toàn bộ mảng mất chưa đầy một giờ. Xóa tập tin / tmp2 là một câu chuyện khác. Tôi đã viết một chương trình khác để xóa các tệp và nó chỉ có thể xóa 30-70 thư mục con mỗi giây. Sẽ mất 2-4 ngày để xóa tất cả các tập tin.

Làm thế nào có thể phục hồi toàn bộ mảng mất một giờ, nhưng xóa khỏi đĩa mất 4 ngày? Tại sao tôi có hiệu suất quá tệ? 70 xóa / giây dường như hiệu suất rất rất xấu.

Tôi có thể xóa inode cho / tmp2 bằng tay, nhưng điều đó sẽ không giải phóng không gian, phải không?

Đây có thể là một vấn đề với zfs, hoặc các ổ đĩa cứng hoặc những gì?


1
Tôi không phải là chuyên gia zfs, vì vậy tôi không thể nói chuyện điều chỉnh hiệu suất của bạn hoặc những gì bạn có thể làm để cải thiện nó (điều đó cũng sẽ mất nhiều thông tin và có lẽ tốt nhất nên được thực hiện trực tiếp bởi một chuyên gia). Tuy nhiên, tôi có thể nói rằng khả năng phục hồi xảy ra ở cấp độ khối, trong khi việc xóa của bạn xảy ra ở cấp hệ thống tệp. Hệ thống tập tin sẽ có phần lớn chi phí khi xóa bộ đệm inode hàng triệu như thế.
đệm

Xin vui lòng gửi của bạn df -hzpool listzfs list.
ewwhite

5
Viết một chương trình khác: rm -rf /tmp2sẽ không làm công việc?
Thorbjørn Ravn Andersen

2
Bạn có thể không chỉ khởi động lại? /tmpnên là một tmpfshệ thống tập tin và được lưu trữ trong bộ nhớ.
Máy xay sinh tố

Câu trả lời:


31

Xóa trong ZFS là đắt tiền. Thậm chí nhiều hơn nếu bạn có tính năng chống trùng lặp được kích hoạt trên hệ thống tệp (vì các tệp bị loại trừ hội nghị là đắt tiền). Ảnh chụp cũng có thể làm phức tạp vấn đề.

Bạn có thể tốt hơn hết là xóa /tmpthư mục thay vì dữ liệu chứa trong đó.

Nếu /tmplà một hệ thống tập tin ZFS, hãy xóa nó và tạo lại.


1
@nagylzs Trong trường hợp đó tôi sẽ đề nghị biến nó thành một hệ thống tệp ZFS riêng. Sau đó, bạn có thể di chuyển hiện tại / tmp ra khỏi đường đi, di chuyển một / tmp mới vào vị trí và xóa các tệp lúc rảnh rỗi của hệ thống. Kết quả: thời gian chết tối thiểu cộng với suy giảm hiệu năng nhẹ (có thể giảm thiểu với ionice, giả sử FreeBSD có nó) trong khi xóa đang chạy.
CVn

9
Tôi đã sai. Đó là một hệ thống tập tin riêng biệt. Đây là những gì đã hoạt động: khởi động lại vào chế độ người dùng đơn, sau đó thực hiện "zfs xóa zroot / tmp; zfs tạo zroot / tmp; chmod 41777 / tmp"
nagylzs

6
Đó là 5 phút tổng thời gian chết. Tuyệt diệu! :-)
nagylzs

1
Chà, điều đó cũng nói lên mối quan tâm của tôi, rằng việc xóa fike không bao giờ giải phóng không gian vì ảnh chụp nhanh. Nhưng tmp sẽ được thiết lập để không tạo ảnh chụp nhanh định kỳ tự động, phải không?
JDługosz

1
Trên thực tế, đây là: zfs tạo -o nén = on -o exec = on -o setuid = off zroot / tmp; chmod 1777 / zroot / tmp; zfs đặt mountpoint = / tmp zroot / tmp; Tôi không chắc chắn làm thế nào để tắt chụp nhanh tự động mặc dù. Có "zfs set com.sun: auto-snapshot = false" nhưng tôi nghĩ rằng nó chỉ hoạt động trên solaris.
nagylzs

27

Làm thế nào có thể phục hồi toàn bộ mảng mất một giờ, nhưng xóa khỏi đĩa mất 4 ngày?

Hãy xem xét một tòa nhà văn phòng.

Loại bỏ tất cả các máy tính và đồ nội thất và sửa chữa khỏi tất cả các văn phòng trên tất cả các tầng mất một thời gian dài , nhưng để lại các văn phòng có thể sử dụng ngay lập tức bởi một khách hàng khác.

Phá hủy toàn bộ tòa nhà bằng RDX nhanh hơn rất nhiều , nhưng khách hàng tiếp theo hoàn toàn có thể phàn nàn về việc nơi này tồi tệ đến mức nào.


5
ZFS không phải là một tòa nhà văn phòng :)
nhà phát triển

9
@developerbmw cũng không thực sự có một tập tin hoặc thư mục trên đó nhưng chúng ta cần các khái niệm ẩn dụ để hiểu những gì đang xảy ra.
JamesRyan

2
@JamesRyan yep nó thực sự là một sự tương tự tốt đẹp ... Tôi chỉ là ngu ngốc
nhà phát triển xe máy

5

Có một số điều đang diễn ra ở đây.

Đầu tiên, tất cả các công nghệ đĩa hiện đại được tối ưu hóa để chuyển số lượng lớn. Nếu bạn cần di chuyển 100 MB dữ liệu, họ sẽ thực hiện nhanh hơn nhiều nếu chúng ở trong một khối liền kề thay vì nằm rải rác khắp nơi. SSD giúp rất nhiều ở đây, nhưng thậm chí họ thích dữ liệu trong các khối liền kề.

Thứ hai, khả năng phục hồi là khá tối ưu cho đến khi hoạt động của đĩa. Bạn đọc một khối dữ liệu liền kề khổng lồ từ một đĩa, thực hiện một số thao tác CPU nhanh trên nó, sau đó viết lại thành một đoạn lớn tiếp giáp với một đĩa khác. Nếu mất điện giữa chừng, không có vấn đề gì lớn - bạn sẽ bỏ qua mọi dữ liệu có tổng kiểm tra xấu và tiếp tục như bình thường.

Thứ ba, xóa một tập tin là rất chậm . ZFS đặc biệt xấu, nhưng thực tế tất cả các hệ thống tập tin đều chậm xóa. Họ phải sửa đổi một số lượng lớn các khối dữ liệu khác nhau trên đĩa và thời gian chính xác (tức là chờ) để hệ thống tập tin không bị hỏng nếu mất điện.

Làm thế nào có thể phục hồi toàn bộ mảng mất một giờ, nhưng xóa khỏi đĩa mất 4 ngày?

Khả năng phục hồi là thứ mà các đĩa thực sự rất nhanh và việc xóa là thứ mà các đĩa bị chậm. Mỗi megabyte của đĩa, bạn chỉ phải thực hiện một chút khả năng phục hồi. Bạn có thể có một ngàn tệp trong không gian đó cần phải xóa.

70 xóa / giây hiệu suất có vẻ rất rất xấu

Nó phụ thuộc. Tôi sẽ không ngạc nhiên về điều này. Bạn chưa đề cập đến loại SSD nào bạn đang sử dụng. SSD Intel và Samsung hiện đại khá tốt trong loại hoạt động này (đọc-sửa đổi-ghi) và sẽ hoạt động tốt hơn. SSD rẻ hơn / cũ hơn (ví dụ Corsair) sẽ chậm. Số lượng thao tác I / O mỗi giây (IOPS) là yếu tố quyết định ở đây.

ZFS đặc biệt chậm để xóa mọi thứ. Thông thường, nó sẽ thực hiện xóa trong nền để bạn không thấy độ trễ. Nếu bạn đang làm một số lượng lớn trong số họ, nó không thể che giấu nó và phải trì hoãn bạn.


Phụ lục: tại sao xóa chậm?

  • Xóa một tập tin đòi hỏi một vài bước. Siêu dữ liệu tệp phải được đánh dấu là 'đã xóa' và cuối cùng nó phải được lấy lại để không gian có thể được sử dụng lại. ZFS là một "hệ thống tập tin có cấu trúc nhật ký" hoạt động tốt nhất nếu bạn chỉ tạo ra mọi thứ, không bao giờ xóa chúng. Cấu trúc nhật ký có nghĩa là nếu bạn xóa một cái gì đó, có một khoảng trống trong nhật ký và do đó, dữ liệu khác phải được sắp xếp lại (phân mảnh) để lấp đầy khoảng trống. Điều này là vô hình với người dùng nhưng nói chung là chậm.
  • Các thay đổi phải được thực hiện theo cách mà nếu mất điện giữa chừng, hệ thống tập tin vẫn nhất quán. Thông thường, điều này có nghĩa là chờ cho đến khi đĩa xác nhận rằng dữ liệu thực sự có trên phương tiện truyền thông; đối với một ổ SSD, có thể mất nhiều thời gian (hàng trăm mili giây). Hiệu quả ròng của việc này là có nhiều sổ sách kế toán hơn (tức là hoạt động I / O của đĩa).
  • Tất cả những thay đổi là nhỏ. Thay vì đọc, viết và xóa toàn bộ khối flash (hoặc hình trụ cho đĩa từ), bạn cần sửa đổi một chút của một khối. Để làm điều này, phần cứng phải đọc trong toàn bộ một khối hoặc hình trụ, sửa đổi nó trong bộ nhớ, sau đó ghi lại ra phương tiện truyền thông một lần nữa. Điều này mất một thời gian dài.

Tôi không biết về ZFS, nhưng một số hệ thống tệp cho phép bạn hủy liên kết thư mục với nội dung, nhưng những nội dung đó sẽ bị xóa sau đó trong giai đoạn thu gom / phân mảnh / dọn rác. ZFS có tiện ích nào để xóa một cách lười biếng như vậy không? Nó sẽ không thực sự tăng tốc độ xóa của OP nhưng có thể sẽ làm cho nó ít gặp vấn đề hơn nếu nó xảy ra ngầm trong quá trình vệ sinh.
Vality

2

Làm thế nào có thể phục hồi toàn bộ mảng mất một giờ, nhưng xóa khỏi đĩa mất 4 ngày?

Có thể bởi vì hai hoạt động trên các lớp khác nhau của ngăn xếp hệ thống tệp. Khả năng phục hồi có thể chạy mức độ thấp và thực sự không cần phải xem từng tệp riêng lẻ, sao chép khối dữ liệu lớn tại một thời điểm.

Tại sao tôi có hiệu suất quá tệ? 70 xóa / giây dường như hiệu suất rất rất xấu.

Nó phải làm rất nhiều sổ sách kế toán ...

Tôi có thể xóa inode cho / tmp2 bằng tay, nhưng điều đó sẽ không giải phóng không gian, phải không?

Tôi không biết về ZFS, nhưng nếu nó có thể tự động phục hồi từ đó, cuối cùng, nó có thể sẽ thực hiện các thao tác giống như bạn đang làm, trong nền.

Đây có thể là một vấn đề với zfs, hoặc các ổ đĩa cứng hoặc những gì?

zfs scrubnói gì không?


2

Xóa nhiều tập tin không bao giờ thực sự là một hoạt động nhanh chóng.

Để xóa tệp trên bất kỳ hệ thống tệp nào , bạn cần đọc chỉ mục tệp, xóa (hoặc đánh dấu là đã xóa) mục nhập tệp trong chỉ mục, xóa mọi siêu dữ liệu khác được liên kết với tệp và đánh dấu khoảng trống được phân bổ cho tệp là không sử dụng Điều này phải được thực hiện riêng cho từng tệp bị xóa, điều đó có nghĩa là việc xóa nhiều tệp yêu cầu nhiều I / O nhỏ. Để làm điều này theo cách đảm bảo tính toàn vẹn dữ liệu trong trường hợp mất điện sẽ tăng thêm chi phí.

Ngay cả khi không có tính đặc thù mà ZFS giới thiệu, việc xóa 30 triệu tệp thường có nghĩa là hơn một trăm triệu thao tác I / O riêng biệt. Điều này sẽ mất nhiều thời gian ngay cả với ổ SSD nhanh. Như những người khác đã đề cập, thiết kế của ZFS càng làm tăng thêm vấn đề này.


2

Ian Howson đưa ra một câu trả lời tốt về lý do tại sao nó chậm.

Nếu bạn xóa các tệp song song, bạn có thể thấy tốc độ tăng do việc xóa có thể sử dụng cùng một khối và do đó có thể lưu lại việc viết lại cùng một khối nhiều lần.

Hãy thử

find /tmp -print0 | parallel -j100 -0 -n100 rm

và xem nếu điều đó thực hiện tốt hơn 70 lần xóa của bạn mỗi giây.


0

Rất đơn giản nếu bạn đảo ngược suy nghĩ của bạn.

  1. Nhận một ổ đĩa thứ hai (dường như bạn đã có cái này rồi)

  2. Sao chép mọi thứ từ ổ A sang ổ B bằng rsync, ngoại trừ thư mục / tmp. Rsync sẽ chậm hơn một bản sao khối.

  3. Khởi động lại, sử dụng ổ B làm ổ đĩa khởi động mới

  4. Ổ đĩa định dạng A.

Điều này cũng sẽ chống phân mảnh ổ đĩa của bạn và cung cấp cho bạn một thư mục mới (tốt, chống phân mảnh không quá quan trọng với SSD nhưng tuyến tính hóa các tệp của bạn không bao giờ làm tổn thương bất cứ điều gì)


Trước hết sao chép mọi thứ trừ / tmp? Vậy bao gồm / dev và / Proc? Thứ hai, âm thanh hơi khó nghe với tôi, đặc biệt là trên một máy chủ sản xuất.
Hennes

Tôi cho rằng anh ta đủ thông minh để loại trừ các tập tin không, tập tin được gắn và thư mục bộ nhớ ảo, hầu hết không thể đoán được ở đây. Hoặc làm điều đó từ một khởi động bảo trì, nơi không có những điều đó quan trọng.
peter

Tôi nghĩ bạn cũng có thể zfs send/recv(sao chép cấp khối) tất cả các hệ thống tệp khác ngoại trừ hệ thống tệp gốc (trong đó / tmp nằm trong trường hợp này) và sao chép dữ liệu còn lại trên hệ thống tệp gốc theo cách thủ công (tất nhiên không bao gồm / tmp).
121391

2
Điều đó sẽ làm mất các ảnh chụp nhanh và bỏ qua một số tính năng đáng tin cậy. Thiếu điểm sử dụng zfs.
JDługosz

2
@ JDługosz điểm hợp lệ, nhưng chỉ liên quan nếu người dùng quan tâm. Đại loại như "bản sao lưu của tôi bị hỏng, làm thế nào để sửa chữa?" -> "Bạn có cần bất kỳ tập tin sao lưu nào không?" -> "Không." -> "Định dạng lại".
peter

-1

Bạn có 30 triệu mục trong một danh sách chưa sắp xếp. Bạn quét danh sách cho mục bạn muốn xóa và bạn xóa nó. Bây giờ bạn chỉ có 29.999.999 mục trong danh sách chưa sắp xếp của bạn. Nếu tất cả đều trong / tmp, tại sao không khởi động lại?


Đã chỉnh sửa để phản ánh thông tin trong các nhận xét: Báo cáo sự cố: Loại bỏ hầu hết, nhưng không phải tất cả , trong số 30M + tệp được tạo không chính xác trong / tmp đang mất nhiều thời gian.
Vấn đề 1) Cách tốt nhất để xóa số lượng lớn các tệp không mong muốn khỏi / tmp.
Vấn đề 2) Hiểu lý do tại sao quá chậm để xóa các tập tin.

Giải pháp 1) - / tmp được đặt lại thành trống khi khởi động bởi hầu hết các bản phân phối * nix. FreeBSD tuy nhiên, không phải là một trong số họ.
Bước 1 - sao chép các tập tin thú vị ở một nơi khác.
Bước 2 - Là root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Bước 3 - khởi động lại.
Bước 4 - thay đổi Clear_tmp_enable trở lại thành "Không".
Các tệp không mong muốn hiện đã biến mất vì ZFS trên FreeBSD có tính năng "Phá hủy tập dữ liệu nhanh hơn nhiều so với xóa tất cả các tệp nằm trong tập dữ liệu, vì nó không liên quan đến việc quét tất cả các tệp và cập nhật tất cả các siêu dữ liệu tương ứng. " vì vậy tất cả những gì phải làm khi khởi động là đặt lại siêu dữ liệu cho tập dữ liệu / tmp. Điều này rất nhanh chóng.

Giải pháp 2) Tại sao nó quá chậm? ZFS là một hệ thống tệp tuyệt vời bao gồm các tính năng như truy cập thư mục thời gian không đổi. Điều này hoạt động tốt nếu bạn biết những gì bạn đang làm, nhưng bằng chứng cho thấy OP không phải là chuyên gia ZFS. OP đã không chỉ ra cách họ cố gắng xóa các tệp, nhưng theo phỏng đoán, tôi sẽ nói rằng họ đã sử dụng một biến thể trên "find regex -exec rm {} \;". Điều này hoạt động tốt với số lượng nhỏ nhưng không mở rộng được vì có ba thao tác nối tiếp đang diễn ra 1) lấy danh sách các tệp có sẵn (trả về 30 triệu tệp theo thứ tự băm), 2) sử dụng regex để chọn tệp tiếp theo sẽ bị xóa, 3 ) báo cho HĐH tìm và xóa tệp đó khỏi danh sách 30 triệu. Ngay cả khi ZFS trả về một danh sách từ bộ nhớ và nếu 'Tìm' lưu trữ nó, regex vẫn phải xác định tệp tiếp theo sẽ được xử lý từ danh sách và sau đó báo cho HĐH cập nhật siêu dữ liệu của nó để phản ánh thay đổi đó và sau đó cập nhật danh sách để nó không được xử lý lại.


1
Tôi nghĩ rằng bạn đã hiểu nhầm câu hỏi. Tôi cần phải loại bỏ hầu hết các tập tin. Đó là, 30M + tệp.
nagylzs

@nagylzs / tmp bị xóa khi khởi động lại. Nếu bạn muốn xóa hầu hết , thì bạn chỉ muốn giữ một số , tức là ít hơn một nửa, vì vậy hãy sao chép những cái bạn muốn giữ và sau đó khởi động lại để loại bỏ phần còn lại. Lý do việc xóa của bạn quá chậm là vì có số lượng lớn tệp trong thư mục dẫn đến một danh sách chưa được sắp xếp lớn cần được xử lý để tìm tệp được vận hành, điều này cần có thời gian. Vấn đề duy nhất ở đây là PEBCAK.
Paul Smith

Thư mục Zfs không được sắp xếp ? Tôi nghĩ rằng zfs đặc biệt xử lý các thư mục lớn tốt.
JDługosz

Chà, / tmp không bị xóa, chỉ có các tệp liên quan đến X. Ít nhất là trên FreeBSD. Dù sao thì nó cũng không thể bị xóa khi khởi động, vì sẽ mất nhiều ngày để tập lệnh RC xóa bình thường.
nagylzs

@JDlugosz - ZFS tốt hơn nhiều, nhưng hầu hết các danh sách inode (là tất cả các thư mục) đều không được sắp xếp.
Paul Smith
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.