Hiệu suất dự kiến ​​của obnam là gì? Hoặc: tại sao nó quá chậm?


8

Tôi đã chơi xung quanh với obnam trong vài ngày qua, và mặc dù nó có vẻ rất hứa hẹn và dường như cung cấp về cơ bản mọi thứ tôi muốn trong một công cụ sao lưu, tôi khá thất vọng về hiệu suất của nó. Trên thực tế, nó rất chậm, tôi nghi ngờ rằng obnam thậm chí không có lỗi ở đây, nhưng một cái gì đó trong môi trường của tôi đang gây ra nó.

Vì vậy, tôi chủ yếu tự hỏi, nếu bất cứ ai khác đang sử dụng obnam hoặc biết rõ nội bộ của nó đủ để có thể xác định vấn đề.

Từ những gì tôi có thể nói cho đến nay, obnam dường như rẽ nhánh một quá trình gpg riêng lẻ cho mỗi tệp được sao lưu. Đánh giá từ htop, strace và iuler, tốc độ của một bản sao lưu ban đầu chủ yếu bị giới hạn bởi việc chuyển đổi liên tục, trong khi CPU và các ổ đĩa (không liên quan đến mạng) hầu như không sử dụng dưới 20%.

Số tiền dự phòng của tôi lên tới khoảng 500.000 tệp với tổng cộng 170 GiB dữ liệu. Vì vậy, với mỗi lần chạy sao lưu, gpg được chia đôi 500.000 lần. Tôi thực sự thậm chí không ngạc nhiên khi việc này mất gần cả ngày cho lần chạy đầu tiên và hơn ba giờ cho lần chạy khác với hầu hết các tệp không thay đổi. Nhưng đây có thực sự là hiệu suất obnam người dùng nên mong đợi? Để so sánh: một lần chạy rsnapshot tăng dần (cùng dữ liệu, cùng máy, cùng ổ đĩa) mất khoảng bốn phút. Cấp, không có mã hóa có liên quan, nhưng điều này không nên ý nghĩa.

Vì vậy, để hỏi một cách rõ ràng: Có phải máy của mọi người khác không thể chạy gpg (mã hóa một đoạn dữ liệu nhỏ) hơn 50 lần mỗi giây, cuối cùng biến obnam thành một công cụ chậm gần như không thể tin được? hay la chỉ Minh tôi?

(FWIW, máy của tôi là Core i5-2500 với 8G RAM và ổ SSD, chạy Gentoo. Sao lưu được thực hiện trên ổ cứng, nhưng tôi không thể quan sát thấy bất kỳ sự khác biệt nào khi sao lưu vào SSD, vì nó không phải là I / O -tiếp theo.)

Câu trả lời:


4

Đây là một bài đọc tốt về cách tăng tốc obnam (có thể chạy nhanh hơn tới 10 lần): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

Tóm tắt: thêm "--lru-size = 1024 --upload-queue-size = 512" vào tập tin dòng lệnh hoặc cấu hình của bạn. Lưu ý rằng nó làm tăng mức sử dụng bộ nhớ của obnam một chút.


Trên một hệ thống giàu bộ nhớ, chúng có thể được đặt cao hơn. Tôi đã đạt được tốc độ tăng hơn 10 lần với các cài đặt này!
tước

mặc định là --lru-size=256 --upload-queue-size=128gì sẽ là một giá trị tốt trên Ubuntu của tôi với RAM 8GB nên sao lưu vào một máy chủ trực tuyến khá chậm chỉ với 2GB RAM?
rubo77

Nếu mục tiêu sao lưu thực sự chậm, thì nút cổ chai của bạn có thể không phải là kích thước LRU hoặc kích thước hàng đợi tải lên. Hãy mở một câu hỏi mới.
1

3

Tôi nghĩ rằng tôi sẽ tấn công vấn đề này theo một số cách. Để bắt đầu, tôi sẽ thử và tự chẩn đoán nó bằng các phương pháp sau.

1. nhật ký obnam

Để bắt đầu, bạn có thể đăng nhập tin nhắn từ obnamnhư vậy:

$ obnam --log obnam.log

Bạn cũng có thể tăng mức ghi nhật ký thông qua công --log-leveltắc để biết thêm chi tiết.

--log=FILE          write log entries to FILE (default is to not write log
                    files at all); use "syslog" to log to system log, or
                    "none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
                    critical, fatal (default: info)

2. Hồ sơ

Bạn cũng có thể nhận được một hồ sơ về những gì obnamđang làm như sau từ đoạn trích này trong Câu hỏi thường gặp của dự án :

Nếu OBNAM_PROFILEbiến môi trường chứa tên tệp, dữ liệu lược tả sẽ được lưu trữ ở đó và có thể được xem sau với obnam-viewprof:

  $ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less

Các vấn đề về hiệu năng không liên quan đến một thiết lập cụ thể cũng có thể được quan sát bằng cách sử dụng obnam-benchmark tool.

3. Mở một vé

Nếu hiệu suất vẫn không được xác định khi thực hiện một số điều tra tự lái thì tôi sẽ mở một vé trên trang web của dự án . Từ những gì tôi đã có thể thu thập (các) nhà phát triển có phần phản ứng nhanh và họ có thể sẽ là người giỏi nhất trong việc khắc phục các vấn đề với dự án của họ.

obnamdường như chỉ sử dụng SFTP, do đó, điều khá rõ ràng là nguyên nhân gây ra sự cố. Tôi cũng sẽ xem xét cơ sở hiệu suất SFTP để bạn có thể thấy mức tối đa theo lý thuyết với kết nối mạng + hệ thống của bạn trước khi cố gắng tự lấy thông tin này ra khỏi các obnambài kiểm tra.

Điểm dữ liệu bổ sung

# 1 - bài đăng trên blog so sánh obnam so với rsnapshot

Tìm thấy bài đăng blog này, nơi tác giả đã so sánh một số tùy chọn trong thể loại này. Bài viết có tiêu đề: So sánh rsnapshot và obnam cho các bản sao lưu lớn theo lịch trình .

Bài báo nhấn mạnh một số hiệu suất rất kém, IMO, với obnamđiều đó dường như sẽ ghen tị với những gì bạn đang mô tả.

hiệu suất obnam

Sau khi sao lưu hoàn toàn / về nhà (mất vài ngày!), Một lần chạy mới, vài ngày sau đó (thời gian theo lệnh thời gian của Linux):

Đã sao lưu 3443706 tệp, đã tải lên 94,0 GiB trong 127h48m49s ở tốc độ trung bình 214,2 KiB / s; 1,24 GiB (0 B / s) người dùng thực 7668m56.628s 4767m16.132s sys 162m48.739s

Từ tệp nhật ký obname:

   2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0
   2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 
   2012-11-21 23:09:36 INFO Backup performance statistics: 
   2012-11-21 23:09:36 INFO * files found: 3443706 
   2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 
   2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s
   2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends
   2012-11-21 23:09:36 INFO obnam version 1.2 ends normally

Vì vậy: ~ 5 ngày để sao lưu ~ 100 GB dữ liệu đã thay đổi. Tải trọng không cao trên các máy, cả về CPU cũng như về RAM. Sử dụng đĩa trong / backups / backup_home là 5,7T, sử dụng đĩa của / home là 6,6T, vì vậy có một số khoản khấu trừ, dường như.

hiệu suất rsnapshot

Một bản sao lưu đầy đủ của / home to (theo tệp nhật ký):

   [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started   
   [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid 
   [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/    
   [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ 
   [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/
   [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/
   [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid
   [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully

Vì vậy: ~ 1,5 ngày để sao lưu toàn bộ 6,3TB. Một bản sao lưu gia tăng một ngày sau đó đã lấy:

     [29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started
     [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid
     [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/
     [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/
     [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid
     [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully

Vì vậy: 15 phút ... và dữ liệu thay đổi lên tới 21GB.

* gác mái so với obnam

Không kỹ lưỡng nhưng đề cập đến một trong những nhược điểm của obnamnó là nó rất chậm so với attic.

Tên họ

  • tài liệu tốt
  • danh sách gửi thư đang hoạt động
  • gói có sẵn

Nhược điểm

  • rất chậm
  • sao lưu lớn

Ưu điểm

  • sao lưu nhỏ hơn nhiều (thậm chí không trùng lặp)
  • chống trùng lặp tốt hơn nhiều
  • nhanh hơn nhiều

Nhược điểm

  • định dạng kho lưu trữ không được ghi lại
  • không phải là một cộng đồng người dùng lớn

Một số dữ liệu thử nghiệm được hiển thị mà dường như chỉ ra rằng obnamnó thực sự chậm.

Từ SSD cục bộ đến HD từ xa, qua kết nối wifi bình thường:

    rsync:           0:24  0:01
    Attic ssh:       0:28  0:05
    Attic sshfs:     0:51  0:08
    Obnam sftp:      8:45  0:21
    Obnam sshfs:    25:22  0:22

Người giới thiệu


3

Cấu hình mặc định của Obnam (kể từ 2015/02/08) không hoạt động tốt để sao lưu các thư mục có số lượng lớn tệp nhỏ. Tôi đã có chính xác cùng một vấn đề như đã đề cập ở trên.

Giải pháp cho tôi là thêm --lru-size = 8192 --upload-queue-size = 8192 vào dòng lệnh. Điều này đã giải quyết vấn đề và biến một người dùng thất vọng thành một người dùng Obnam rất hạnh phúc. (Tôi có các cài đặt này trong các tệp cấu hình tiêu chuẩn của mình ngay bây giờ.)

Thật không may, hướng dẫn của Obnam không đề cập đến việc trả trước tầm quan trọng của các cài đặt này. Câu hỏi thường gặp cung cấp thêm chi tiết. Đặt các tham số hiệu suất là thực sự bắt buộc trên các hệ thống có nhiều tệp nhỏ.


1
Bạn có thể nói sự khác biệt của các cài đặt mới đối với việc sử dụng tài nguyên không?
Faheem Mitha
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.