Jak liczba podkatalogów wpływa na wydajność odczytu / zapisu dysku w systemie Linux?

Mam sformatowany dysk EXT3 na serwerze Linux CentOS. Jest to dysk danych aplikacji sieci Web i zawiera katalog dla każdego konta użytkownika (istnieje 25 000 użytkowników). Każdy folder zawiera pliki przesłane przez tego użytkownika. Ogólnie rzecz biorąc, na tym dysku znajduje się około 250 GB danych.

Czy struktura dysku z tymi wszystkimi katalogami wpływa na wydajność odczytu / zapisu? Czy wpływa to na inny aspekt wydajności, o którym nie wiem?

Czy jest coś z natury złego lub złego w takiej strukturze rzeczy? Być może po prostu zły wybór systemu plików?

Niedawno próbowałem połączyć dwa dyski danych i zdałem sobie sprawę, że EXT3 jest ograniczony do 32 000 podkatalogów. Zastanawiałem się dlaczego. To głupie, że zbudowałem go w ten sposób, biorąc pod uwagę, że każdy plik ma unikalny identyfikator, który odpowiada identyfikatorowi w bazie danych. Niestety ...

Łatwo jest przetestować opcje dla siebie, w swoim środowisku i porównać wyniki. Tak, negatywny wpływ na wydajność ma wzrost liczby katalogów. Tak, inne systemy plików mogą pomóc ominąć te bariery lub zmniejszyć wpływ.

System plików XFS jest lepszy dla tego typu struktury katalogów. ext4 jest obecnie prawdopodobnie w porządku. Dostęp i operacje na katalogu spowolnią się wraz ze wzrostem liczby podkatalogów i plików. Jest to bardzo wyraźne w ext3 i nie tak bardzo na XFS.

Odpowiedź nie jest tak prosta jak wybór systemu plików. Rozsądne systemy plików już dawno przestały używać list liniowych dla katalogów, co oznacza, że ​​liczba pozycji w katalogu nie wpływa na czas dostępu do plików ...

z wyjątkiem kiedy to robi.

W rzeczywistości każda operacja pozostaje szybka i wydajna bez względu na liczbę wpisów, ale niektóre zadania wymagają rosnącej liczby operacji. Oczywiście wykonanie prostej lszajmuje dużo czasu i nic nie widać, dopóki wszystkie i-węzły nie zostaną odczytane i posortowane. Robienie ls -U(nieposortowane) trochę pomaga, ponieważ widać, że nie jest martwe, ale nie redukuje percepcyjnie czasu. Mniej oczywiste jest to, że każde rozszerzenie z użyciem symboli wieloznacznych musi sprawdzać każdą nazwę pliku i wydaje się, że w większości przypadków należy przeczytać cały i-węzeł.

Krótko mówiąc: jeśli możesz mieć pewność, że żadna aplikacja (w tym dostęp do powłoki) nigdy nie użyje żadnego znaku wieloznacznego, możesz uzyskać ogromne katalogi bez wyrzutów sumienia. Ale jeśli w kodzie czają się symbole wieloznaczne, lepiej trzymaj katalogi poniżej tysiąca wpisów.

edycja :

Wszystkie nowoczesne systemy plików używają dobrych struktur danych dla dużych katalogów, więc pojedyncza operacja, która musi znaleźć i-węzeł konkretnego pliku, będzie dość szybka nawet w przypadku katalogów o dużej pojemności .

Ale większość aplikacji nie wykonuje tylko pojedynczych operacji. Większość z nich wykona pełny katalog lub dopasowanie do znaku wieloznacznego. Są one powolne bez względu na wszystko, ponieważ obejmują czytanie wszystkich wpisów.

Na przykład: załóżmy, że masz katalog z milionem plików od „foo-000000.txt” do „foo-999999.txt” i pojedynczym „natalieportman.jpeg”. Będą szybkie:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

te zawiodą, ale również zawiodą szybko:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

będą one powolne, nawet jeśli zwrócą bardzo niewiele wyników; nawet te, które zawodzą, zawodzą po zeskanowaniu wszystkich wpisów:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

Najpierw upewnij się, że partycja ext3 ma dir_indexustawioną flagę.

sudo dumpe2fs /dev/sdaX |grep --color dir_index

Jeśli go brakuje, możesz go włączyć. Musisz odmontować system plików, a następnie uruchomić:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

Następnie zamontuj system plików.

Nie robi to różnicy, dopóki nie osiągniesz 32 000 nazw ext3 na limit katalogu. Aktualizacja do ext4 może obejść ten problem, podobnie jak inne korzyści, jakie ma ext4.

Im więcej wpisów (plików i katalogów) masz w jednym katalogu, tym wolniejszy będzie dostęp. Dotyczy to każdego systemu plików, choć niektóre są gorsze od innych.

Lepszym rozwiązaniem jest utworzenie hierarchii katalogów, takiej jak ta:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

A jeśli nadal potrzebujesz lepszej wydajności, możesz rozszerzyć wiele poziomów:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

Większość systemów pocztowych używa tej sztuczki w swoich plikach kolejek pocztowych.

Odkryłem również, że w przypadku niektórych systemów plików, posiadanie w przeszłości wielu pozycji w katalogu spowoduje, że dostęp do katalogu będzie wolny. Wykonaj ls -ldw katalogu, aby zobaczyć rozmiar samego wpisu w katalogu. Jeśli ma kilka MB lub więcej, a katalog jest względnie pusty, być może wydajność jest niska. Zmień nazwę katalogu na bok, utwórz nowy z tą samą nazwą i uprawnieniami oraz własnością, a następnie przenieś zawartość starego katalogu do nowego. Użyłem tej sztuczki wiele razy, aby znacznie przyspieszyć serwery pocztowe, które zostały spowolnione przez system plików.

Niedawno opracowałem serwer pamięci, który musiał utworzyć dziesiątki milionów plików i setki tysięcy katalogów. Porównałem XFS z ext4 i reiserfs. Odkryłem, że w moim przypadku ext4 był nieco szybszy niż XFS. Reiser był interesujący, ale miał ograniczenia, więc został odrzucony. Odkryłem również, że ext4 był znacznie szybszy niż ext3.

Kiedy dostajesz dużo plików w katalogu, czas otwarcia plików zaczyna cierpieć. Plik We / Wy nie. Czas usuwania pliku również cierpi. Jednak nie jest zbyt wolny na ext4. Jest to dość zauważalne pod ext3. XFS i ext4 są na tym dość szybkie.

Kiedy ostatnio patrzyłem na XFS i zastanawiałem się nad zaletami i wadami używania XFS nad ext4, znalazłem raporty o utracie danych w XFS. Nie jestem pewien, czy to nadal jest problem, czy kiedykolwiek tak było, ale denerwowało mnie to na tyle, by omijać. Ponieważ ext4 jest domyślnym fs w Ubuntu, łatwo wygrał z XFS.

Oprócz sugestii Tylerla, która pomoże z punktu widzenia zarządzania, proponuję uaktualnienie do ext4. Limit na katalog to 64000 wpisów z ext4

Kolejną korzyścią jest to, że czas fsck jest znacznie krótszy. Nigdy nie miałem żadnych problemów z korupcją.

Zaletą ext4 jest to, że możesz zamontować wolumin ext3 na ext4, aby wypróbować. Zobacz: Migracja systemu na żywo z systemu plików ext3 do ext4

Cytat z tego linku:

Jeśli ograniczenia ext3 nie dotyczą Ciebie i nie chcesz podejmować ryzyka, być może nie warto. Z drugiej strony, po pomyślnym zakończeniu procedury migracji system może wykonywać szybciej, doświadczać skróconych kontroli systemu plików i mieć większą niezawodność bez żadnych negatywnych skutków.

Więc śmiało i spróbuj. Najpierw zasugeruj kopię zapasową.

Na pewno będą pewne konsekwencje takiego postępowania. Podstawowym będzie odczyt / zapis IO. Poza tym jest to po prostu bardzo przerażający sposób radzenia sobie z tego rodzaju danymi (na taką skalę).

W przeszłości korzystałem z XFS, aby z powodzeniem ominąć granice Ext3.

Pierwsza lista zawartości systemów plików potrwa chwilę, dopóki system nie przeczyta wszystkich informacji o katalogu / pliku. Dodatkowe operacje będą szybsze, ponieważ jądro ma teraz buforowane informacje.

Widziałem, jak administratorzy regularnie uruchamiają „znajdź / somepath 2> i 1> / dev / null” w cronie, aby utrzymać aktywną pamięć podręczną, co skutkuje lepszą wydajnością.

Mam kilka pytań i możliwe ustalenia wąskiego gardła.

Po pierwsze, czy jest to system CentOS 5 lub 6? Ponieważ w wersji 6 mamy niesamowite narzędzie o nazwie blktrace, które idealnie nadaje się do pomiaru wpływu w tego rodzaju sytuacjach.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

Następnie możemy przeanalizować dane wyjściowe za pomocą btt i dowiedzieć się, gdzie jest wąskie gardło, aplikacja, system plików, harmonogram, pamięć - przy jakim komponencie IO spędza większość czasu.

Teraz, teoretycznie dochodząc do pytania, oczywiście zwiększy liczbę i-węzłów, a gdy będziesz tworzyć lub uzyskiwać dostęp do nowych lub istniejących plików lub katalogów w katalogach, czas dostępu wydłuży się. Jądro musi przejść przez szerszą hierarchię systemu plików, a zatem bez wątpienia jest to narzut.

Inną kwestią, na którą należy zwrócić uwagę, jest to, że wraz ze wzrostem liczby katalogów zużycie pamięci podręcznej i-węzłów dentystycznych wzrośnie, co oznacza zużycie większej ilości pamięci RAM. Jest to objęte pamięcią płyty, więc jeśli twój serwer ma mało pamięci, to kolejny punkt do rozważenia.

Mówiąc o przykładzie z prawdziwego świata, ostatnio zauważyłem, że na bardzo zagnieżdżonym ext3 fs, utworzenie podkatalogu po raz pierwszy zajmuje około 20 sekund, podczas gdy na ext4 zajmuje około 4 sekund. Jest tak, ponieważ struktura przydziału bloków jest zorganizowana w różnych systemach plików. Jeśli używasz XFS lub ext4, nie trzeba mówić, że dostaniesz pewien wzrost wydajności, choć może być minimalny.

Tak więc, jeśli pytasz tylko o właściwy wybór systemu plików, ext3 jest nieco przestarzały. To wszystko, co mogę zaoferować bez dalszych danych i testów.

Nie jest to opcja w CentOS 5 i nie jestem pewien, ile to jest opcja w CentOS 6, ale mam przeczucie, że rozwiązanie oparte na drzewie B lub B *, tj. BTRFS, zapewni spójną, jeśli nie znacznie lepszą wydajność w twoim przypadku scenariusz, gdyby tylko można było powierzyć to swoje cenne dane z czystym sumieniem (nadal bym tego nie zrobił).

Ale jeśli możesz sobie na to pozwolić, możesz to przetestować.