Szybsze rsync ogromnego katalogu, który nie został zmieniony

13

Używamy rsync do tworzenia kopii zapasowych serwerów.

Niestety sieć do niektórych serwerów jest powolna.

Rsync wykrywa, że ​​nic się nie zmieniło w ogromnych katalogach. Te ogromne drzewa katalogów zawierają wiele małych plików (około 80 000 plików).

Myślę, że klienci rsync wysyłają dane dla każdego z 80k plików.

Ponieważ sieć działa wolno, chciałbym uniknąć wysyłania informacji o każdym pliku 80 razy.

Czy istnieje sposób, aby powiedzieć rsync, aby utworzyła sumę sumaryczną drzewa podkatalogów?

W ten sposób klient rsync wyśle ​​tylko kilka bajtów dla dużego drzewa katalogów.

Aktualizacja

Do tej pory moją strategią jest używanie rsync. Ale jeśli inne narzędzia pasują tutaj lepiej, mogę się przełączyć. Zarówno (serwer, jak i klient) są pod moją kontrolą.

Aktualizacja 2

W jednym drzewie katalogów znajduje się 80 000 plików . Każdy pojedynczy katalog nie ma więcej niż 2k plików lub podkatalogów

Aktualizacja 3

Szczegóły dotyczące powolności sieci:

time ssh einswp 'cd attachments/200 && ls -lLR' >/tmp/list
real    0m2.645s

Rozmiar pliku tmp / list: 2 MB

time scp einswp:/tmp/list tmp/
real    0m2.821s

Wniosek: scp ma tę samą prędkość (bez zaskoczenia)

time scp einswp:tmp/100MB tmp/
real    1m24.049s

Prędkość: 1,2 MB / s

rsync synchronization guettli
źródło
1
Możesz przeczytać na zsync. Sam go nie użyłem, ale z tego, co przeczytałem, wstępnie renderuje metadane po stronie serwera i może po prostu przyspieszyć transfery w twoim przypadku. Zresztą może warto to przetestować. Poza tym jedyne inne rozwiązanie, jakie znam, to synchronizacja na poziomie bloków w czasie rzeczywistym, która jest dostarczana z niektórymi rozwiązaniami san / nas.
Aaron

Odpowiedzi:

36

Niektóre niepowiązane punkty:

80 KB to dużo plików.

80 000 plików w jednym katalogu? Domyślnie żaden system operacyjny ani aplikacja nie radzą sobie z tą sytuacją. Właśnie zauważyłeś ten problem z rsync.

Sprawdź swoją wersję rsync

Nowoczesne rsync obsługuje duże katalogi znacznie lepiej niż w przeszłości. Upewnij się, że używasz najnowszej wersji.

Nawet stary rsync dość dobrze radzi sobie z dużymi katalogami w przypadku linków o dużym opóźnieniu ... ale pliki o wielkości 80 000 nie są duże ... są ogromne!

To powiedziawszy, użycie pamięci rsync jest wprost proporcjonalne do liczby plików w drzewie. Duże katalogi wymagają dużej ilości pamięci RAM. Powolność może być spowodowana brakiem pamięci RAM po obu stronach. Wykonaj test, obserwując zużycie pamięci. Linux używa pozostałej pamięci RAM jako pamięci podręcznej dysku, więc jeśli brakuje pamięci RAM, buforowanie dysku jest mniejsze. Jeśli zabraknie pamięci RAM, a system zacznie używać wymiany, wydajność będzie naprawdę niska.

Upewnij się, że --checksum nie jest używany

--checksum(lub -c) wymaga odczytu każdego bloku każdego pliku. Prawdopodobnie możesz sobie poradzić z domyślnym zachowaniem polegającym na po prostu czytaniu czasów modyfikacji (zapisanych w i-węźle).

Podziel pracę na małe partie.

Istnieje kilka projektów, takich jak Gigasync, które „ podzielą obciążenie, używając perla do rekurencji drzewa katalogów, tworząc małe listy plików do przesłania za pomocą rsync”.

Dodatkowe skanowanie katalogu będzie dużym obciążeniem, ale być może będzie to wygrana netto.

Domyślne ustawienia systemu operacyjnego nie są tworzone dla tej sytuacji.

Jeśli używasz Linux / FreeBSD / etc ze wszystkimi ustawieniami domyślnymi, wydajność będzie straszna dla wszystkich twoich aplikacji. Domyślne wartości zakładają mniejsze katalogi, aby nie marnować pamięci RAM na zbyt duże pamięci podręczne.

Dostosuj swój system plików, aby lepiej obsługiwał duże katalogi: czy duże rozmiary folderów spowalniają wydajność IO?

Spójrz na „cache namei”

Systemy operacyjne podobne do BSD mają pamięć podręczną, która przyspiesza wyszukiwanie nazwy i-węzła (pamięć podręczna „namei”). Dla każdego katalogu istnieje pamięć podręczna namei. Jeśli jest ona zbyt mała, stanowi przeszkodę bardziej niż optymalizację. Ponieważ rsync wykonuje komendę lstat () dla każdego pliku, dostęp do i-węzła jest uzyskiwany dla każdego z plików 80k. To może zapełnić pamięć podręczną. Dowiedz się, jak dostroić wydajność katalogu plików w systemie.

Rozważ inny system plików

XFS został zaprojektowany do obsługi większych katalogów. Zobacz System plików duża liczba plików w jednym katalogu

Może najlepiej 5 minut.

Rozważ obliczenie liczby odczytywanych bloków dysku i oblicz, jak szybko można oczekiwać, że sprzęt będzie w stanie odczytać tyle bloków.

Może twoje oczekiwania są zbyt wysokie. Zastanów się, ile bloków dyskowych należy odczytać, aby wykonać rsync bez zmian plików: każdy serwer będzie musiał odczytać katalog i odczytać jeden i-węzeł na plik. Załóżmy, że nic nie jest buforowane, ponieważ cóż, 80k plików prawdopodobnie zepsuło pamięć podręczną. Powiedzmy, że matematyka ma 80 bloków. To około 40 milionów danych, które powinny być czytelne za kilka sekund. Jeśli jednak konieczne jest wyszukiwanie dysku między blokami, może to potrwać znacznie dłużej.

Musisz więc przeczytać około 80 000 bloków dysku. Jak szybko może to zrobić Twój dysk twardy? Biorąc pod uwagę, że jest to przypadkowe we / wy, a nie długi odczyt liniowy, 5 minut może być całkiem doskonałe. To 1 / (80000/600) lub dysk odczytywany co 7,5 ms. Czy to jest szybkie czy wolne dla twojego dysku twardego? To zależy od modelu.

Benchmark w stosunku do czegoś podobnego

Innym sposobem myślenia o tym jest to. Jeśli żadne pliki się nie zmieniły, ls -Llrwykonuje tyle samo aktywności na dysku, ale nigdy nie czyta żadnych danych pliku (tylko metadane). Czas ls -Llrpotrzebny na bieg to górna granica.

  • Czy rsync (bez zmian plików) jest znacznie wolniejszy niż ls -Llr? Następnie opcje, których używasz dla rsync, mogą zostać ulepszone. Może -cjest włączona lub jakaś inna flaga, która czyta więcej niż tylko katalogi i metadane (dane i-węzłów).

  • Czy rsync (bez zmian plików) jest prawie tak szybki jak ls -Llr? Następnie dostroiłeś rsync najlepiej, jak potrafisz. Musisz dostroić system operacyjny, dodać pamięć RAM, uzyskać szybsze dyski, zmienić systemy plików itp.

Porozmawiaj ze swoimi twórcami

Pliki 80k to po prostu zły projekt. Bardzo niewiele systemów plików i narzędzi systemowych bardzo dobrze radzi sobie z tak dużymi katalogami. Jeśli nazwy plików to abcdefg.txt, rozważ przechowywanie ich w abdc / abcdefg.txt (zwróć uwagę na powtórzenie). Dzieli to katalogi na mniejsze, ale nie wymaga dużych zmian w kodzie.

Również .... rozważ skorzystanie z bazy danych. Jeśli masz 80 000 plików w katalogu, być może twoi programiści pracują nad tym, że tak naprawdę chcą bazy danych. MariaDB lub MySQL lub PostgreSQL byłyby znacznie lepszą opcją do przechowywania dużych ilości danych.

Hej, co jest nie tak z 5 minutami?

Wreszcie, czy 5 minut jest naprawdę tak źle? Jeśli uruchomisz tę kopię zapasową raz dziennie, 5 minut nie będzie dużo czasu. Tak, uwielbiam szybkość. Jeśli jednak 5 minut jest „wystarczających” dla klientów, to jest wystarczająco dobre dla Ciebie. Jeśli nie masz pisemnej umowy SLA, co powiesz na nieformalną dyskusję z użytkownikami, aby dowiedzieć się, jak szybko oczekują kopii zapasowych.

Zakładam, że nie zadałeś tego pytania, jeśli nie było potrzeby poprawy wydajności. Jeśli jednak Twoi klienci są zadowoleni z 5 minut, zadeklaruj zwycięstwo i przejdź do innych projektów, które wymagają twoich wysiłków.

Aktualizacja: po krótkiej dyskusji ustaliliśmy, że wąskim gardłem jest sieć. Zanim się poddam, polecę 2 rzeczy :-).

  • Staraj się wyciskać większą przepustowość z rury za pomocą kompresji. Jednak kompresja wymaga więcej procesora, więc jeśli procesor jest przeciążony, może to pogorszyć wydajność. Wypróbuj rsync z lub bez -zi skonfiguruj ssh z kompresją i bez. Czas we wszystkich 4 kombinacjach, aby sprawdzić, czy któraś z nich działa znacznie lepiej niż inne.
  • Obserwuj ruch sieciowy, aby zobaczyć, czy są jakieś przerwy. Jeśli występują przerwy, możesz znaleźć przyczynę ich wystąpienia i tam zoptymalizować. Jeśli rsync zawsze wysyła, to naprawdę masz limit. Do wyboru są:
    • szybsza sieć
    • coś innego niż rsync
    • przenieś źródło i cel bliżej siebie. Jeśli nie możesz tego zrobić, czy możesz zsynchronizować rsync z maszyną lokalną, a następnie zsynchronizować rsync z rzeczywistym miejscem docelowym? Może to przynieść korzyści, jeśli system musi być wyłączony podczas początkowego rsync.
TomOnTime
źródło
80K to dużo plików .: w jednym drzewie katalogów jest 80 tysięcy plików . Każdy pojedynczy katalog nie ma więcej niż 2k plików / podkatalogów.
guettli
Sprawdź wersję rsync: gotowe, upewnij się, że --checksum nie jest używane: gotowe. Podziel pracę na małe partie: dziękuję Zajrzę do gigasync. Domyślne ustawienia systemu operacyjnego nie są tworzone dla tej sytuacji: gotowe (wąskim gardłem jest sieć, a nie system operacyjny). Spójrz na „namei cache”: gotowe (to jest sieć, nie system operacyjny). Rozważ inny system plików: ponownie net, a nie system operacyjny. Być może najlepiej jest zrobić 5 minut. Myślę, że może być znacznie szybciej. Porozmawiaj ze swoimi twórcami (użyj DB): To byłaby ogromna zmiana. Być może system plików z lepszą obsługą tworzenia kopii zapasowych rozwiązałby to.
guettli
2k plików na katalog jest o wiele lepszy. Dziękuję za aktualizację. Nie wspominałeś, że sieć działa wolno. Czy jest to niska przepustowość, duże opóźnienia, czy jedno i drugie? rsync zwykle działa dobrze na łączach o dużych opóźnieniach (został opracowany przez kogoś pracującego nad jego doktoratem z Australii podczas pracy z komputerami w USA). Spróbuj zrobić to „ls -lLR” przez ssh i czas, ile czasu zajmuje przesłanie wyniku. msgstr "czas ssh remotehost 'cd / dest && ls -lLR'> / tmp / list”. Upewnij się, że lista / tmp / została utworzona na lokalnym hoście.
TomOnTime,
tak, sieć działa wolno. Szkoda.
guettli
Jak wolno Jeśli użyjesz „scp” do skopiowania pliku 100M, ile to zajmie? A także, co jest wynikiem „time ssh remotehost 'cd / dest && ls -lLR'> / tmp / list”?
TomOnTime,
2

Nie, nie jest to możliwe w przypadku rsync i byłoby to nieefektywne pod innym względem:

Zwykle rsyncporównuje tylko daty modyfikacji i rozmiary plików. Twoje podejście zmusiłoby go do dwukrotnego odczytu i sumowania zawartości wszystkich plików (w systemie lokalnym i zdalnym) w celu znalezienia zmienionych katalogów.

Sven
źródło
1
AFAIK rsync sprawdza czas i rozmiar. Jeśli oba są zgodne, plik nie jest ponownie przesyłany (przynajmniej w ustawieniach domyślnych). Wystarczy wysłać skrót krotek (nazwa pliku, rozmiar, mtime). Nie ma potrzeby sumowania zawartości.
guettli
Tak, masz rację, ale i tak rsynctego nie robi.
Sven
2

Do synchronizacji dużej liczby plików (gdzie niewiele się zmieniło) warto również ustawić noatimepartycje źródłowe i docelowe. Oszczędza to czas dostępu do zapisu na dysku dla każdego niezmienionego pliku.

Andy Beverley
źródło
Tak, opcja noatime ma sens. Używamy go od kilku lat. Chyba potrzebna jest alternatywa dla rsync.
guettli
2

Możesz także wypróbować lsyncd, który uruchomi rsync tylko wtedy, gdy zostaną wykryte zmiany w systemie plików i tylko zmienione podkatalogi. Używam go do katalogów zawierających do dwóch milionów plików na porządnym serwerze.

Juanga Covas
źródło