Geraden f\u00fcr den Typ 2 ist ein strukturiertes Vorgehen von gro\u00dfer Bedeutung. Es empfiehlt sich, ein Vorgehensmodel zu definieren und zu dokumentieren. Bei neuen Erkenntnissen wird das Vorgehensmodel erweitert oder ggf. angepasst. F\u00fcr jeden Vorgehensschritt gibt es eine konkrete Aufgabe, die verschiedene Ergebnisse liefert. Dieses Vorgehen hat mehrere Vorteile:<\/p>\n
- \n
- Es gibt einen roten Faden: Die Komplexit\u00e4t ist meist sehr hoch. Wenn man nicht strukturiert die Probleme angeht, l\u00e4uft man Gefahr, sich zu verzetteln.<\/li>\n
- Das Wissen kann besser auf mehrere Mitarbeiter verteilt werden: Sollte ein Mitarbeiter mal ausfallen (wegen Krankheit oder Urlaub) k\u00f6nnen andere Mitarbeiter diese Aufgabe \u00fcbernehmen.<\/li>\n
- Es gibt Material f\u00fcr das Management: Das Management kann sich oft nicht vorstellen, warum es so lange dauert, das Problem zu l\u00f6sen. \u00dcber das Vorgehensmodel ist gekl\u00e4rt, wo wir uns befinden, und was die n\u00e4chsten Schritte sind. \u00dcber Entscheidungsvorlagen k\u00f6nnen weitere Budgets oder Termine abgestimmt werden.<\/li>\n<\/ul>\n
Hilfreich ist es auch, Probleme und Teilerfolge im Team zu diskutieren. Dazu m\u00fcssen Vorgehen und Ergebnisse auch in entsprechender Form aufbereitet werden.<\/p>\n
Betriebskennzahlen ermitteln<\/strong><\/h3>\n
Prozess und Speicher<\/strong><\/p>\n
Im Teil 1<\/a> wurde bereits dargestellt, dass die Gr\u00f6\u00dfe des maximalen Speichers f\u00fcr einen Prozess abh\u00e4ngig von dem Betriebssystem und der Hardware ist.
\nAnzeigen kann man den Speicher f\u00fcr einen Prozess unter Linux mit dem Kommando top.<\/p>\ntop -p <PID><\/pre>\n
Weiterhin kann auch festgestellt werden, wie viel Ressourcen \u00fcberhaupt noch zur Verf\u00fcgung stehen.
\nUm herauszufinden, wie viel Speicher ein Prozess maximal einnehmen kann, ben\u00f6tigt man die genaue Kernel-Version und die Spezifikation des Betriebssystems.<\/p>\nuname -r (Linux)<\/pre>\n
- \n
- In Betriebssystemspezifikation nachlesen (z.B. bei RedHat) <\/a><\/li>\n<\/ul>\n
Red Hat Enterprise Linux 4 includes a kernel known as the hugemem kernel.
\nThis kernel supports a 4GB per-process user space (versus 3GB for the other kernels), and a 4GB direct kernel space. <\/em><\/p>\nJava-Speicherverlauf \u00fcberwachen<\/strong><\/p>\n
- \n
- GC-Logging aktivieren<\/li>\n<\/ul>\n
JAVA_VM_ARGS=\"$JAVA_VM_ARGS -verbose:gc -Xloggc:var\/logs\/gc.log \\\r\n -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC \\\r\n -XX:+PrintTenuringDistribution\"<\/pre>\n
- \n
- Auswerten der Datei
var\/logs\/gc.log<\/code> mit dem Tool HPjtune<\/li>\n<\/ul>\n![\"\"](\"http:\/\/marko-seifert.de\/blog\/wp-content\/uploads\/2012\/06\/gc-log.png\" "\\"gc-log\\"")
<\/a><\/p>\n- \n
- Kurz vor OutOfMemorykann durch GC kaum noch Speicher freigegeben werde<\/li>\n
- das Systen ist praktisch nur noch mit GC besch\u00e4ftigt<\/li>\n<\/ul>\n
Tomcat-Monitoring<\/strong>
\n\u00dcber die Tomcat-Manager-Seiten kann der Tomcat \u00fcberwacht werden. Daf\u00fcr muss ein Nutzer mit der Rollemanager<\/code> in der Dateitomcat-users.xml<\/code> existieren.<\/p>\n<?xml version='1.0' encoding='utf-8'?>\r\n<tomcat-users>\r\n...\r\n<role rolename=\"admin\"\/>\r\n<role rolename=\"manager\"\/>\r\n<user username=\"admin\" password=\"admin\" roles=\"admin, manager\"\/>\r\n...\r\n<\/tomcat-users><\/pre>\n
Tomcat Monitoring URL: http:\/\/HOST:PORT\/manager\/status?XML=true<\/a><\/p>\n
<?xml version=\"1.0\" encoding=\"utf-8\"?>\r\n<status>\r\n<jvm>\r\n<memory free='206.306.536' total='424.214.528' max='492.175.360'\/>\r\n<\/jvm>\r\n...\r\n<\/status><\/pre>\n
Grafisch ausgewertet werden k\u00f6nnen die Werte mit JMeter:<\/p>\n
![\"\"](\"http:\/\/marko-seifert.de\/blog\/wp-content\/uploads\/2012\/06\/jmeter2-1024x668.png\" "\\"jmeter2\\"")
<\/a><\/p>\nSpeicherdumps auswerten<\/strong><\/p>\n
Oft findet man die Ursachen des Speicherproblems aber nur mit der Auswertung des Heapdumps. Zuerst muss man ein Heapdump erstellen. Es empfiehlt sich, den Heap f\u00fcr die Analyse nicht zu gro\u00df zu w\u00e4hlen. Eine Analyse eines 2 GB Dumps ist schon sehr schwierig.<\/p>\n
- \n
- Histogramm\n
$JAVA_HOME\/bin\/jmap -histo <PID> > hist.txt<\/pre>\n<\/li>\n
- Binary HeapDump (komplett)\n
$JAVA_HOME\/bin\/jmap -heap:format=b <PID><\/pre>\n<\/li>\n<\/ul>\n
- \n
- Auswerten mit JHat (JDK 1.6)\n
java -Xmx2048m -jar hat.jar ..\/java_pid27280.hprof\r\nStarted HTTP server on port 7000\r\n Reading from ..\/java_pid27280.hprof...\r\n Dump file created Tue Nov 20 14:22:07 CET 2007<\/pre>\n
die Auswertung kann dann webbasiert per Browser auf Port: 7000 erfolgen<\/li>\n
- Auswerten mit dem SAP Memory Analyzer\n
- \n
- kostenloses Tool zum Analysieren von gro\u00dfen Memory Dumps<\/li>\n
- sehr schnelle (durch Indizierung)<\/li>\n
- sehr gute Analysem\u00f6glichkeiten<\/li>\n
- Bearbeitung gro\u00dfer Dumps<\/li>\n
- als Eclipse Plugin oder eigenst\u00e4ndige Applikation (RPC-Framework)<\/li>\n
- Artikel im JavaMagazin (11\/2007 S.105)<\/li>\n
- Download: https:\/\/wiki.sdn.sap.com\/wiki\/display\/Java\/Java+Memory+Analysis<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
- Auswerten mit JHat (JDK 1.6)\n
- Histogramm\n
- Auswerten der Datei
- GC-Logging aktivieren<\/li>\n<\/ul>\n
- In Betriebssystemspezifikation nachlesen (z.B. bei RedHat) <\/a><\/li>\n<\/ul>\n
![\"\"](\"http:\/\/marko-seifert.de\/blog\/wp-content\/uploads\/2012\/06\/sap-mem1-1024x710.png\" "\\"sap-mem1\\"")
<\/a><\/p>\n![\"\"](\"http:\/\/marko-seifert.de\/blog\/wp-content\/uploads\/2012\/06\/sap-mem2-1024x710.png\" "\\"sap-mem2\\"")
<\/a><\/p>\n![\"\"](\"http:\/\/marko-seifert.de\/blog\/wp-content\/uploads\/2012\/06\/sap-mem3-1024x710.png\" "\\"sap-mem3\\"")
<\/a><\/p>\n