Udostępnij za pośrednictwem

Omówienie rozmiarów katalogów w usłudze Azure NetApp Files

  • Artykuł

Po utworzeniu pliku w katalogu wpis jest dodawany do ukrytego pliku indeksu w woluminie usługi Azure NetApp Files. Ten plik indeksu pomaga śledzić istniejące węzły w katalogu i pomaga przyspieszyć żądania wyszukiwania dla katalogów z dużą liczbą plików. W miarę dodawania wpisów do tego pliku rozmiar pliku zwiększa się (ale nigdy nie zmniejsza) w tempie około 512 bajtów na wpis w zależności od długości nazwy pliku. Dłuższe nazwy plików dodają większy rozmiar do pliku. Linki symboliczne dodają również wpisy do tego pliku. Ta koncepcja jest znana jako rozmiar katalogu, który jest wspólnym elementem we wszystkich systemach plików opartych na systemie Linux. Rozmiar katalogu nie jest maksymalną całkowitą liczbą plików w jednym woluminie usługi Azure NetApp Files. Jest to określane przez maxfiles wartość.

Domyślnie podczas tworzenia nowego katalogu używa on 4 bloków KiB (4096 bajtów) lub ośmiu bloków 512 bajtów. Rozmiar nowo utworzonego katalogu można wyświetlić na podstawie klienta systemu Linux przy użyciu polecenia stat.

# mkdir dirsize 
# stat dirsize 
File: ‘dirsize’ 
Size: 4096            Blocks: 8          IO Block: 32768  directory

Rozmiary katalogów są specyficzne dla pojedynczego katalogu i nie łączą się w rozmiarach. Jeśli na przykład w woluminie istnieje 10 katalogów, każdy z nich może zbliżyć się do limitu rozmiaru katalogu 320-MiB w jednym woluminie.

Określanie, czy katalog zbliża się do rozmiaru limitu

W przypadku katalogu 320-MiB liczba bloków wynosi 655360, a każdy rozmiar bloku wynosi 512 bajtów. (Oznacza to, 320x1024x1024/512). Ta liczba przekłada się na maksymalnie 4–5 milionów plików dla katalogu 320-MiB. Jednak rzeczywista liczba maksymalnych plików może być niższa, w zależności od czynników, takich jak liczba plików z znakami innymi niż ASCII w katalogu.

Możesz użyć stat polecenia od klienta, aby sprawdzić, czy katalog zbliża się do maksymalnego limitu rozmiaru metadanych katalogu (320 MB). Jeśli osiągniesz maksymalny limit rozmiaru dla pojedynczego katalogu dla usługi Azure NetApp Files, wystąpi błąd No space left on device .

W przypadku katalogu 320 MB liczba bloków wynosi 655 360, a każdy rozmiar bloku wynosi 512 bajtów. (Oznacza to, 320x1024x1024/512). Ta liczba przekłada się na maksymalnie 4 miliony plików dla katalogu 320 MB. Jednak rzeczywista liczba maksymalnych plików może być niższa, w zależności od czynników, takich jak liczba plików z znakami innymi niż ASCII w katalogu. Aby uzyskać informacje na temat monitorowania maxdirsize, zobacz Monitorowanie maxdirsize.

Zagadnienia dotyczące rozmiaru katalogu

Podczas pracy ze środowiskiem o dużej liczbie plików należy wziąć pod uwagę następujące zalecenia:

  • Woluminy usługi Azure NetApp Files obsługują maksymalnie 320 miB dla rozmiarów katalogów. Nie można zwiększyć tej wartości.
  • Po przekroczeniu rozmiaru katalogu woluminu klienci wyświetlają błąd braku miejsca, nawet jeśli w woluminie jest dostępne wolne miejsce.
  • W przypadku woluminów regularnych rozmiar katalogu MiB wynosi około 4–5 milionów plików w jednym katalogu. Ta wartość zależy od długości nazw plików.
  • Duże woluminy mają inną architekturę niż zwykłe woluminy.
  • Duże liczby plików w jednym katalogu mogą stanowić problemy z wydajnością podczas wyszukiwania. Jeśli to możliwe, ogranicz całkowity rozmiar pojedynczego katalogu do 2 MiB (około 27 000 plików), gdy są potrzebne częste wyszukiwania.
    • Jeśli w jednym katalogu jest potrzebnych więcej plików, odpowiednio dostosuj oczekiwania dotyczące wydajności wyszukiwania. Podczas gdy usługa Azure NetApp Files indeksuje listę plików katalogu pod kątem wydajności, wyszukiwanie może zająć trochę czasu z dużą liczbą plików.
  • Podczas projektowania systemu plików unikaj układów katalogów prostych. Aby uzyskać informacje o różnych podejściach do układów katalogów, zobacz About directory layouts (Informacje o układach katalogów).
  • Aby rozwiązać problemy z przekroczeniem rozmiaru katalogu, a nie można utworzyć nowych plików, usunąć ani przenieść plików z odpowiedniego katalogu.

Informacje o układach katalogów

Wartość maxdirsize może powodować problemy podczas korzystania z prostych struktur katalogów, w których pojedynczy folder zawiera miliony plików na jednym poziomie. Struktury folderów, w których pliki, foldery i podfoldery są przeplatane, mają niewielki wpływ na element maxdirsize. Istnieje kilka metodologii struktury katalogów.

Płaska struktura katalogów to pojedynczy katalog z wieloma plikami poniżej tego samego katalogu.

Diagram struktury katalogów prostych.

Szeroka struktura katalogów zawiera wiele katalogów najwyższego poziomu z plikami rozmieszczonymi we wszystkich katalogach.

Diagram struktury szerokiego katalogu.

Struktura katalogu głębokiego zawiera mniej katalogów najwyższego poziomu z wieloma podkatalogami. Mimo że ta struktura zapewnia mniej plików na folder, długości ścieżek plików mogą stać się problemem, jeśli układy katalogów są zbyt głębokie, a ścieżki plików stają się zbyt długie. Aby uzyskać szczegółowe informacje na temat długości ścieżek plików, zobacz Opis długości ścieżek plików w usłudze Azure NetApp Files.

Diagram struktury katalogu głębokiego.

Wpływ struktur katalogów prostych w usłudze Azure NetApp Files

Płaskie struktury katalogów (wiele plików w jednym lub kilku katalogach) mają negatywny wpływ na szeroką gamę systemów plików, woluminów usługi Azure NetApp File lub innych. Potencjalne problemy obejmują:

  • Wykorzystanie pamięci
  • Wykorzystanie procesora
  • Wydajność/opóźnienie sieci (szczególnie podczas masowych zapytań dotyczących plików, GETATTR operacji, READDIR operacji)

Ze względu na projekt dużych woluminów usługi Azure NetApp Files wpływ maxdirsize jest unikatowy. Duży wolumin maxdirsize usługi Azure NetApp Files ma unikatowy wpływ na jego projekt. W przeciwieństwie do zwykłego woluminu duży wolumin używa zdalnych twardych linków wewnątrz usługi Azure NetApp Files, aby ułatwić przekierowywanie ruchu między różnymi urządzeniami magazynowymi w celu zapewnienia większej skali i wydajności. W przypadku korzystania z katalogów prostych istnieje wyższy stosunek wewnętrznych zdalnych twardych linków do plików lokalnych. Te zdalne twarde łącza są liczone względem łącznej maxdirsize wartości, więc duża ilość może zbliżyć się do limitu maxdirsize szybciej niż zwykły wolumin.

Jeśli na przykład pojedynczy katalog zawiera miliony plików i generuje około 85% zdalnych twardych linków dla systemu plików, można oczekiwać maxdirsize , że zostanie wyczerpany z niemal dwukrotnie większą ilością, ponieważ wolumin zwykły.

Aby uzyskać najlepsze wyniki z rozmiarami katalogów w usłudze Azure NetApp Files:

  • Unikaj prostych struktur katalogów w usłudze Azure NetApp Files. Struktury szerokiego lub głębokiego katalogu działają najlepiej, pod warunkiem, że długość ścieżki pliku lub folderu nie przekracza standardów protokołu NAS.
  • Jeśli płaskie struktury katalogów są nieuniknione, monitoruj maxdirsize katalogi.

Monitor maxdirsize

W przypadku pojedynczego katalogu użyj stat polecenia , aby znaleźć rozmiar katalogu.

# stat /mnt/dir_11/c5

stat Mimo że polecenie może służyć do sprawdzania rozmiaru katalogu określonego katalogu, może nie być tak wydajne, aby uruchomić je indywidualnie w jednym katalogu. Aby wyświetlić listę największych rozmiarów katalogów posortowanych od największych do najmniejszych, następujące polecenie zapewnia, że pomijając katalogi migawek z zapytania.

# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn

Uwaga

Rozmiar katalogu zgłoszony przez polecenie stat jest w bajtach. Rozmiar zgłoszony w poleceniu find znajduje się w kiB.

Przykład

# stat /mnt/dir_11/c5 

  File: ‘/mnt/dir_11/c5’ 

  Size: 322396160       Blocks: 632168     IO Block: 32768  directory 
 
# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn 
316084 /mnt/dir_11/c5 

3792 /mnt/dir_19 

3792 /mnt/dir_16

W poprzednim przypadku rozmiar /mnt/dir_11/c5 katalogu to 316 084 KiB (308,6 MiB), który zbliża się do limitu 320-MiB. Oznacza to około 4,1 miliona plików.

# ls /mnt/dir_11/c5 | wc -l
4171624

W takim przypadku należy rozważyć akcje naprawcze, takie jak przenoszenie lub usuwanie plików.

Więcej informacji