PowerScale OneFS: Felsökning av prestandaproblem

Klientdatorer körs långsamt. Specifika jobb, särskilt de som körs i klustret, misslyckas eller tar längre tid än förväntat.

Prestandaproblem beror vanligtvis på nätverkstrafik, problem med nätverkskonfiguration, klient- eller klusterbearbetningsbelastning eller en kombination av dessa faktorer. I den här artikeln beskrivs flera effektiva sätt att felsöka prestandaproblem.

Felsökning med InsightIQ

Innehållsförteckning:

• Använda Isilon InsightIQ
• Felsökning utan InsightIQ
• Nätverkets genomströmning
• Distribution av klientanslutningar
• Klustergenomströmning
• Bearbetning av kluster
• Köade åtgärder
• Processor

Använda Isilon InsightIQ

Att använda Isilon InsightIQ är det bästa sättet att övervaka prestanda och felsöka prestandaproblem.

Med den virtuella Isilon InsightIQ-enheten kan du övervaka och analysera Isilon-klusteraktivitet via flexibla, anpassningsbara diagramvyer i det webbaserade InsightIQ-programmet. De här diagrammen innehåller detaljerad information om maskinvara, programvara och filsystem och protokollåtgärder. InsightIQ omvandlar data till visuell information som betonar eventuella prestandaavvikelser, vilket möjliggör snabb diagnos av flaskhalsar eller optimerade arbetsflöden.

Mer information om hur du använder InsightIQ finns i PowerScale InsightIQ – informationshubb. 

Felsökning utan InsightIQ

Om du inte använder InsightIQ kan du köra olika kommandon för att undersöka prestandaproblem. Felsök prestandaproblem först genom att undersöka nätverks- och klusterdataflöde, sedan genom att undersöka klusterbearbetning och slutligen genom att undersöka enskilda noders CPU-hastigheter.

Nätverkets genomströmning

Använd ett verktyg för nätverkstestning, t.ex. Iperf eller Iperf3 för att fastställa dataflödeskapaciteten för klustret och klientdatorerna i nätverket.

Använda Iperfkör du följande kommandon på klustret och klienten. Dessa kommandon definierar en fönsterstorlek som är tillräckligt stor för att avslöja om nätverkslänken är en potentiell orsak till problem med svarstider.

• Kluster: iperf -s -w 262144
• Klient: iperf -c <cluster IP> -w 262144

Använda Iperf3kör du följande kommandon på klustret och klienten. Dessa kommandon definierar en fönsterstorlek som är tillräckligt stor för att avslöja om nätverkslänken är en potentiell orsak till problem med svarstider.

• Kluster: iperf3 -s -w 262144
• Klient: iperf3 -c <cluster IP> -w 262144

Distribution av klientanslutningar

Kontrollera hur många NFS- (Network File System) och SMB-klienter (Server Message Block) som är anslutna till klustret för att säkerställa att de inte prioriterar en nod.

1. Öppna en SSH-anslutning på en nod i klustret och logga in med hjälp av root Konto.
2. Kör isi statistics query current list --nodes=all --keys=node.clientstats.connected.nfs,node.clientstats.active.nfs -d för att kontrollera NFS-klienter. 
   Utdata visar antalet klienter som är anslutna per nod och hur många av dessa klienter som är aktiva på varje nod.
3. Kör isi statistics query current list --keys=node.clientstats.connected.smb,node.clientstats.active.smb1,node.clientstats.active.smb2 -n all -d för att kontrollera SMB-klienter.
   Utdata visar antalet klienter som är anslutna per nod och hur många av dessa klienter som är aktiva på varje nod.

Klustergenomströmning

Utvärdera klustrets dataflöde genom att utföra skriv- och lästester som mäter hur lång tid det tar att läsa från och skriva till en fil. Genomför minst ett skrivtest och ett lästest enligt följande.

Skriv ett test.

1. Öppna en SSH-anslutningpå en nod i klustret och logga in med hjälp av root Konto.
2. Ändra till /ifs Katalog: cd /ifs
3. Från kommandoradsgränssnittet (CLI) i klustret eller från en UNIX- eller Linux-klientdator använder du dd för att skriva en ny fil till klustret.
   Kör följande kommando: dd if=/dev/zero of=1GBfile bs=1024k count=1024
   Det här kommandot skapar ett exempel på en fil på 1 GB och rapporterar hur lång tid det tog att skriva den till disken.
4. Från utdata från det här kommandot extrapolerar du hur många MB per sekund som kan skrivas till disken i arbetsflöden med en ström.
5. Om du har en MAC-klient och vill göra ytterligare analyser,
   1. Starta Aktivitetskontroll.
   2. Kör cat /dev/zero > /pathToFile kommandot, där pathToFile är filsökvägen för målfilen.
      Det här kommandot hjälper till att mäta dataflödet för skrivåtgärder på Isilon Cluster. (Även om det är möjligt att köra dd från en MAC-klient kan resultaten vara inkonsekventa.)
   3. Övervaka resultatet av kommandot på fliken Nätverk i Aktivitetskontroll.

Läs testet.
När du mäter dataflödet för läsåtgärder bör du se till att inte utföra lästester på filen som du skapade under skrivtestet. Eftersom filen har cachelagrats skulle resultaten av dina lästester vara felaktiga. Testa i stället en läsåtgärd för en fil som inte har cachelagrats. Leta reda på en fil i klustret som är större än 1 GB och referera till filen i lästestet.

1. Öppna en SSH-anslutning på en nod i klustret och logga in med hjälp av root Konto.
2. Från CLI på klustret eller från en UNIX- eller Linux-klientdator använder du dd för att läsa en fil i klustret.
   Kör dd if=/pathToLargeFile of=/dev/null bs=1024k kommando där pathToFile är filsökvägen för målfilen.
   Det här kommandot läser målfilen och rapporterar hur lång tid det tog att läsa den.
3. Om du har en MAC-klient och vill göra ytterligare analyser,
   1. Starta Aktivitetskontroll.
   2. Kör time cp /pathToLargeFile > /dev/null kommando där pathToFile är filsökvägen för målfilen.
      Det här kommandot hjälper till att mäta dataflödet för läsåtgärder på Isilon-klustret. (Även om det är möjligt att köra dd från en MAC-klient kan resultaten vara inkonsekventa.)
   3. Övervaka resultatet av kommandot på fliken Nätverk i Aktivitetskontroll.

Bearbetning av kluster

Strippa om jobb.
Innan du undersöker I/O-åtgärder (indata/utdata) för klustret:

• Ta reda på vilka jobb som körs i klustret. Om restripe-jobb som Auto-Balance, Collect eller MultiScan körs bör du fundera över varför dessa jobb körs och om de ska fortsätta att köras.
• Överväg vilken typ av data som används. Om klientdatorerna arbetar med stora videofiler eller virtuella datorer kräver det omstripade jobbet en större mängd disk-IOPS än normalt.
• Överväg att tillfälligt pausa ett omstripningsjobb. Det kan förbättra prestanda och kan vara en genomförbar kortsiktig lösning på ett prestandaproblem.

Disk-I/O
Genom att undersöka disk-I/O kan du avgöra om vissa diskar överanvänds.

Efter kluster

1. Öppna en SSH-anslutning på en nod i klustret och logga in med ”rot”-kontot.
2. Kör isi statistics pstat kommando för att kontrollera disk-I/O.
3. Från utdata från det här kommandot dividerar du diskens IOPS med det totala antalet diskar i klustret. För ett kluster med 8 noder som använder Isilon IQ 12000x-noder, som har 12 enheter per nod, dividerar du till exempel diskens IOPS med 96.
   För noder i X-serien och noder i NL-serien bör du förvänta dig att se disk-IOPS på 70 eller mindre för 100 % slumpmässiga arbetsflöden, eller disk-IOPS på 140 eller mindre för 100 % sekventiella arbetsflöden. Eftersom noder i NL-serien har mindre RAM-minne och lägre processorhastigheter än noder i X-serien kan noder i X-serien hantera högre disk-IOPS.

Efter nod och disk

1. Öppna en SSH-anslutning på en nod i klustret och logga in med ”rot”-kontot.
2. Kör isi statistics query current --nodes=all --stats=node.disk.xfers.rate.sum --format=top kommando för att fastställa disk-IOPS efter nod, vilket kan hjälpa dig att identifiera diskar som är överanvända.
3. Kör isi_stats_tool -a get_key_info|grep node.disk.xfer för att avgöra hur du ska fråga efter statistik per disk.

Köade åtgärder

Ett annat sätt att avgöra om diskar överanvänds är att avgöra hur många åtgärder som placeras i kö för varje disk i klustret. För ett SMB-baserat arbetsflöde med en enda dataström kan en kö på fyra tyda på ett problem, medan kön är större för NFS-namnområdesåtgärder med hög samtidighet.

1. Öppna en SSH-anslutning på en nod i klustret och logga in med hjälp av root Konto.
2. Kör isi statistics drive list --nodes=all --sort=queued -d för att avgöra hur många åtgärder som placeras i kö för varje disk i klustret.
3. Ta reda på hur länge åtgärden fanns i kön: isi statistics drive list --nodes=all --sort=queued -d 

Processor

CPU-problem spåras ofta till de åtgärder som klienterna utför i klustret. Med hjälp av isi statistics kan du bestämma vilka åtgärder som ska utföras på klustret, katalogiserade efter antingen nätverksprotokoll eller klientdator.

1. Öppna en SSH-anslutning på en nod i klustret och logga in med hjälp av root Konto.
2. Kör isi statistics protocol list --long --totalby Op,proto -d --sort TimeAvg --format top för att avgöra vilka åtgärder som utförs i nätverket och bedöma vilka av dessa åtgärder som tar mest tid.
   Dessa kommandoutdata ger detaljerad statistik för alla nätverksprotokoll, ordnade efter hur lång tid det tar för klustret att svara på klienter. Även om resultatet av det här kommandot kanske inte identifierar vilken åtgärd som är långsammast, kan det peka dig i rätt riktning.
3. Kör isi statistics system --nodes all --format top för att få mer information om processorbearbetning, till exempel vilka noders processorer som används mest.
4. Kör isi_for_array -sX 'top -u -n |grep PID -A4' för att hämta de fyra processer på varje nod som förbrukar mest CPU-resurser.

• PowerScale OneFS informationshubbar
• Aktuella korrigeringsfiler för PowerScale OneFS