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.