View Full Version : Speicherverbrauch der JVM
Hi,
unser Java Team hat mit erklärt das sie Java auf der As400 starten und dabei einen minimalen und einen maximalen Hauptspeicherverbrauch weggeben.
Was sie mir nicht beantworten konnten, war das Verhalten der JVM im Leerlauf.
Angenommen das Java Pgm hat bei der Verarbeitung sich soviel Speicher genommen, das der Max Bereich erreicht wurde.
Nun wartet es auf die nächste Aufgabe. Diese kommt ggf sofort mit ähnlich großen Anforderungen oder auch mit nur einem 10. zu verarbeitender Informationen. Schlimstenfalls hat Sie quasi Feierabend.
Was ist mit dem Speicher ? Wird er für AS400 Programme wieder frei oder ist einmal zugeordnet bis zum Jobende weg für die 'grüne' Welt.
Danke
Robi
... da gibt es zwei Einflussgrößen:
- Java seitig wird Speicher von Objekten automatisch freigegeben, auf die keine Referenzen mehr gehalten werden. (embedded Java in RPG schneidet da z.B. wg. lausiger Implementierung ganz schlecht ab!!!)
- vom Workmanagement her wird Java aus dem Hauptspeicher nach denselben Regeln verdrängt, wie andere Objekte auch (single level store).
Am Besten ist da immer mit Serverprozessen zu arbeiten (Tomcat, JBoss, WebSphere, AppServer4RPG...) und diese mit entsprechender Poolzuordnung Speicher resident zu halten.
D*B
Hi,
unser Java Team hat mit erklärt das sie Java auf der As400 starten und dabei einen minimalen und einen maximalen Hauptspeicherverbrauch weggeben.
Was sie mir nicht beantworten konnten, war das Verhalten der JVM im Leerlauf.
Angenommen das Java Pgm hat bei der Verarbeitung sich soviel Speicher genommen, das der Max Bereich erreicht wurde.
Nun wartet es auf die nächste Aufgabe. Diese kommt ggf sofort mit ähnlich großen Anforderungen oder auch mit nur einem 10. zu verarbeitender Informationen. Schlimstenfalls hat Sie quasi Feierabend.
Was ist mit dem Speicher ? Wird er für AS400 Programme wieder frei oder ist einmal zugeordnet bis zum Jobende weg für die 'grüne' Welt.
Danke
Robi
Bedeutet das, wir können beim Start als Max Wert annähernd den gesammten HSP weggeben ohne 'permannent' die anderen zu stören ? ( Das für den kurzen Moment der 'Notwendigkeit'
5250 Grün Schwarz sich extrem verlangsamt währe kein Prob.)
Robi
...letzteres würde single level store eh' verhindern. Die Frage hört sich allerdings danach an, dass die Lösung eine andere wäre...
D*B
Bedeutet das, wir können beim Start als Max Wert annähernd den gesammten HSP weggeben ohne 'permannent' die anderen zu stören ? ( Das für den kurzen Moment der 'Notwendigkeit'
5250 Grün Schwarz sich extrem verlangsamt währe kein Prob.)
Robi
holgerscherer
30-09-10, 15:34
Bedeutet das, wir können beim Start als Max Wert annähernd den gesammten HSP weggeben ohne 'permannent' die anderen zu stören ? ( Das für den kurzen Moment der 'Notwendigkeit'
5250 Grün Schwarz sich extrem verlangsamt währe kein Prob.)
Robi
Wie Dieter schon schrieb, ist das eine zweischneidige Angelegnheit. Du kannst für die JVM auch das Zehnfache des phyisch vorhandenen RAMs angeben. Die Maschine wird dann eventuell kurzfristig die Platten putzen. Wird der Speicher nicht gebraucht, kümmert sich die Speicherverwaltung schon darum, wem man wieviel RAM zuteilt.
Sollte allerdings Eure Applikation von viel RAM profitieren, ist das auch eine Design-Frage. Wenn die Maschine genügend RAM hat, um vom Dauerhaften Gebraucht die Hälfte fix abzugeben, könnte man das in einem eigenen Pool erledigen.
Aber auch hier gilt: ohne genaue Betrachtung von Anwendung und Maschine hilft nur Experimentieren. Die AS/400 hilft dabei, in dem sie demokratisch jedem genug RAM zuweist, der gerade welchen braucht. Ausserdem wird wie in einer parlamentarischen Demokratie mit Prioritäten gearbeitet (manche sind gleicher als andere), und wer unter die 5%-Hürde fällt (nur selten aufgerufen und wenig RAM benötigt) muss gelegentlich warten ;-)
-h
... wie auch von Dieter beschrieben ...
Sollte allerdings Eure Applikation von viel RAM profitieren, ist das auch eine Design-Frage.
Ist ein Excelexport mit POI das, so sagte man mir, das Excel im Speicher aufbaut.
Bei 2,7 Mio Datensätzen ist das halt viel. Der im Standart vergebene Speicher ist 'übergelaufen' (sagte die JVM).
Der Designfehler ist höchstens der Wunsch, das ins Excel zu bekommen, csv würde M.E. zur Weiterverarbeitung reichen oder besser sein.
Aber das erklär mal dem Windows Edv-ler, der deine Brötchen bezahlt.:(
schön, das die AS400 sich zurückholt, was nicht gebraucht wird.
Gruß
Robi
Ich denke, die Diskussion ist bei der AS/400 eh für die Katz:
Die JVM läuft in einem eigenen Job, der mit anderen Jobs ja nun mal nichts zu tun hat.
Eine Speicherzuordnung ist absolut überflüssig, da durch das Einspeicherkonzept der AS/400 der Speicher im RAM oder auch auf der Platte liegen kann und durch das Paging zwischen beiden hin und hergeschoben wird.
Wenn sich eine JVM eben 4GB (bei 32-Bit) Speicher genehmigen will, bekommt sie ihn auch.
Erst wenn tatsächlich auf den Speicher zugegriffen wird wird dieser eingelagert und eben anderer Speicher ggf. verdrängt.
Excel unterstützt ja erst ab Office2007 1Mio Zeilen, vorher sind's max. 65535 Zeilen.
Man muss dann wohl je 65535 Zeilen ein neues Blatt erstellen, wobei nur max. 255 Blätter unterstützt werden.
Ansonsten wirst du die Excel-Dateien mit Excel selber nie bearbeiten können.
Könnte wohl eher das Problem sein, dass ein Java-Programm in 32-Bit nur 4GB Speicher haben kann, was bei dieser Anzahl Sätzen ja durchaus nicht ausreichen kann.
Ist ein Excelexport mit POI das, so sagte man mir, das Excel im Speicher aufbaut.
Bei 2,7 Mio Datensätzen ist das halt viel. Der im Standart vergebene Speicher ist 'übergelaufen' (sagte die JVM).
Genau aus diesem Grund habe ich unsere Anwendung von POI auf JExcelAPI umgestellt. Das hat einen deutlich geringeren Speicherverbrauch und die Laufzeit ist wesentlich kürzer.
Gruß,
KM
2.7 Mio Sätze könnten auch das IFS-Limit von 4GB übersteigen (neben dem Problem, dass Excel das nie verarbeiten kann).