Mam serwer kopii zapasowych Ubuntu 16.04 z dyskiem twardym 8x10 TB za pośrednictwem płyty montażowej SATA 3.0. 8 dysków twardych jest połączonych z RAID6, używany jest system plików EXT4. Ten system plików przechowuje ogromną liczbę małych plików z bardzo wieloma operacjami SEEK, ale niską przepustowością operacji we / wy. W rzeczywistości istnieje wiele małych plików z różnych serwerów, które są snappshotowane przez rsnapshot każdego dnia (wiele INODES bezpośrednio do tych samych plików. Mam bardzo słabą wydajność, ponieważ system plików (60 TB netto) przekroczył 50% wykorzystania. W tej chwili zużycie wynosi 75%, a

du -sch /backup-root/

zajmuje kilka dni (!). Maszyna ma 8 rdzeni i 16 GB pamięci RAM. Pamięć RAM jest całkowicie wykorzystywana przez pamięć podręczną systemu plików OS, 7 z 8 rdzeni jest zawsze bezczynnych z powodu IOWAIT.

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

Brakuje mi doświadczenia z tego rodzaju użytkowaniem systemu plików. Jakie opcje muszę to dostroić. Jaki system plików działałby lepiej w tym scenariuszu? Czy są jakieś opcje angażowania pamięci RAM dla innych opcji buforowania niż wbudowane w system operacyjny?

Jak radzisz sobie z bardzo dużymi ilościami małych plików w dużych zestawach RAID?

Dzięki, Sebastian

Mam podobną (choć mniejszą) konfigurację, z 12x dyskami 2 TB w macierzy RAID6, używanymi do tego samego celu ( rsnapshotserwer kopii zapasowych).

Po pierwsze, jest tak normalne, du -hsże poświęcenie tak dużo czasu na tak duży i używany system plików. Ponadto duuwzględnia twarde łącza, które powodują znaczne i gwałtowne obciążenie procesora oprócz oczywistego obciążenia we / wy.

Twoja powolność wynika z tego, że metadane systemu plików znajdują się w bardzo odległych (w kategoriach LBA) blokach, co powoduje wiele prób. Ponieważ normalny dysk RPM o prędkości 7,2 K zapewnia około 100 IOPS, możesz zobaczyć, ile godzin, jeśli nie dni, są potrzebne do załadowania wszystkich metadanych.

Coś, co możesz (nieniszcząco) poprawić w sytuacji:

• Pamiętaj, aby nie mający mlocate/slocateindeksowania /backup-root/(można skorzystać z usługi prunefs tego uniknąć), lub metadanych cache zaśmiecaj będzie poparzonych zaburzać zapasową czasu;
• Z tego samego powodu należy unikać działa duna /backup-root/. W razie potrzeby uruchom dutylko na określonym zainteresowanym podfolderze;
• niższa vfs_cache_pressureod wartości domyślnej (100) do bardziej konserwatywnej (10 lub 20). To poinstruuje jądro, aby preferowało buforowanie metadanych zamiast buforowania danych; to z kolei powinno przyspieszyć rsnapshot/rsyncfazę odkrywania;
• możesz spróbować dodać zapisywane urządzenie buforujące metadane, na przykład za pomocą lvmcache lub bcache . To urządzenie metadanych powinno oczywiście być dyskiem SSD;
• zwiększyć dostępną pamięć RAM.
• gdy używasz ext4, pamiętaj o problemach z przydzielaniem i-węzłów (przeczytaj tutaj na przykład). Nie jest to bezpośrednio związane z wydajnością, ale jest ważnym czynnikiem, gdy ma się tak wiele plików w systemie plików opartym na ext.

Inne rzeczy, których możesz spróbować - ale są to destrukcyjne operacje:

• korzystać z obu XFS -ftypei -finobtzestawem opcji;
• używaj ZFS w systemie Linux (ZoL) ze skompresowanym ARC i primarycache=metadataustawieniami (i być może L2ARC dla pamięci podręcznej tylko do odczytu).

Ten system plików przechowuje ogromną liczbę małych plików z bardzo wieloma operacjami SEEK, ale niską przepustowością operacji we / wy.

🎉

To jest coś, co chwyta dziś wielu ludzi. Niestety, konwencjonalne FS nie skalują się tutaj dobrze. Mogę dać ci kilka porad, jeśli chodzi o konfigurację, którą już masz: EXT4 na RAID-6 na dyskach twardych :

1. Niżej vm.vfs_cache_pressure, powiedzmy na 1. Zmieniłoby to nastawienie pamięci podręcznej na zachowanie większej liczby metadanych (i-węzeł, dentystyka) zamiast samych danych i powinno mieć pozytywny wpływ na zmniejszenie liczby wyszukiwań
2. Dodaj więcej pamięci RAM . Chociaż może to wyglądać dziwnie w przypadku serwera, na którym nie działają żadne świnkowe aplikacje, pamiętaj: jedynym sposobem na zmniejszenie liczby poszukiwań jest przechowywanie większej ilości metadanych w szybszym magazynie, biorąc pod uwagę, że masz tylko 16 GB, wydaje się, że powinno być stosunkowo łatwo zwiększyć ilość pamięci RAM
3. Jak powiedziałem, EXT4 nie jest dobrym wyborem dla twojego przypadku użycia, ale nadal możesz użyć niektórych funkcji, które łagodzą ból:
   • zewnętrzny dziennik jest obsługiwany, więc możesz spróbować dodać dysk SSD (lepiej dublowany) i umieścić tam dziennik. Sprawdź „ ext4: zastrzeżenia zewnętrzne dziennika ”
   • Spróbuj przełączyć tryb kroniki na montowanie „wszystkich danych jest kronikowanych”data=journal
4. Spróbuj przenieść pliki poza pojedynczy zakres FS . Na przykład, jeśli masz tutaj LVM-2, możesz tworzyć woluminy o mniejszym rozmiarze i używać ich przez jakiś czas, a następnie, gdy się zapełni, utwórz kolejny i tak dalej.
   • Jeśli nie masz LVM-2, możesz spróbować to zrobić za pomocą / dev / loop, ale nie jest to tak wygodne i prawdopodobnie mniej wydajne

UPD. : ponieważ okazało się, że jest to Linux Software RAID (LSR) RAID-6, oto dodatkowy element:

5. LSR ma własne opcje dostrajania, które wielu ludzi zdaje się przeoczyć
   • Pamięć podręczna pasków , którą można ustawić w ten sposób na maksimum: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Ale rób to ostrożnie (w razie potrzeby użyj mniejszej wartości), ponieważ rozmiar jest wielokrotnością fragmentu i w zależności od wybranego rozmiaru fragmentu zajmie to inną ilość pamięci RAM
   • Dziennik zewnętrzny, który może znajdować się również na tych lustrzanych dyskach SSD ( ale obecnie urządzenia MD utworzone bez dziennika nie można przekonwertować na takie ).

- To prawdopodobnie większość tego, co można poprawić bez ponownego projektowania od zera.

Mam bardzo niską wydajność, ponieważ system plików (60 TB netto) przekroczył 50% użycia. W tej chwili zużycie wynosi 75%

To bardzo poważny problem, ponieważ wysoki poziom zajętości miejsca na dysku tylko pogarsza fragmentację. A większa fragmentacja oznacza więcej poszukiwań. Nie zastanawiaj się już, dlaczego dawało mniej lub bardziej akceptowalną wydajność, zanim osiągnęła 50%. Wiele podręczników ma wyraźne zalecenia, aby nie dopuścić, aby FS rosły za 75–80%.

RAID6 nie pomaga ci w tym przypadku, coś takiego jak ZFS może umożliwić znacznie szybszy dostęp do metadanych i katalogu przy zachowaniu prędkości na tym samym poziomie.

Dyski z paskami RAID-6, dlatego wszystkie operacje wejścia / wyjścia trafiają do wszystkich dysków. Jest to dość nieefektywne w przypadku wielu małych plików. Jednak to prawdopodobnie nie jest twój główny problem, którym jest ...

Ext4 nie jest odpowiedni dla dużych systemów plików z milionami plików. Użyj XFS . Mam systemy plików XFS działające na poziomie 1,2 PB i z 1 miliardem plików, nie ma problemu. Po prostu użyj XFS .

Dziękuję wszystkim, którzy udzielili odpowiedzi na moje pytanie.

Oto jak to rozwiązałem:

Przede wszystkim dodałem maksymalną ilość pamięci RAM do płyty. Niestety, płyta obsługuje tylko do 64 GB pamięci RAM. Obserwowałem zachowanie po rozszerzeniu i było to rozczarowujące. Chociaż cała dostępna pamięć RAM została użyta do pamięci podręcznej IO, wydajność kopii zapasowej RSNAPSHOT nie uległa znaczącej poprawie.

Musiałem więc wyciągnąć dużą buławę. Dodałem dwa dyski NVME o pojemności 1 TB i zmontowałem je do macierzy RAID 1. RAID 6 składający się z 8x dysków twardych 10 TB został zdemontowany na jeden RAID 1 (składający się z 2 dysków twardych 10 TB, ext4) i jeden RAID 5 (składający się z dysków twardych 6x10 TB). RAID 1 zawiera teraz system operacyjny i kopię roboczą serwerów (które są synchronizowane 4 razy dziennie na tym dysku).

RAID5 jest teraz urządzeniem wspieranym przez BCACHE, wspieranym przez NVME-RAID 1 i sformatowanym przy pomocy ext4. Ten dysk zawiera kopie RSNAPSHOT. Każdej nocy pliki są synchronizowane z RAID1 na RAID5, co zmniejsza o połowę przepustowość operacji we / wy RAID5 w porównaniu do poprzedniej RAID6, która zawierała kopie robocze ORAZ migawki kopii zapasowej. Dzięki BCache nie dosłownie każdy pojedynczy plik jest zapisywany na dyskach, ale wszystkie zmiany w jednym bloku są zapisywane jeden raz, nawet jeśli zawiera kilka zmian pojedynczego pliku. To dodatkowo zmniejszyło liczbę operacji we / wy na dyskach twardych.

Wreszcie zmieniłem konfigurację RSnapshot. Poprzednio istniało 31 migawek dziennie i 18 migawek miesięcznych, co zaowocowało 49 generacjami kopii zapasowych. Teraz mam klasyczną konstrukcję 7d / 4w / 12m / 1y, która zmniejsza liczbę generacji kopii zapasowych do 24.

Po tych zmianach (i przy wspomnianej powyżej 64 GB pamięci RAM) czas trwania jednej migawki skrócił się z ~ 20 godzin do 1,5 godziny. Urządzenia BCache mają współczynnik trafień w pamięci podręcznej na poziomie 82% (po 6 tygodniach regularnej pracy).

Misja zakończona sukcesem. Dziękujemy wszystkim za przemyślenia i wkład.