Powiedzmy, że używamy ext4 (z włączonym dir_index) do hostowania około 3M plików (o średnim rozmiarze 750 KB) i musimy zdecydować, jakiego schematu folderów będziemy używać.
W pierwszym rozwiązaniu stosujemy funkcję skrótu do pliku i używamy folderu dwupoziomowego (1 znak dla pierwszego poziomu i 2 znaki do drugiego poziomu): dlatego, że filex.forskrót jest równy abcde1234 , będziemy przechowywać go na / path / a / bc /abcde1234-filex.for.
W drugim rozwiązaniu stosujemy funkcję skrótu do pliku i używamy folderu dwóch poziomów (2 znaki dla pierwszego poziomu i 2 znaki dla drugiego poziomu): dlatego, że filex.forskrót jest równy abcde1234 , będziemy przechowywać go na / path / ab / de /abcde1234-filex.for.
W przypadku pierwszego rozwiązania mamy następujący schemat /path/[16 folders]/[256 folders]ze średnią 732 plików na folder (ostatni folder, w którym plik będzie się znajdować).
Podczas gdy na drugim rozwiązaniu będziemy mieli /path/[256 folders]/[256 folders]ze związkiem średnio 45 plików w folderze .
Biorąc pod uwagę, że zamierzamy zapisywać / rozłączać / czytać pliki ( ale głównie czytać ) z tego schematu (zasadniczo system buforowania nginx), czy ma to znaczenie pod względem wydajności, jeśli wybraliśmy jedno lub drugie rozwiązanie?
Jakich narzędzi możemy użyć do sprawdzenia / przetestowania tej konfiguracji?
źródło
hdparm -Tt /dev/hdXale może nie być to najbardziej odpowiednie narzędzie.hdparmnie jest właściwym narzędziem, jest to sprawdzenie surowej wydajności urządzenia blokowego, a nie test systemu plików.Odpowiedzi:
Powodem utworzenia takiej struktury katalogów jest to, że systemy plików muszą zlokalizować plik w katalogu, a im większy katalog, tym wolniej działa.
O ile wolniej zależy od projektu systemu plików.
System plików ext4 używa B-drzewa do przechowywania pozycji katalogu. Oczekuje się, że sprawdzenie tej tabeli zajmie czas O (log n) , który przez większość czasu jest krótszy niż naiwna liniowa tabela używana przez ext3 i poprzednie systemy plików (a gdy nie jest, katalog jest zbyt mały, aby mógł naprawdę ważne).
System plików XFS używa zamiast tego drzewa B + . Zaletą tego nad tabelą skrótów lub drzewkiem B jest to, że dowolny węzeł może mieć wiele potomków b , gdzie w XFS b jest różny i może wynosić nawet 254 (lub 19 w przypadku węzła głównego; liczby te mogą być nieaktualne ). Daje to złożoność czasową O (log b n) , ogromną poprawę.
Każdy z tych systemów plików może obsłużyć dziesiątki tysięcy plików w jednym katalogu, przy czym XFS jest znacznie szybszy niż ext4 w katalogu z taką samą liczbą i-węzłów. Ale prawdopodobnie nie chcesz jednego katalogu z i-węzłami 3M, ponieważ nawet w przypadku drzewa B + wyszukiwanie może zająć trochę czasu. To właśnie doprowadziło do utworzenia katalogów w ten sposób.
Jeśli chodzi o proponowane struktury, pierwszą podaną opcją jest dokładnie to, co pokazano w przykładach nginx. Będzie działał dobrze na każdym systemie plików, choć XFS nadal będzie miał pewną przewagę. Druga opcja może działać nieco lepiej lub nieco gorzej, ale prawdopodobnie będzie całkiem blisko, nawet w testach porównawczych.
źródło
ls -lzajmuje całą minutę, jeśli katalog spadł z bufora i-węzłów. A kiedy jest buforowany, nadal zajmuje sekundę. Jest to z dyskiem SSD i Xeon z tonami pamięci RAM na dość niskim serwerze ruchu sieciowego.Z mojego doświadczenia wynika, że jednym z czynników skalujących jest rozmiar i-węzłów, dla których zastosowano strategię partycjonowania nazw skrótów.
Obie proponowane opcje tworzą maksymalnie trzy wpisy i-węzłów dla każdego utworzonego pliku. Ponadto pliki 732 utworzą i-węzeł, który jest nadal mniejszy niż zwykle 16 KB. Dla mnie oznacza to, że każda z opcji będzie działać tak samo.
Oklaskuję cię za twój krótki hasz; poprzednie systemy, nad którymi pracowałem, pobierały sumę podanego pliku i splicowały katalogi na podstawie tego ciągu, co jest znacznie trudniejszym problemem.
źródło
Z pewnością każda z tych opcji pomoże zredukować liczbę plików w katalogu do czegoś, co wydaje się rozsądne, dla XFS, Ext4 lub innego systemu plików. Nie jest oczywiste, co jest lepsze, musiałbym przetestować, aby powiedzieć.
Benchmark z aplikacją symulującą coś takiego jak rzeczywiste obciążenie pracą jest idealny. W przeciwnym razie wymyśl coś, co symuluje wiele małych plików. Mówiąc o tym, oto open source o nazwie smallfile . Jego dokumentacja odwołuje się do innych narzędzi.
hdparmrobienie trwałych operacji we / wy nie jest tak przydatne. Nie pokaże wielu małych I / O lub gigantycznych pozycji katalogu związanych z bardzo wieloma plikami.źródło
Jednym z problemów jest sposób skanowania folderu.
Wyobraź sobie metodę Java, która uruchamia skanowanie folderu.
Będzie musiał przydzielić dużą ilość pamięci i zwolnić ją w krótkim czasie, co jest bardzo ciężkie dla JVM.
Najlepszym sposobem jest uporządkowanie struktury folderów tak, aby każdy plik znajdował się w dedykowanym folderze, np. Rok / miesiąc / dzień.
Sposób pełnego skanowania polega na tym, że dla każdego folderu jest jedno uruchomienie funkcji, więc JVM wyjdzie z funkcji, zwolni pamięć RAM i uruchomi ją ponownie w innym folderze.
To tylko przykład, ale posiadanie tak ogromnego folderu nie ma sensu.
źródło
Mam ten sam problem. Próba przechowywania milionów plików na serwerze Ubuntu w ext4. Skończyłem uruchamiać własne testy porównawcze. Okazało się, że płaski katalog działa znacznie lepiej, a jednocześnie jest o wiele prostszy w użyciu:
Napisał artykuł .
źródło