sobota, 9 stycznia 2010

Solaris jako domowy serwer

Robiąc kopie laptopa za pomocą 'rsync' na domowy komputer, zaciekawił mnie w pewnym momencie postęp kopiowania plików jaki pokazuje rsync, a w zasadzie, to jego brak..

Komputer pełniący rolę serwera pracuje pod kontrolą systemu OpenSolaris.
Logując się na serwer zauważyłem, że bardzo mało danych jest wysyłanych przez sieć, natomiast dysk jest używany w 100%:

Widać, że dysk 'cmdk1' ma sporo operacji odczytu.
Za pomocą skryptu DTrace 'rwbytype', znajdującego się w pakiecie DTrace Toolkit (DTT) sprawdziłem jakie procesy używają I/O:Widać, że najwięcej danych odczytuje rsync z PIDem 5981.

Kolejny skrypt z DTT 'pfilestat' pokaże statystyki otwartych plików danego procesu:
# /opt/DTT/Proc/pfilestat 5981

Widać, że proces odczytuje sporo z deskryptora pliku nr 0.
Aby dowiedzieć się więcej o tym pliku wystarczy użyć komendy 'pfiles' z numerem PID:
# pfiles 5981


Teraz już wiadomo dlaczego rsync 'zatrzymał' się na chwilę z kopiowaniem danych.
W tym przypadku porównuje sumy kontrolne źródłowego i docelowego pliku, ponieważ plik został zmodyfikowany od ostatniego kopiowania.
Porównywany plik jest obrazem dysku wirtualnej maszyny VirtualBox'a i zajmuje 13GB, dlatego też ta operacja zatrzymała 'progress' jaki pokazuje rsync.

Aby przyśpieszyć kopiowanie plików usunąłem ten plik z docelowego miejsca, jednocześnie mając jego kopię w snapshotach ZFS.

1 komentarz:

Przemoc pisze...

Duże pliki (dajmy na to: liczone w dziesiątkach gigabajtów) zawsze były problematyczne w różnego rodzaju zastosowaniach.

Od dłuższego czasu nie miałem styczności ze słonecznym systemem, ale zakładam, że rsync masz w nim w wersji 3.x, która usuwa problem ograniczonej przestrzeni hashy prowadzącej do częstych kolizji właśnie przy dużych plikach. Tu akurat i tak raczej nie jest to problemem, ale warto wiedzieć, że v3 jest po prostu lepsza.

Sposobów przyspieszenia rsyncowania dużych plików jest kilka, ale zależą od tego czym dysponujesz.

Po LAN-ie mając gigabitowe łącze szybsze może się okazać kopiowanie całych takich sporych plików (ale też i nie dowolonie sporych). Wówczas trzeba rozbić rsync na dwa wywołania: normalne dla małych plików (definiowanych przez --max-size) i bez algorytmu delta (--whole-file) dla dużych plików (definiowanych przez --min-size). Wiedząc, że dużych plików nie tykałeś, możesz w ogóle pominąć drugą część.

Kolejna przydatna opcja to --inplace. Unikamy tworzenia kopii pliku i podmiany docelowego poprzez bezpośrednie operowanie na celu. Gorzej jak nam sieć/prąd padnie w trakcie. Świat należy do odważnych! ;)

Pewnie są jeszcze jakieś inne, których nie znam.

Tak sobie myślę, że dla ZFS mógłby powstać dedykowany rsync, który wykorzystywałby wbudowany mechanizm sum kontrolnych obecny prawie na każdym kroku. Dostępność ich na poziomie bloków (używana zresztą przez mechanizm deduplikacji) idealnie pasowałaby do obrazów dysków itp. danych. Może coś takiego już jest? Kto wie...