Sdílet prostřednictvím

Osvědčené postupy souběžnosti Linuxu pro Azure NetApp Files – Sloty relací a položky tabulky slotů

  • Článek

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 zásobníku sítě serveru 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 IOPS.
  • Vzhledem k latenci 1 ms je potřeba souběžnost 155 k dosažení 155 000 IOPS.

Oracle DNFS latency curve

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_entriesa 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_entriesa 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_entriesa 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 IOPS.

  • 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í ion 1
      • Klient nebude vydávat více než 100 požadavků na server z tohoto připojení.
      • Očekává se, že server nebude přijímat více než 128 požadavků z klienta pro toto připojení.
    • Připojení ion 2
      • Klient nebude vydávat více než 100 požadavků na server z tohoto připojení.
      • Očekává se, že server nebude přijímat více než 128 požadavků z klienta pro toto připojení.
    • …
    • …
    • Připojení ion 8
      • Klient nebude vydávat více než 100 požadavků na server z tohoto připojení.
      • 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_entriesa 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 vydá na server na připojení maximálně 8 požadavků.
      • 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 vydá na server na připojení maximálně 8 požadavků.
      • 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 vydá na server na připojení maximálně 8 požadavků.
      • 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 pro jednotlivé připojení na sunrpc.tcp_max_slot_table_entries méně než 128, když se aplikace škáluje napříč mnoha síťovými připojeními (nconnect obecně a HPC a 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:

  • Škálování úloh na více instancí je často dominantní v sekvenční povaze.
  • Databázové úlohy, zejména OLTP, jsou často náhodné v přírodě.

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 IOPS | 859 MiB/s 55
8 KiB 2 ms 400 000 IOPS | 3 125 MiB/s 800
256 KiB 2 ms 16 000 IOPS | 4 000 MiB/s 32
256 KiB 4 ms 32 000 IOPS | 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

  1. 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.
  2. Spusťte následující příkaz:
    $ sysctl -p
  3. 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), nconnectplatí 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=2vš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í ion 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í ion 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í ion 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í ion 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í:

Screenshot that shows packets of interest.

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

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.

Screenshot that shows max session slots for Packet 12.

Následující příklad ukazuje paket 14 (maximální počet požadavků serveru):

Screenshot that shows max session slots for Packet 14.

Další kroky