Osvědčené postupy souběžnosti Linuxu pro Azure NetApp Files – Sloty relací a položky tabulky slotů
Tento článek vám pomůže pochopit osvědčené postupy souběžnosti pro sloty relací a položky tabulky slotů protokolu NFS služby Azure NetApp Files.
NFSv3
NFSv3 nemá mechanismus pro vyjednávání souběžnosti mezi klientem a serverem. Klient a server každý definuje svůj limit bez konzultace s druhým. Pro dosažení nejlepšího výkonu byste měli zarovnávat maximální počet položek tabulky slotů na straně sunrpc
klienta s položkami podporovanými bez zpětného odeslání na serveru. Když klient zahltí schopnost serverového síťového zásobníku zpracovat úlohu, server reaguje snížením velikosti okna pro připojení, což není ideální scénář výkonu.
Ve výchozím nastavení moderní linuxová jádra definují velikost sunrpc.tcp_max_slot_table_entries
položky tabulky slotů pro připojení sunrpc
jako podporu 65 536 nevyřízených operací, jak je znázorněno v následující tabulce.
Server Azure NetApp Files NFSv3 Maximální počet kontextů spuštění na připojení |
Klient Linuxu Výchozí maximální počet sunrpc položek tabulky slotů na připojení |
---|---|
128 | 65 536 |
Tyto položky tabulky slotů definují omezení souběžnosti. Hodnoty, které jsou vysoké, nejsou nutné. Například pomocí teorie fronty známé jako Littles Law zjistíte, že míra vstupně-výstupních operací je určena souběžností (tj. nevyřízených vstupně-výstupních operací) a latencí. Algoritmus například prokáže, že 65 536 slotů je řádově vyšší, než je potřeba k řízení i extrémně náročných úloh.
Littles Law: (concurrency = operation rate × latency in seconds)
Úroveň souběžnosti až 155 je dostatečná k dosažení 155 000 operací SYSTÉMU SOUBORŮ NFS oracle db za sekundu nconnect
pomocí systému souborů NFS Oracle Direct, což je technologie podobná v konceptu možnosti připojení:
- Vzhledem k latenci 0,5 ms je potřeba souběžnost 55 k dosažení 110 000 I/OPS.
- Vzhledem k latenci 1 ms je potřeba souběžnost 155 k dosažení 155 000 I/OPS.
Podrobnosti najdete v tématu Výkon databáze Oracle na jednotlivých svazcích Azure NetApp Files.
Ladění sunrpc.tcp_max_slot_table_entries
je parametr ladění na úrovni připojení.
Osvědčeným postupem je nastavit tuto hodnotu na 128 nebo méně na připojení, a nepřekročila 10 000 slotů v celém prostředí.
Příklady počtu slotů na základě doporučení souběžnosti
Příklady v této části ukazují počet slotů na základě doporučení souběžnosti.
Příklad 1 – jeden klient NFS, 65 536 sunrpc.tcp_max_slot_table_entries
a ne nconnect
pro maximální souběžnost 128 na základě limitu na straně serveru 128
Příklad 1 je založen na jedné úloze klienta s výchozí sunrpc.tcp_max_slot_table_entry
hodnotou 65 536 a jedním síťovým připojením, to znamená ne nconnect
. V tomto případě je souběžnost 128 dosažitelná.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
-
Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP
)- Klient v teorii nemůže vydávat více než 65 536 požadavků v letu na server na připojení.
- Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.
-
Příklad 2 – jeden klient NFS, 128 sunrpc.tcp_max_slot_table_entries
a ne nconnect
pro maximální souběžnost 128
Příklad 2 je založený na jedné úloze klienta s sunrpc.tcp_max_slot_table_entry
hodnotou 128, ale bez nconnect
možnosti připojení. Díky tomuto nastavení je souběžnost 128 dosažitelná z jednoho síťového připojení.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
- Klient nebude vydávat více než 128 požadavků na server na připojení.
- Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.
Příklad 3 – jeden klient NFS, 100 sunrpc.tcp_max_slot_table_entries
a nconnect=8
maximální souběžnost 800
Příklad 3 je založený na jedné úloze klienta, ale s nižší sunrpc.tcp_max_slot_table_entry
hodnotou 100. Tentokrát se nconnect=8
možnost připojení použila k rozložení úlohy mezi 8 připojení. Díky tomuto nastavení je souběžnost 800 dosažitelná napříč 8 připojeními. Tato částka je souběžnost potřebná k dosažení 400 000 I/OPS.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP), Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)… Connection 8 (10.10.10.10:2049, 10.10.10.11:7321,TCP)
- Připojení 1
- Klient vydá na server z tohoto připojení maximálně 100 požadavků.
- Očekává se, že server nebude přijímat více než 128 požadavků z klienta pro toto připojení.
- Připojení 2
- Klient vydá na server z tohoto připojení maximálně 100 požadavků.
- Očekává se, že server nebude přijímat více než 128 požadavků z klienta pro toto připojení.
…
…
- Připojení 8
- Klient vydá na server z tohoto připojení maximálně 100 požadavků.
- Očekává se, že server nebude přijímat více než 128 požadavků z klienta pro toto připojení.
Příklad 4 – 250 klientů NFS, 8 sunrpc.tcp_max_slot_table_entries
a ne nconnect
pro maximální souběžnost 2000
Příklad 4 používá pro prostředí EDA 250 sníženou hodnotu na klienta sunrpc.tcp_max_slot_table_entry
o 8. V tomto scénáři je dosaženo souběžnosti 2000 v celém prostředí, což je hodnota větší než dostatečná pro řízení 4 000 MiB/s úlohy back-endu EDA.
NFS_Server=10.10.10.10, NFS_Client1=10.10.10.11
Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
- Klient nebude vydávat více než osm požadavků za letu na server na připojení.
- Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.
NFS_Server=10.10.10.10, NFS_Client2=10.10.10.12
Connection (10.10.10.10:2049, 10.10.10.12:7820,TCP)
- Klient nebude vydávat více než osm požadavků za letu na server na připojení.
- Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.
…
…
NFS_Server=10.10.10.10, NFS_Client250=10.10.11.13
Connection (10.10.10.10:2049, 10.10.11.13:4320,TCP)
- Klient nebude vydávat více než osm požadavků za letu na server na připojení.
- Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.
Při použití NFSv3 byste měli společně zachovat počet slotů koncového bodu úložiště na 10 000 nebo méně. Nejlepší je nastavit hodnotu připojení na sunrpc.tcp_max_slot_table_entries
méně než 128, když se aplikace škáluje na více než 128 síťových připojení (nconnect
obecně a HPC a konkrétně EDA).
Jak vypočítat to nejlepší sunrpc.tcp_max_slot_table_entries
Pomocí funkce Littles Law můžete vypočítat celkový požadovaný počet položek tabulky slotů. Obecně zvažte následující faktory:
- Úlohy se škálováním na více instancí jsou často dominantní v sekvenční povaze.
- Databázové úlohy, zejména zpracování online transakcí, jsou často náhodné povahy.
Následující tabulka ukazuje ukázkovou studii souběžnosti s libovolnou latencí:
Velikost vstupně-výstupních operací | Latence | Vstupně-výstupní operace nebo propustnost | Souběžnost |
---|---|---|---|
8 KiB | 0,5 ms | 110 000 I/OPS | 859 MiB/s | 55 |
8 KiB | 2 ms | 400 000 I/OPS | 3 125 MiB/s | 800 |
256 KiB | 2 ms | 16 000 I/OPS | 4 000 MiB/s | 32 |
256 KiB | 4 ms | 32 000 I/OPS | 8 000 MiB/s | 128 |
Výpočet nastavení souběžnosti podle počtu připojení
Pokud je například úloha farma EDA a 1 250 klientů všechny jednotky úlohy do stejného koncového bodu úložiště (koncový bod úložiště je IP adresa úložiště), vypočítáte požadovanou vstupně-výstupní sazbu a vydělíte souběžnost napříč farmou.
Předpokládejme, že úloha je 4 000 MiB/s pomocí průměrné velikosti operace 256 KiB a průměrné latence 10 ms. Pokud chcete vypočítat souběžnost, použijte následující vzorec:
(concurrency = operation rate × latency in seconds)
Výpočet se přeloží na souběžnost 160:
(160 = 16,000 × 0.010)
Vzhledem k tomu, že potřebujete 1 250 klientů, můžete bezpečně nastavit sunrpc.tcp_max_slot_table_entries
2 na klienta, abyste dosáhli 4 000 MiB/s. Můžete se ale rozhodnout, že budete moct sestavovat v nadbytečné místnosti tak, že nastavíte počet na klienta na 4 nebo dokonce 8, přičemž budete mít dobře pod doporučeným stropem slotu 10 000.
Jak nastavit sunrpc.tcp_max_slot_table_entries
na klientovi
- Přidejte
sunrpc.tcp_max_slot_table_entries=<n>
do konfiguračního/etc/sysctl.conf
souboru.
Pokud se při ladění najde optimální hodnota nižší než 128, nahraďte hodnotu 128 odpovídajícím číslem. - Spusťte následující příkaz:
$ sysctl -p
- Připojte (nebo znovu připojte) všechny systémy souborů NFS, protože tunable se vztahuje pouze na připojení vytvořená po nastavení ladění.
NFSv4.1
V NFSv4.1 relace definují vztah mezi klientem a serverem. Bez ohledu na to, jestli připojené systémy souborů NFS jsou připojené k jednomu připojení nebo mnoha (stejně jako tomu je), nconnect
platí pravidla pro relaci. Při nastavení relace klient a server vyjednávají maximální požadavky na relaci a uspokojuje se na nižších ze dvou podporovaných hodnot. Azure NetApp Files podporuje 180 nevyřízených požadavků a klienti Linuxu mají výchozí hodnotu 64. V následující tabulce jsou uvedené limity relací:
Server Azure NetApp Files NFSv4.1 Maximální počet příkazů na relaci |
Klient Linuxu Výchozí maximální počet příkazů na relaci |
Vyjednané maximální počet příkazů pro relaci |
---|---|---|
180 | 64 | 64 |
I když klienti s Linuxem mají výchozí hodnotu 64 maximálních požadavků na relaci, je hodnota max_session_slots
vyladěná. Aby se změny projevily, vyžaduje se restartování.
systool -v -m nfs
Pomocí příkazu zobrazíte aktuální maximum používané klientem. Aby příkaz fungoval, musí být na místě alespoň jedno připojení NFSv4.1:
$ systool -v -m nfs
{
Module = "nfs"
...
Parameters:
...
max_session_slots = "64"
...
}
Chcete-li ladit max_session_slots
, vytvořte konfigurační soubor pod /etc/modprobe.d
takovým způsobem. Ujistěte se, že pro řádek v souboru nejsou žádné "uvozovky". Jinak se tato možnost neprojeví.
$ sudo echo “options nfs max_session_slots=180” > /etc/modprobe.d/nfsclient.conf
$ sudo reboot
Azure NetApp Files omezuje každou relaci na maximálně 180 příkazů. Proto zvažte maximální hodnotu 180, která je aktuálně konfigurovatelná. Klient nebude moct dosáhnout souběžnosti větší než 128, pokud není relace rozdělena mezi více než jedno připojení, protože Azure NetApp Files omezuje každé připojení na maximálně 128 příkazů NFS. Pokud chcete získat více než jedno připojení, nconnect
doporučuje se možnost připojení a vyžaduje se hodnota dvou nebo větších.
Příklady očekávaných maximální souběžnosti
Příklady v této části ukazují očekávané maximum souběžnosti.
Příklad 1 – 64 max_session_slots
a ne nconnect
Příklad 1 je založen na výchozím nastavení 64 max_session_slots
a ne nconnect
. Díky tomuto nastavení je souběžnost 64 dosažitelná, a to vše z jednoho síťového připojení.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
- Klient vydá na server pro relaci maximálně 64 požadavků.
- Server nebude přijímat více než 64 požadavků z klienta pro relaci. (64 je vyjednaná hodnota.)
Příklad 2 – 64 max_session_slots
a nconnect=2
Příklad 2 je založen na 64 max session_slots
, ale s přidanou možností montáže nconnect=2
. Souběžnost 64 je dosažitelná, ale rozdělená mezi dvě spojení. I když v tomto scénáři nepřináší více souběžnosti více připojení, menší hloubka fronty na připojení má pozitivní dopad na latenci.
max_session_slots
S stále na 64, ale nconnect=2
všimněte si, že maximální počet požadavků se rozdělí mezi připojení.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
- Připojení 1
- Klient nebude vydávat více než 32 požadavků na server z tohoto připojení.
- Očekává se, že server nebude přijímat více než 32 požadavků z klienta pro toto připojení.
- Připojení 2
- Klient nebude vydávat více než 32 požadavků na server z tohoto připojení.
- Očekává se, že server nebude přijímat více než 32 požadavků z klienta pro toto připojení.
Příklad 3 – 180 max_session_slots
a ne nconnect
Příklad 3 zahodí nconnect
možnost připojení a nastaví max_session_slots
hodnotu na 180 odpovídající maximální souběžnosti relace NFSv4.1 serveru. V tomto scénáři platí, že s pouze jedním připojením a vzhledem k maximálnímu nevyrovnanému počtu operací Azure NetApp Files na připojení NFS je relace omezená na 128 operací za letu.
I když max_session_slots
je nastavená hodnota 180, jedno síťové připojení je omezené na 128 maximálních požadavků, jako například:
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
- Klient vydá na server pro relaci maximálně 180 požadavků.
- Server nebude přijímat více než 180 požadavků z klienta pro relaci.
- Server nebude přijímat více než 128 požadavků na jedno připojení.
Příklad 4 – 180 max_session_slots
a nconnect=2
Příklad 4 přidá nconnect=2
možnost připojení a znovu použije hodnotu 180 max_session_slots
. Vzhledem k tomu, že je celková úloha rozdělená mezi dvě připojení, je možné dosáhnout 180 nevyřízených operací.
Se dvěma připojeními ve hře relace podporuje úplné přidělení 180 nevyřízených požadavků.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
- Připojení 1
- Očekává se, že klient nebude uchovávat více než 90 požadavků na server z připojení.
- Očekává se, že server nebude uchovávat více než 90 požadavků z klienta pro toto připojení v rámci relace.
- Připojení 2
- Očekává se, že klient nebude uchovávat více než 90 požadavků na server z připojení.
- Očekává se, že server nebude uchovávat více než 90 požadavků z klienta pro toto připojení v rámci relace.
Poznámka:
Pro maximální souběžnost nastavte max_session_slots
hodnotu 180, což je maximální souběžnost na úrovni relace podporovaná službou Azure NetApp Files.
Postup kontroly maximálních nevyřízených požadavků pro relaci
Pokud chcete zobrazit session_slot
velikosti podporované klientem a serverem, zachyťte příkaz mount v trasování paketů.
CREATE_SESSION
Vyhledejte hovor a CREATE_SESSION
odpověď, jak je znázorněno v následujícím příkladu. Volání pochází z klienta a odpověď pochází ze serveru.
K zachycení příkazu mount použijte následující tcpdump
příkaz:
$ tcpdump -i eth0 -s 900 -w /tmp/write.trc port 2049
Pomocí Wiresharku jsou pakety, které jsou zajímavé, následující:
V rámci těchto dvou paketů se podívejte na max_reqs
pole v prostřední části trasovacího souboru.
- Systém souborů sítě
- Operace
Opcode
csa_fore_channel_attrs
max reqs
- Operace
Paket 12 (maximální počet požadavků klienta) ukazuje, že klient měl max_session_slots
hodnotu 64. V další části si všimněte, že server podporuje souběžnost 180 pro relaci. Relace nakonec vyjednává nižší ze dvou zadaných hodnot.
Následující příklad ukazuje paket 14 (maximální počet požadavků serveru):
Další kroky
- Osvědčené postupy pro přímé vstupně-výstupní operace Linuxu pro Azure NetApp Files
- Osvědčené postupy mezipaměti systému souborů Linuxu pro Azure NetApp Files
- Osvědčené postupy pro možnosti připojení systému souborů NFS pro Linux pro Azure NetApp Files
- Osvědčené postupy pro čtení systému souborů NFS pro Linux
- Osvědčené postupy skladových jednotek virtuálních počítačů Azure
- Srovnávací testy výkonu pro Linux