PowerScale OneFS: Felsökning av prestandaproblem

Klientdatorer fungerar 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. 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
• Smartconnect
• 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 användarhandboken för InsightIQ.

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 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

Distribution av klientanslutningar

Kontrollera hur många NFS- och SMB-klienter som är anslutna till klustret för att säkerställa att de inte favoriserar en nod.

1. Öppna en SSH-anslutning på en nod i klustret och logga in med rotkontot.
2. Kör följande kommando för att kontrollera NFS-klienter:

   isi statistics query - nodes=all --stats=node.clientstats.connected.nfs,node.clientstats.active.nfs

   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 följande kommando för att kontrollera SMB-klienter:

   isi statistics query - nodes=all --stats=node.clientstats.connected.smb,
   node.clientstats.active.smb1,node.clientstats.active.smb2

   Utdata visar antalet klienter som är anslutna per nod och hur många av dessa klienter som är aktiva på varje nod.

Smartconnect

Kontrollera att noden som SmartConnect körs på inte belastas med nätverkstrafik.

1. Öppna en SSH-anslutning på en nod i klustret och logga in med rotkontot.
2. Kör följande kommando:

   isi_for_array -sq 'ifconfig|grep em -A3'

   Utdata visar en lista över alla IP-adresser som är bundna till det externa gränssnittet.
3. Kontrollera om det finns några noder som har ytterligare en IP-adress än resten.
4. Kontrollera statusen för de noder som du märkte i steg 3 genom att köra följande kommando:

   isi status

   Kontrollera dataflödeskolumnen för utdata för att fastställa belastningen på noderna som noterades i steg 3.

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 test

1. Öppna en SSH-anslutning på en nod i klustret och logga in med rotkontot.
2. Ändra till katalogen /ifs :

   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 följande kommando, där pathToFile är filsökvägen för målfilen:

      cat /dev/zero > /pathToFile

      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 test
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 rotkontot.
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 följande kommando där pathToFile är filsökvägen för målfilen:

   dd if=/pathToLargeFile of=/dev/null bs=1024k

   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 följande kommando där pathToFile är filsökvägen för målfilen:

      time cp /pathToLargeFile > /dev/null

      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

Omstripe-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 Multi-Scan 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. Detta kan förbättra prestandan avsevärt 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 rotkontot.
2. Kör följande kommando för att kontrollera disk-I/O:

   isi statistics pstat

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 rotkontot.
2. Kör följande kommando för att fastställa disk-IOPS per nod, vilket kan hjälpa dig att identifiera diskar som är överanvända:

   isi statistics query --nodes=all --stats=node.disk.xfers.rate.sum --top

3. Kör följande kommando för att avgöra hur du frågar efter statistik per disk:

   isi statistics describe --stats=all | grep 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å 4 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 rotkontot.
2. Kör följande kommando för att avgöra hur många åtgärder som placeras i kö för varje disk i klustret:

   isi_for_array -s sysctl hw.iosched | grep total_inqueue

3. Fastställ svarstiden som orsakas av köåtgärderna:

   sysctl -aN hw.iosched|grep bios_inqueue|xargs sysctl -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 rotkontot.
2. Kör följande kommando för att avgöra vilka åtgärder som utförs i nätverket och utvärdera vilka av dessa åtgärder som tar mest tid:

   isi statistics protocol --orderby=TimeAvg --top

   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 följande kommando för att få mer information om CPU-bearbetning, till exempel vilka noders processorer som används mest:

   isi statistics system --top

4. Kör följande kommando för att hämta de fyra processerna på varje nod som förbrukar mest CPU-resurser:

   isi_for_array -sq 'top -d1|grep PID -A4'

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