system plików dla milionów małych plików

44

Który system plików Linux wybrałbyś dla uzyskania najlepszej prędkości w następującym scenariuszu:

  • sto milionów plików
  • Średnio rozmiar pliku ~ 2k
  • > 95% dostęp do odczytu
  • dość losowy dostęp
  • wysoka współbieżność (> 100 procesów)

Uwaga: Pliki są przechowywane w głębokim drzewie hierarchicznym, aby uniknąć dużych katalogów. Każdy katalog liści zawiera około tysiąca plików.

Jak byś to zrobił?

bene
źródło
3
Potrzebne są dodatkowe informacje. Na przykład, czy przechowujesz wszystkie pliki w płaskim katalogu, czy w zagnieżdżonych (posortowanych) katalogach? Może to mieć ogromny wpływ na wydajność na czas dostępu do plików. Przesiewanie przez 100 000 000 wpisów w układzie „płaskim” pociągnie za sobą znaczne koszty ogólne, niezależnie od typu FS; w najlepszym przypadku szukasz jakiegoś rodzaju drzewa, które wciąż wymaga wielu odnośników, aby dotrzeć do pliku. Jeśli katagorujesz pliki do podkatalogów, czas dostępu znacznie przyspieszy, ponieważ na każdym poziomie jest mniej pozycji do wyszukiwania.
Avery Payne,
Czy plik jest dostępny szeregowo czy jednocześnie?
Steve Schnepp,

Odpowiedzi:

19

Oto kilka wyników porównujących wszystkie główne FS-y Linuksa z bonnie ++, których możesz użyć jako punktu wyjścia.

Pod względem losowych wyszukiwań wygrywa Reiser, następnie EXT4, a następnie JFS. Nie jestem pewien, czy będzie to dokładnie korelować z wyszukiwaniem katalogów, ale wydaje się, że byłby to wskaźnik. W tym celu musisz wykonać własne testy. EXT2 bije spodnie od czasu tworzenia plików, prawdopodobnie z powodu braku dziennika, wciąż EXT4 bije wszystko oprócz Reisera, z którego możesz nie chcieć korzystać z powodu obecnego statusu hans reiser.

Możesz zajrzeć do dysków obsługujących NCQ i upewnić się, że instalacja jest skonfigurowana do korzystania z niego. Podczas intensywnego poszukiwania powinien zapewnić przyspieszenie.

Na koniec upewnij się, że na twojej maszynie jest dużo taranów. Ponieważ pliki nie są często aktualizowane, Linux skończy buforowanie większości z nich, aby uzyskać ram, jeśli ma wolne miejsce. Jeśli twoje wzorce użytkowania są prawidłowe, da ci to ogromny wzrost prędkości.

Andrew Cholakian
źródło
1
Problem z bonnie ++ polega na tym, że nawet nie testuje z grubsza mojego scenariusza użytkowania
poniżej
2
Chodzi o to, że nie testuje przeszukiwania katalogów, ale szczerze mówiąc, jeśli to jest twój problem, lepiej zrzucić dane do prawdziwej bazy danych. Systemy plików nie działają tak dobrze na małych obiektach, z których większość baz danych jest zaprojektowana
Andrew Cholakian
7
@AndrewCholakian Link jest teraz martwy.
Don Scott
8

Zgadzam się z większością tego, co powiedział Andrew, z tym wyjątkiem, że poleciłbym Reiser4 lub starszą (ale lepiej obsługiwaną) ReiserFS . Jak wskazują te testy (i dokumentacja dla ReiserFS), jest on zaprojektowany specjalnie do sytuacji, o którą pytasz (duża liczba małych plików lub katalogów). W przeszłości korzystałem z ReiserFS z Gentoo i Ubuntu bez żadnych problemów.

Jeśli chodzi o status Hansa Reisera, nie uważam tego za problem z kodem lub stabilnością samego systemu plików. Reiser4 jest nawet sponsorowany zarówno przez DARPA, jak i Linspire, więc chociaż zgadzam się, że dalszy rozwój systemu plików Reiser nie jest określony, nie uważam, że powinien to być decydujący czynnik, czy ktoś powinien go używać, czy nie.

Mikrofon
źródło
3
Używam ReiserFS od dłuższego czasu. Właściwie nadal używam go na starszym serwerze Gentoo, do którego jeszcze się nie przyłączyłem. Ta instalacja ma 4 lata w maju. Co mi może powiedzieć, jest to, że znacznie spowolnione. Zjawisko to miało miejsce z biegiem czasu we wszystkich systemach plików korzystających z ReiserFS, które są w aktywnym użyciu do odczytu i zapisu na wszystkich komputerach, które miały takie systemy plików, bez wyjątków - więc jeśli chcesz go używać przez dłuższy czas, warto go zatrzymać na uwadze. Odszedłem od tego, używając XFS dla dużych systemów plików.
Mihai Limbăşan,
3

Wiem, że nie jest to bezpośrednia odpowiedź na twoje pytanie, ale w tych przypadkach myślę, że baza danych może być bardziej odpowiednia do hostowania tego. Małe pliki mogą być przechowywane w formacie binarnym w tabeli bazy danych i wyszukiwane w wil. Oprogramowanie korzystające z tych plików powinno być w stanie to obsłużyć ...

Jeroen Landheer
źródło
1
Co to jest system plików, jeśli nie tylko hierarchiczna baza danych? Twoja propozycja dodaje warstwy abstrakcji, złożoności i oprogramowania, które prawdopodobnie nie są uzasadnione. Co więcej, właściciel pytania wykonuje swoje zadanie dzięki „UNIX Philosophy”, co, jak podejrzewam, nie lubisz być facetem z Windows?
Stu Thompson
3
Przede wszystkim nie mam nic przeciwko Unixowi ani nic innego w tej dziedzinie. Istnieją duże różnice między systemami plików i bazami danych, dlatego opracowano obie technologie. Bazy danych są zaprojektowane do pracy z ogromną liczbą małych jednostek, w których wykonują lepszą pracę niż większość systemów plików. Po prostu wskazałem, że może istnieć inna droga, którą można z tym podążać.
Jeroen Landheer
1
Znacznie łatwiej jest „wyczyścić / odkurzyć” plik db niż defragmentować system plików w systemie Linux. Większość / wszystkie fs nie zapewniają tej funkcjonalności, mówiąc, że nie jest to konieczne. Biorąc pod uwagę powyższy komentarz Mihai, widać, że nie jest to do końca prawda.
Gringo Suave,
3

Ktoś z Unix StackExchange stworzył test porównawczy (ze źródłem), aby przetestować ten scenariusz:

P: Jaki jest najbardziej wydajny system plików Linux do przechowywania wielu małych plików (HDD, a nie SSD)?

Najlepsza wydajność odczytu wydaje się pochodzić z ReiserFS.

thenickdude
źródło
Btrfs wydaje się mieć lepsze lub porównywalne wyniki we wszystkim oprócz usuwania. Ale jak często usuwasz 300 tys. Plików? W przeszłości lubiłem rfs, ale btrfs może być lepszym wyborem na przyszłość.
Gringo Suave,
3

Z mojego doświadczenia wynika, że ​​ext2 wydmuchuje ext4 z wody dla małych plików. Jeśli nie zależy Ci na integralności zapisu, to świetnie. Na przykład subversion tworzy mnóstwo plików i wiele małych plików, które dławią ext4 i inne systemy plików (XFS) (uruchamiaj zadanie cron, które rsynchronizuje dane do ext4 z ext2 co pół godziny lub mniej więcej rozwiązuje problem).

Uruchamianie tych poleceń sprawia, że ​​ext2 jest jeszcze szybszy (nawet jeśli większość z tych opcji powoduje niestabilność systemu plików po awarii, chyba że uruchomisz synchronizację przed awarią). Te polecenia prawie nie mają wpływu na ext4 z małymi plikami.

echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure
Jason Hall
źródło
1

Wydaje mi się, że ext3 (lub ext4), może JFS byłoby dobrym rozwiązaniem. Byłbym ostrożny z ext4 i btrfs (systemy plików są trudne - bądź przygotowany na kopie zapasowe, jeśli chcesz używać najnowszych, najnowszych rzeczy).

Istnieją również różne parametry, które można modyfikować w czasie mkfs, aby dostosować system plików do własnych upodobań.

Z pewnością poleciłbym przeciwko XFS. Nie dlatego, że jest to zły system plików, ale tworzenie / usuwanie jest na nim kosztowną operacją.


Aby uniknąć problemów z wyszukiwaniem katalogów, użyj inteligentnego schematu nazewnictwa, na przykład:

<first letter of id>_<last letter of id>/<id>

lub podobne, bardziej skomplikowane schematy. Przyspieszy to wyszukiwanie katalogów, a tym samym ogólne prędkości dostępu. (To stara sztuczka unixowa, myślę, że pochodzi z V7)


źródło
1
jaka jest zaleta używania pierwszej i ostatniej litery, a nie tylko pierwszych n liter?
bene
to tylko jeden z możliwych schematów - czy byłaby to zaleta, zależy od „klucza” używanego do indeksowania. Ten konkretny schemat, który widziałem w odniesieniu do aplikacji, która przechowywała dane o osobach w organizacji, dzięki czemu mają lepsze indeksowanie. Jak zawsze musisz dostosować go do swoich danych, a następnie profilować, aż znajdziesz dokładne odpowiedzi :)
1

Większość plików FS dusi się z ponad 65 000 plików w katalogu, myślę, że nadal dotyczy to ext4. Systemy plików Reiser nie mają tego limitu (ludzie na mp3.com zapłacili, aby się upewnić). Nie jestem pewien niczego innego, ale jest to jeden ze scenariuszy użycia, dla których stworzono ReiserFS.

Ronald Pottol
źródło
1
To ReiserFS, nie RieserFS
Daniel Rikowski,
W ten weekend miałem katalog na ext4 z 1000000 plików. Tak długo, jak tego nie zrobisz lslub tabulacja, działa szybko. Prawdopodobnie ze względu na indeks.
Ole Tange
ext4 ma rozszerzenie dir_index, które przyspiesza wiele plików w jednym katalogu.
alfonx