Một số điểm không liên quan:
80K là rất nhiều tập tin.
80.000 tập tin trong một thư mục? Không có hệ điều hành hoặc ứng dụng xử lý tình huống đó theo mặc định. Bạn chỉ tình cờ nhận thấy vấn đề này với rsync.
Kiểm tra phiên bản rsync của bạn
Rsync hiện đại xử lý các thư mục lớn tốt hơn rất nhiều so với trước đây. Hãy chắc chắn rằng bạn đang sử dụng phiên bản mới nhất.
Ngay cả rsync cũ cũng xử lý các thư mục lớn khá tốt qua các liên kết có độ trễ cao ... nhưng các tệp 80k không lớn ... nó rất lớn!
Điều đó nói rằng, việc sử dụng bộ nhớ của rsync tỷ lệ thuận với số lượng tệp trong một cây. Các thư mục lớn cần một lượng lớn RAM. Sự chậm chạp có thể là do thiếu RAM ở hai bên. Thực hiện chạy thử trong khi xem sử dụng bộ nhớ. Linux sử dụng bất kỳ RAM còn lại làm bộ đệm đĩa, vì vậy nếu bạn sắp hết RAM, sẽ có ít bộ đệm hơn. Nếu bạn hết RAM và hệ thống bắt đầu sử dụng trao đổi, hiệu suất sẽ rất tệ.
Hãy chắc chắn --checksum không được sử dụng
--checksum(hoặc -c) yêu cầu đọc từng khối của mỗi tệp. Bạn có thể có thể nhận được bằng hành vi mặc định chỉ đọc thời gian sửa đổi (được lưu trong inode).
Chia công việc thành các đợt nhỏ.
Có một số dự án như Gigasync sẽ "Cắt giảm khối lượng công việc bằng cách sử dụng perl để lấy lại cây thư mục, xây dựng danh sách nhỏ các tệp để chuyển bằng rsync."
Quét thư mục bổ sung sẽ là một số lượng lớn chi phí, nhưng có thể nó sẽ là một chiến thắng ròng.
Mặc định hệ điều hành không được thực hiện cho tình huống này.
Nếu bạn đang sử dụng Linux / FreeBSD / etc với tất cả các giá trị mặc định, hiệu suất sẽ rất tệ cho tất cả các ứng dụng của bạn. Mặc định giả định các thư mục nhỏ hơn để không lãng phí RAM cho bộ nhớ quá khổ.
Điều chỉnh hệ thống tập tin của bạn để xử lý tốt hơn các thư mục lớn: Kích thước thư mục lớn có làm chậm hiệu suất IO không?
Nhìn vào "tên cache"
Các hệ điều hành giống như BSD có bộ đệm tăng tốc tìm kiếm tên cho inode (bộ đệm "namei"). Có một bộ đệm tên cho mỗi thư mục. Nếu quá nhỏ, nó gây trở ngại nhiều hơn là tối ưu hóa. Vì rsync đang thực hiện lstat () trên mỗi tệp, nên inode được truy cập cho mỗi một trong số 80k tệp. Điều đó có thể làm hỏng bộ đệm của bạn. Nghiên cứu cách điều chỉnh hiệu suất thư mục tệp trên hệ thống của bạn.
Hãy xem xét một hệ thống tập tin khác
XFS được thiết kế để xử lý các thư mục lớn hơn. Xem hệ thống tập tin số lượng lớn các tập tin trong một thư mục
Có lẽ 5 phút là tốt nhất bạn có thể làm.
Xem xét tính toán có bao nhiêu khối đĩa đang được đọc và tính toán tốc độ bạn mong đợi phần cứng có thể đọc được bao nhiêu khối.
Có thể kỳ vọng của bạn quá cao. Xem xét có bao nhiêu khối đĩa phải được đọc để thực hiện một rsync không có tệp thay đổi: mỗi máy chủ sẽ cần đọc thư mục và đọc một nút trên mỗi tệp. Giả sử không có gì được lưu trong bộ nhớ cache vì, tốt, các tệp 80k có thể đã làm hỏng bộ nhớ cache của bạn. Hãy nói rằng đó là khối 80k để giữ cho toán học đơn giản. Đó là khoảng 40 triệu dữ liệu, có thể đọc được trong vài giây. Tuy nhiên, nếu cần phải có một đĩa tìm kiếm giữa mỗi khối, điều đó có thể mất nhiều thời gian hơn.
Vì vậy, bạn sẽ cần phải đọc khoảng 80.000 khối đĩa. Làm thế nào nhanh ổ cứng của bạn có thể làm điều đó? Xem xét rằng đây là I / O ngẫu nhiên, không phải là đọc tuyến tính dài, 5 phút có thể khá xuất sắc. Đó là 1 / (80000/600) hoặc đĩa đọc sau mỗi 7,5ms. Đó là nhanh hay chậm cho ổ cứng của bạn? Nó phụ thuộc vào mô hình.
Điểm chuẩn đối với một cái gì đó tương tự
Một cách khác để suy nghĩ về nó là điều này. Nếu không có tệp nào thay đổi, ls -Llrsẽ thực hiện cùng một lượng hoạt động của đĩa nhưng không bao giờ đọc bất kỳ dữ liệu tệp nào (chỉ siêu dữ liệu). Thời gian ls -Llrđể chạy là giới hạn trên của bạn.
Là rsync (không có tệp thay đổi) chậm hơn đáng kể so với ls -Llr? Sau đó, các tùy chọn bạn đang sử dụng cho rsync có thể được cải thiện. Có thể -cđược bật hoặc một số cờ khác đọc nhiều hơn chỉ thư mục và siêu dữ liệu (dữ liệu inode).
Là rsync (không có tập tin thay đổi) gần như nhanh như ls -Llrvậy? Sau đó, bạn đã điều chỉnh rsync tốt nhất có thể. Bạn phải điều chỉnh HĐH, thêm RAM, nhận ổ đĩa nhanh hơn, thay đổi hệ thống tập tin, v.v.
Nói chuyện với các dev của bạn
80k tập tin chỉ là thiết kế xấu. Rất ít hệ thống tập tin và công cụ hệ thống xử lý các thư mục lớn như vậy rất tốt. Nếu tên tệp là abcdefg.txt, hãy xem xét lưu trữ chúng trong abdc / abcdefg.txt (lưu ý sự lặp lại). Điều này phá vỡ các thư mục thành các thư mục nhỏ hơn, nhưng không đòi hỏi một sự thay đổi lớn đối với mã.
Ngoài ra .... xem xét sử dụng một cơ sở dữ liệu. Nếu bạn có 80k tệp trong một thư mục, có thể các nhà phát triển của bạn đang làm việc xung quanh thực tế rằng những gì họ thực sự muốn là một cơ sở dữ liệu. MariaDB hoặc MySQL hoặc PostgreSQL sẽ là một lựa chọn tốt hơn nhiều để lưu trữ lượng lớn dữ liệu.
Này, có gì sai với 5 phút?
Cuối cùng, là 5 phút thực sự rất xấu? Nếu bạn chạy bản sao lưu này một lần một ngày, 5 phút không phải là nhiều thời gian. Vâng, tôi yêu tốc độ. Tuy nhiên, nếu 5 phút là "đủ tốt" cho khách hàng của bạn, thì nó đủ tốt cho bạn. Nếu bạn không có SLA bằng văn bản, làm thế nào về một cuộc thảo luận không chính thức với người dùng của bạn để tìm hiểu xem họ dự kiến sẽ sao lưu nhanh như thế nào.
Tôi cho rằng bạn đã không hỏi câu hỏi này nếu không cần phải cải thiện hiệu suất. Tuy nhiên, nếu khách hàng của bạn hài lòng với 5 phút, hãy tuyên bố chiến thắng và chuyển sang các dự án khác cần nỗ lực của bạn.
Cập nhật: Sau một số cuộc thảo luận, chúng tôi xác định rằng nút cổ chai là mạng. Tôi sẽ đề nghị 2 điều trước khi tôi từ bỏ :-).
- Cố gắng nén thêm băng thông ra khỏi đường ống bằng nén. Tuy nhiên, việc nén đòi hỏi nhiều CPU hơn, vì vậy nếu CPU của bạn bị quá tải, nó có thể làm cho hiệu suất kém hơn. Hãy thử rsync có và không có
-z, và định cấu hình ssh của bạn có và không nén. Thời gian tất cả 4 kết hợp để xem nếu bất kỳ trong số họ thực hiện tốt hơn đáng kể so với những người khác.
- Xem lưu lượng truy cập mạng để xem nếu có bất kỳ tạm dừng. Nếu có tạm dừng, bạn có thể tìm thấy những gì gây ra chúng và tối ưu hóa ở đó. Nếu rsync luôn gửi, thì bạn thực sự đang ở giới hạn của mình. Lựa chọn của bạn là:
- một mạng nhanh hơn
- một cái gì đó khác với rsync
- di chuyển nguồn và đích đến gần nhau hơn. Nếu bạn không thể làm điều đó, bạn có thể rsync đến một máy cục bộ sau đó rsync đến đích thực không? Có thể có lợi ích khi làm điều này nếu hệ thống phải ngừng hoạt động trong rsync ban đầu.