Maksymalna liczba plików w jednym katalogu ext3 przy jednoczesnym uzyskiwaniu akceptowalnej wydajności?


25

Mam aplikację piszącą do katalogu ext3, który z czasem urósł do około trzech milionów plików. Nie trzeba dodawać, że czytanie listy plików tego katalogu jest nieznośnie wolne.

Nie obwiniam ext3. Właściwym rozwiązaniem byłoby pozwolenie kodowi aplikacji zapisywać w podkatalogach, na przykład ./a/b/c/abc.extzamiast używać tylko ./abc.ext.

Zmieniam się na taką strukturę podkatalogów, a moje pytanie brzmi: z grubsza, ile plików powinienem przechowywać w jednym katalogu ext3, a jednocześnie uzyskać akceptowalną wydajność? Jakie masz wrażenia

Lub innymi słowy; zakładając, że muszę przechowywać trzy miliony plików w strukturze, ile głębokości powinna ./a/b/c/abc.extmieć struktura?

Oczywiście jest to pytanie, na które nie można dokładnie odpowiedzieć, ale szukam oszacowania parku.

Odpowiedzi:


12

Pod warunkiem, że masz dystrybucję, która obsługuje tę funkcję dir_index, możesz łatwo mieć 200 000 plików w jednym katalogu. Zatrzymałbym go jednak na około 25 000, dla bezpieczeństwa. Bez tego dir_indexpostaraj się utrzymać go na 5000.


10

Bądź bardzo ostrożny, jak wybrać podział katalogów. „a / b / c” brzmi dla mnie jak przepis na katastrofę ...

Nie wystarczy ślepo tworzyć kilka głębokich struktur katalogów, powiedzmy 100 wpisów na pierwszym poziomie, 100 wpisów na drugim poziomie, 100 wpisów na trzecim. Byłem tam, zrobiłem to, wziąłem kurtkę i musiałem ją zrestrukturyzować, gdy wydajność spadła do crappera z kilkoma milionami plików. :-)

Mamy klienta, który wykonał układ „wielu katalogów” i ostatecznie umieścił od jednego do pięciu plików na katalog, i to je zabijało. 3 do 6 godzin na wykonanie „du” w tej strukturze katalogów. Wybawicielem tutaj był dysk SSD, nie chcieli przepisać tej części swojej aplikacji, a dysk SSD skrócił ten czas z godzin na minuty.

Problem polega na tym, że każdy poziom wyszukiwania katalogów wymaga wyszukiwania, a wyszukiwanie jest niezwykle kosztowne. Wielkość katalogu jest również ważnym czynnikiem, więc posiadanie go mniejszego niż większego to duża wygrana.

Aby odpowiedzieć na pytanie o liczbę plików w katalogu, 1000, o których mówiłem, że jest „optymalnych”, ale wydajność na 10 000 wydaje się być w porządku.

Tak więc polecam jeden poziom katalogów, przy czym każdy poziom jest katalogiem o długości 2 znaków, złożonym z wielkich i małych liter oraz cyfr, dla około 3800 katalogów na najwyższym poziomie. Następnie możesz przechowywać 14 mln plików w podkatalogach zawierających 3800 plików lub około 1000 plików w podkatalogu dla plików 3 mln.

Dokonałem takiej zmiany dla innego klienta i to zrobiło ogromną różnicę.


6

Sugeruję przetestowanie różnych rozmiarów katalogów za pomocą narzędzia do testów porównawczych, takiego jak stempel pocztowy , ponieważ istnieje wiele zmiennych, takich jak rozmiar pamięci podręcznej (zarówno w systemie operacyjnym, jak i podsystemie dyskowym), które zależą od konkretnego środowiska.

Moją osobistą zasadą jest dążenie do rozmiaru katalogu <= 20 000 plików, chociaż widziałem stosunkowo przyzwoitą wydajność z maksymalnie 100 000 plików / katalogu.


3

Mam wszystkie pliki do folderów takich jak:

uploads / [date] / [hour] /yo.png

i nie masz żadnych problemów z wydajnością.


4
A ile plików dostajesz na godzinę?
Cascabel,


2

Potrafię potwierdzić na dość potężnym serwerze z dużą ilością pamięci pod przyzwoitym obciążeniem, że 70 000 plików może spowodować spustoszenie wszelkiego rodzaju. Poszedłem usunąć folder pamięci podręcznej z 70k plików, co spowodowało, że apache zaczął odradzać nowe instancje, dopóki nie osiągnął maksymalnej liczby 255 i system zużył całą wolną pamięć (16 GB, chociaż instancja wirtualna mogła być niższa). Tak czy inaczej, utrzymanie go poniżej 25 000 jest prawdopodobnie bardzo ostrożnym posunięciem


1

Z mojego doświadczenia wynika, że ​​najlepszym podejściem jest nie przeprojektowywanie struktury plików z góry. Jak wspomniano w co najmniej jednej innej odpowiedzi, istnieją rozszerzenia systemu plików, które zajmują się kwestiami związanymi z wydajnością.

Problem, który częściej dotykam, to użyteczność po stronie administracyjnej. Najmniejszą pracą, jaką możesz zrobić, aby zmniejszyć liczbę plików w katalogu, jest prawdopodobnie podejście, którego potrzebujesz teraz.

sqrt (3_000_000) == 1732

Kilka tysięcy plików w jednym katalogu brzmi dla mnie rozsądnie. Bądź swoim własnym sędzią dla swojej sytuacji. Aby to osiągnąć, spróbuj podzielić pliki na jeden poziom katalogów skrótów, aby średnia liczba plików w katalogu była mniej więcej taka sama jak liczba katalogów.

Biorąc pod uwagę Twój przykład byłoby ./a/abc.ext, ./ab/abc.ext, ./abc/abc.ext, ....

Rozpowszechnianie plików będzie w dużym stopniu zależeć od rzeczywistych nazw plików. Wyobraź sobie zastosowanie tej techniki do katalogu milionów plików o nazwach foobar???.txt. Istnieją sposoby na osiągnięcie bardziej równomiernego rozprzestrzeniania się, na przykład haszowanie oparte na wartości określonej liczby bitów z sumy MD5 każdej nazwy pliku, ale śmiem zgadywać, że byłoby to przesadą w stosunku do tego, co próbujesz osiągnąć.


1

Hmm, ostatnio czytałem ten artykuł . Zasadniczo korzystasz z dystrybucji swojego ulubionego algorytmu mieszającego. Zacząłem grać z liczbami, INT z MySQL ma maksymalną wartość 2147483647. Możesz także zmieniać żądaną liczbę plików na katalog i liczbę podkatalogów, aby ustalić ostateczną liczbę podkatalogów / plików- podział na katalog dla danego zestawu danych, ale trudno jest znaleźć dowody empiryczne na temat optymalnych organizacji katalogów / plików. W tym artykule przedstawiono wgląd w różnice w wydajności między systemami plików (kilka interesujących wskaźników), ale nic o optymalnych organizacjach.


0

Myślę, że zbyt dużo się nad tym zastanawiasz. Jeśli nawet wybrałeś jeden dodatkowy poziom katalogów i potrafiłeś zrównoważyć wszystko, miałbyś 1732 * katalogów i 1732 plików na katalog.

O ile nie planujesz potrzebować dziesiątek miliardów plików, możesz właściwie wybrać liczbę od 1000 do 100 000 i uzyskać dobre wyniki.

* pierwiastek kwadratowy z 3 milionów.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.