Systematische Performance Analyse

Transcript

2. Systematische Performance Analyse Ulrich Gräf Principal Sales Consultant
3. Performance Analyse nötig? Ist die Applikation schnell genug? • Ja? Dann sind wir fertig! Was ist Unsinn? • “Machen Sie es so schnell wie möglich!” – Darf es denn soviel wie möglich kosten? • “Die Maschine kann doch mehr!” – Stimmt, das kann sie immer, aber um welchen Preis? Man braucht also klare Ziele zum Benchmarken!
4. Strategie vs. Taktik • Strategische Benchmarks – Zahlen zum Veröffentlichen – Gute Zahlen – Viel Finetuning – ... Werte in der Praxis nicht erreichbar • Taktische Benchmarks – ~ Proof-of-Concept – Aufzeigen: Applikation ist schnell genug – Sizing – Sicherheit beim Kunden schaffen
5. Taktische Performance Analyse ... wie ein Wetterbericht, aber bessere Genauigkeit: Disk IO ist das Problem (70%) Applikation läuft nicht parallel (20%) FERTIG!
6. Performance Analyse Die klassischen Bereiche: • CPU - Sind die CPUs überlastet? • Memory - Zuwenig Memory eingebaut? • IO - Volumes/Platten zu langsam? • Netzwerk - Ist das Netzwerk überlastet? • Systemlast - App. überlastet das System. – Systemcalls – Mutex – xcalls
7. 1. CPU: Analyse allgemein • CPU überlastet: – Kommando: vmstat 5 – Spalte idle ist 0 (letzte Spalte rechts)=> 100% Auslastung – mehr geht nicht! – Bei zuviel System Time (Spalte sys): – -> 5. Applikation erzeugt zuviel System Last
8. 1. CPU: Analyse (1) • Thread ist im Verdacht – prstat -L Thread behindert Prozess • CPU des Threads ist bei ( 100 / Anzahl_CPUs ) % – Klarheit schaffen mit pbind • Thread an CPU binden: – pbind -b cpu cpu/thread
9. 1. CPU: Analyse (2) • SMP-System (mehrere CPUs oder Cores): – mpstat 5 Eine CPU ist bei 100% (0% wt + idl) – prstat Prozess nutzt eine CPU: Spalte CPU • Anmerkungen: – Eine CPU entspricht im ps/prstat ( 100 / Anzahl_CPUs ) % – Die Spalten wt im mpstat sagen nichts aus – prstat zeigt die Anzahl der Threads als NLWP – CMT: corestat für Analyse core notwendig
10. 1. CPU: Analyse (Multi- Processing) • psrset benutzen um Applikation festzubinden – Applikation bleibt dann im Prozessor Set – Kommandos: – psrset -c <cpu>... • Prozessor-Set erzeugen aus angegebenen CPUs – psrset -b <psrset> <pid>... • Laufende Prozesse an Prozessor-Set binden • CPU-Last unbeeinflusst beobachtbar • Auch zur Lösung nutzbar
11. 1. CPU: Behebung (1) • Bei idle = 0% sprich user + system = 100%: – Mehr CPUs einbauen • Schnellere CPUs einbauen (so verfügbar) – Allgemein: kein CPU-Rennen mehr... • Applikation anders Programmieren oder Benutzen – mehr Threads – Applikation mehrfach starten • Daten aufteilen in Teilmengen
12. 1. CPU: Behebung (2) • Reservieren von Ressourcen für die Prozesse – psrset (schon seit Solaris 2.6, saubere Separation) • gut ad-hoc nutzbar – Resource Pools mit Prozessorsets (ab Solaris 9) • aufwendiger als psrset, gut für dauerhafte Nutzung – Fixed Priority Scheduler (ab Solaris 9) • ~ Real-Time Scheduler Features ohne die Gefahren! – pbind (aber kein Ausschluß → nicht benutzen) – Modifizieren der Scheduling Tabellen (gefährlich)
13. 1. CPU: Tuning • FX Scheduler: Hervorheben bestimmter Prozesse – TCP Listener der Datenbank – Authorisierungsserver (so vorhanden) • FX Scheduler – De-priorisieren von z.B: Backup Prozessen
14. 2. Memory: Analyse (1) • Memory: – vmstat 5 • zeigt: die Spalten free und sr(meist verrutscht) • swap: freier virtueller Speicher in KByte • free: freier realer Speicher in Kbyte (~1/32 muss immer frei sein (minfree)) • sr: scan rate (dauernd > 0 bei Speichernotstand) in 8k-Seiten/Sekunde Suche nach Seiten zum Freigeben Nur noch bei Programmstarts > 0 z.B. DB Start (Ab S8) Sonst: Maschine hat zuwenig Real-Speicher!
15. 2. Memory: Analyse (2) • Memory eines Prozesses: pmap • Oder mit mdb -k Makro: ::memstat
16. 2. Memory Fresser: Segmap (UFS) • Segmap: System Segment für I/O zu Dateien – Wenn das Programm mmap benutzt: eigenes Segment – Alles andere: mapping via Segment segmap im OS – Default für segmap ist 12 % • z.B. Bei 64 GB Hauptspeicher fast 8 GB! – Einstellung in /etc/system (Wert in Prozent) – Segmap größer • bei File-Server • Programme mit vielen Dateien • Nur bei UFS, PCFS, HSFS, nicht bei ZFS
17. 2. Memory Fresser: ARC • ZFS benutzt einen neuen Cache: ARC – Einen anderen als UFS! – ARC – Adaptive Replacement Cache • Passt sich automatisch an die Nutzung der Daten an • Unterscheidet Daten: einmal gelesen, häufig gelesen • Einmal gelesene Daten stören nicht das Caching der häufig gelesenen Daten • ARC Cache Default ist 75% des Hauptspeichers – Automatische Anpassung an verfügbaren Speicher – “Kampf” zwischen ARC und Applikationen – Reduktion z.B.: set zfs_arc_max=0x78000000 (Bytes)
18. 2. Memory: TLB • Virtual Memory – Virtuelle Adresse muss umgesetzt werden – Hashtabelle im System (pagemap) – Beschleunigung durch TLB • TLB - Translation Lookaside Buffer – Assozativer Cache -> Zugriff in einem CPU-Takt – Aber: nur 64 .. 512 Einträge ( * 8 KByte = 4 MByte !!!) – Analyse: cputrack / cpustat (CPU abhängig) – TLB miss (dtlb..., itlb..., siehe cpustat -h) – Shared Memory Segmente nutzen automatisch größere Seiten (shmat)
19. 3. Disk IO: Analyse (1) • Disk-Auslastung: – 'iostat -xzn 5' zeigt nach Plattennamen sortiert: • read und write pro Sekunde (zusammen: I/O / Sek) • read KB und write KB: Datenrate • asvc_t: average Service time in Millisekunden – <= 20 ist optimal, 2-5 ist super, 0-1 ist SSD – länger ist ok, wenn User zufrieden
20. 3. Disk IO: Analyse (2) • iostat -xzn 5 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 1547.8 7.6 16960.3 66.4 0.0 1.0 0.0 0.7 1 78 c1t0d0 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 762.6 0.0 4612.3 0.0 0.0 0.2 0.0 0.3 0 21 c1t0d0 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 2160.2 0.0 6312.9 0.0 0.0 0.6 0.0 0.3 1 55 c1t0d0
21. 3. Disk IO: Analyse (3) • Disk-Auslastung: – %b: zu wieviel Prozent der Zeit die Platte beschäftigt war (mindestens 1 I/O aktiv). Das sagt gar nichts aus! Multiple I/Os pro Platte sind möglich (tags)! (ausser bei IDE Platten) – wait: IO kann nicht an Platte übertragen werden • Limit der Platte erreicht • max_throttle (/etc/system) erreicht
22. 3. Disk IO: Analyse (4) • Remote Mirroring über lange Strecken – Erhöht die Antwortzeit, z.T. extrem • Summation des Datenverkehrs für Controller – iostat -Cxn 5 • Analyse IO pro Disk Slice – iostat -xznp 5
23. 3. Disk I/O: Behebung (1) • Bei einer Überlastung der Disk – Daten neu verteilen – (Software) Raid-5 / raidz/raidz2 auflösen – Plattensubsystem mit Schreibcache verwenden (wenn hohe Anzahl write vorliegt) – besser stripen (Thin Wide Stripes!) • Volumes – SVM Volumes sind in iostat sichtbar – Veritas Volumes: Kommando 'vxstat'
24. 3. Disk I/O: Behebung (2) • Storage-Subsystem mit Cache (batteriegepuffert) – statt JBOD • SSD Disk mit ZFS als Log oder Cache
25. 3. Disk I/O: Dtrace (Solaris 10) • read / write: Zuordnung zur Applikation • Statistik über die Größe von read/write • welche Applikation verursacht I/O auf – einer Platte – allen Platten mit Statistik • Summarische Daten bereits ab Solaris 8 mit kstat – Zahlen werden pro Platte / Partition aufsummiert – iostat nutzt dieses Interface – was gibts?: kstat -c disk • Umsetzung sd Nummern in Plattennamen: /etc/path_to_inst
26. 4. Netzwerk I/O: Analyse • Netzwerk-Auslastung: – nicht so einfach zu sehen – netstat -I ge0 5 • zeigt die Zahl der Pakete auf Interface ge0 – kstat -p -c net 5 • plus Auswertescript zeigt alles • z.B.: ifstat (Basis ist kstat)
27. 4. Netzwerk I/O: Behebung – IPQoS (S9 - S10) – Crossbow Flows (S11...) – mehr Netzwerk Interfaces – Behebung von ungünstiger Programmierung in der Applikation – Trunking hilft nur bei 1:n – 10 GBit Ethernet (demnächst 40Gbit) – Infiniband
28. 5. Applikation zuviel Systemlast • Feststellbar mit: vmstat 5 – Spalte sys ist zu hoch – zu hoch? ab 10 % – Schlechte Applikationen bis 60 %
29. 5.1 Applikation: Mutex • Mutex – was ist das? – Das OS synchronisiert mit locks viele Dinge. – spinning mutex: Warten auf das lock • da es sich nicht lohnt den Prozess zu suspendieren • man sowieso gleich drankommt (hoffentlich) – zu häufig: spinning mutex Werte sind hoch
30. 5.1 Applikation: Mutex • Messen von spinning mutex – mit 'mpstat 5' in der Spalte smtx – US-III bis 8000-12000 smtx pro CPU – US-IV bis 20000 pro CPU – SPARC-64: 50000 - 60000 – dann Systemcalls und Applikation langsamer – Applikation synchronisiert zuviel • Handshake mit zu kleinen Daten-Elementen(Byte für Byte...) • zu kleine Netzwerk-Pakete • ggf. in Konfig-Datei einstellbar – dtrace (ab Solaris 10)
31. 5.2 Applikation: Systemcalls • Applikation macht zuviele Systemcalls • sichtbar im mpstat Spalte syscl • Anzahl der Systemcalls pro Sekunde (diese CPU) • Zuordnung zur Applikation • dtrace (ab Solaris 10) • truss – Prozess muß bekannt sein – kann Performance beeinträchtigen – besser: truss -c -p <pid> • Behebung nur durch Änderung der Applikation
32. 5.3 Applikation: Processor Crosscalls • Prozess liest Daten, die von einem anderen Prozessor noch bearbeitet werden – schlechte Applikation – Backup von Dataspace einer Datenbank • Summarisch: mpstat Spalte xcal • Zuordnung zur Applikation: dtrace • Behebung: • Überarbeitung Betriebskonzept
33. 5.4 Applikation: Software • Software-Analyse – 'truss <Kommando>...' oder – 'truss -p <pid>' • untersucht die Systemaufrufe von Applikationen. – Kenntnisse der Unix Systemcalls sind erforderlich – Fehlverhalten von Programmen entdeckbar (keine Garantie!) – optimalere Einstellung der Volumes oder des OS möglich
34. Speicherzugriff • Applikation “springt” wild durch den Speicher • z.B. Java... • TLB misses und Cache Verhalten • Gesamtsystem: cpustat • Applikation: cputrack • Andere Pagegrößen • pmap -s <pid> • Spalte Pgsz • Verfügbare: pagesize -a – Default: 8KByte 4 KByte – Setzen mit: ppgsz
35. Disk Technologie • wie lange dauert es die ganze Platte zu lesen (Backup) Jahr Disk Kapazität MByte / Mittlere RPM IO / IO / MByte / (Seagate) in GB Sekunde Zugriffs- Sekunde Sekunde Sekunde Zeit je GB je GB 1991 ST1480N 0.424 2.62 14 4412 73 172.00 6.18 1992 ST11200N 1.054 4.00 11.2 5411 90 85.30 3.80 1993 ST12400N 2.148 4.50 10.5 5411 90 41.80 2.09 1994 ST15230N 4.294 5.88 11.4 5411 90 21.00 1.37 1995 ST19171N 9.100 12.80 10.7 7200 120 13.20 1.40 1996 ST118273LC 18.210 19.40 8.7 7200 120 6.59 1.06 1997 ST136403LC 36.400 30.80 6.85 10016 167 4.58 0.85 1999 ST173404LC 73.400 44.20 6.85 10033 167 2.28 0.60 2002 ST3146707LC 146.800 82.25 5.3 10008 167 1.14 0.56 2004 ST3300007LC 300.000 88.50 5.3 10008 167 0.56 0.29
36. SATA Disk Technologie • Aktuelle SATA Platten bis 1.5 / 2 TB: – 7200 RPM=> 120 Umdrehungen pro Sekunde=> 120 Positionierungen (ohne I/O)< 120 IOs – In der Regel: 60-80 realistische IOs – Beispiel • NFS Service mit 150000 random reads pro Minute – 2500 IOs pro Sekunde – => 2500 / 60 ~ 42 Platten mindestens!Eher mehr um bessere Latency zu bekommen ( x 2 ! ) • Der Cache hilft, nur – Er muss gross genug sein – Er muss gefüllt sein (kann dauern)
37. Random Writes bei ZFS • Können durch Logzilla abgefangen werden – Wie Cache bei HDS/EMC • Mit logbias=throughput besser bei ganz vielen Platten • ZFS sammelt random writes – Schreibt mit wenigen sequential writes – In Beispielkonfigurationen: 4-fache IO (random write)
38. ZFS: Eine Zauberwelt, ohne Probleme? • Random reads => Lesecache anpassen – Mit Datenbanken: besser Cache der Datenbank erhöhen • Sequential read, wenn sequentiell gelesen: ok • Random writes => Logzilla hilft mit ZFS • Sonderfall: random schreiben, sequentiell lesen – Prefetch im ZFS hilft (genug IOs notwendig) – Bei Datenbanken: Anpassung der Queries – Danke!