---

PermGen.jpg

Hallo Windchiller,
heute morgen aufgewacht und zur Arbeit gefahren und an nichts Böses gedacht und dann  DAS  ? Weiß jemand Rat? Ein Reboot hat nichts gebracht! Das System läuft offensichtlich einwandfrei (IMHO) !? Zugriff auf Dateien + Infos ist nicht mehr möglich .
Danke

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo

löscht Ihr beim Neustart immer den Tomcat Cache?

Gruß Tabula

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nein?!
Ich habe jetzt mich etwas umgesehen. Es muß etwas mit dem Speicher zu tun haben. Hintergrund ist: Derzeit lasse ich nun weitere ausgesuchte Teilnehmer mit dem System arbeiten. Ich habe die Zahl von einer Testperson auf 10 erhöht. Danach ist der Fehler aufgetreten. Die Teilnehmer hatten die Aufgabe alle Dinge so zu machen wie Sie sie aus Intralink 3.4 gewohnt waren. Dabei sind natürlich auch viele Dinge in die Hose gegangen. Es wurden aber keinerlei Anpassungen auf dem Server veranlasst (Bis zu diesem Fehler).
Ich werde dem Hinweis jetzt nachgehen. Danke!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo   ,
ich war mal so frei und habe alles unter <LOADPOINT>\work gelöscht und siehe da, es klappt. Das Löschen geht auch anscheinend während Tomcat läuft. Er hat sich nicht beschwert. Ich werde den Cache nun zyklisch löschen   .

PS: Man muß booten, da er sonst beim Einchecken nicht mehr seinen Workspace findet.

[Diese Nachricht wurde von COMPUTERSPACE am 22. Jan. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Es könnte etwas bringen, dem Tomcat mehr Speicher zur Verfügung zu stellen, indem man das Setting "-Xmx" in der Datei "<Tomcat>\bin\<wttomcat_start>" erhöht, z.B. auf 512MB (-Xmx512M) ... oder allgemein gesagt: der System Admin sollte sich mal mit JAVA Garbage Collection befassen und die Werte dafür sowohl für Tomcat als auch für den oder die Method Server an Eure Gegebenheiten anpassen.

------------------
Genius is 99 percent perspiration and 1 percent inspiration! ... Thomas Edison

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
ich bin der Admin und war immer der Meinung, das Tomcat sich den Erfordernissen dynamisch anpasst und die GarbageCollection im Hintergrund läuft. Ich kriege auch immer eine schöne Übersicht über den Status des Servers. Da ist auch meistens alles in Ordnung nur die Antwortzeiten werden etwas länger. Eine rotes Signal bekomme ich auch nur, nachdem etwas schiefgegangen ist.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hallo
nun ist wochenende und ich kann mich nun etwas tiefgehender mit der Materie auseinandersetzten. Ich habe diese Beitrag gefunden

http://ww3.cad.de/foren/ubb/Forum70/HTML/000176.shtml

Aus diesem Artikel geht hervor, daß die Sache nicht so einfach ist, wie ich vermutet habe. Um dem PermGenMonster aus dem Weg zu gehen sind weitere Einstellungen notwendig. Diese sind

Tomcat: 1500 MB (xmx & xms)
ServerManager: 768 MB (xmx & xms)
Methodserver: 1200 MB (xmx & xms)
BackGroundMS: 1200 MB (xmx & xms).

Die Frage ist wo finde ich diese Parameter. Tomcat habe ich schon gefunden und verändert. Jedoch die drei anderen konnte ich noch nicht zuordnen. Kann mir jemand weiterhelfen, in welchen Dateien die Parameter zu finden sind? Kann man eventuell über eine Umgebungsvariable für alle Anwendungen die Heapgrößen anpassen?

[Diese Nachricht wurde von COMPUTERSPACE am 23. Jan. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Die Speichereinstellungen werden recht anschaulich im Performance Tuning Guide erklärt.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

error-java-32bit-server[1].GIF error-java-32bit[1].GIF

Hallo,
ich habe nun schrittweise die HEAPs erhöht und dann den gegenteiligen Effekt erreicht. Es war nun möglich schon bei 2 Usern Windchill aus dem Tritt zu bringen (siehe Anlage 1). Ich habe dann mal auf den taskmgr geschaut und dann festgestellt, das dieser Fehler immer bei circa 3.8Gb auftrat. Da ich den Heap in allen Bereichen immer höher wählte, kam ich automatisch immer schneller an diese Grenze. Ich habe mir dann mal die Details von Server angeschaut. Da ist mir aufgefallen das eine Komponente mit einer Java Umgebung für 32bit installiert war, was dazu führte, das man schnell an die 4.0 Gb Grenze stößt (siehe Anlage 2).

Ursache ist sicher, daß ich für eine Raid Mgr-Console eine JAVA Laufzeitumgebung brauche. Diese wurde auch brav als 32bit installiert und dann wurde noch JAVA_HOME auf diesen Ordner gelegt.

Bei der anschließenden Installation von Windchill muß auf diese Umgebungsvariable zurückgegriffen worden sein.

Ich habe nun nachträglich eine 64bit Java Umgebung zusätzlich zur 32bit und Windchill eigenen installiert und die Umgebungsvariable umgebogen und nun laufen aber andere Komponenten nicht mehr (OPENDS). Ein überbügeln der 32bit mit 64bit laufen die Anwendungen  auch nicht. Es muß wohl so sein, daß sowohl absolute als auch Umgebungsvariablen verwendet werden und das es Unterschiede in der 32bit und 64bit Version gibt.

Alle Versuche, die Installation anzupassen scheiterten. Da ich diesen Knoten sicher nicht lösen kann, weiß ich natürlich was jetzt zu tun ist und bedanke mich nochmals bei Allen für die Unterstützung.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

zwischen den Zeilen gelesen: handelt es sich um eine Testumgebung mit 10 Benutzern? Dann halte ich die Speicherwerte zu hoch.

Unabhängig davon:
Die Fehlermeldung PermGen-Space hat zwar was mit dem Heap zu tun, wird aber nicht durch die Parameter -Xms und -Xmx, sondern durch die Parameter "-XX:PermSize" und "-XX:MaxPermSize" eingestellt.
Wenn Du -Xmx=1536 hast, dann stell doch mal die MaxPermSize auf 128.

Viele Grüße,
Ruediger

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo RScholz,
du solltest meinen letzten Beitrag lesen. Das Problem für die Ausfälle lag woanders. Ich habe im übrigen RAM nachgeladen und liege jetzt bei 16Gb. Die Hälfte wird von System und Anwendung aufgefressen.

Gruß

PS: Die Testumgebung ist zwar derzeit 10 aber in Zukunft 40.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Computerspace,

ich habe deinen Beitrag gelesen, und das war auch der Grund für meine Antwort. Du schriebst:

Zitat:

---

Um dem PermGenMonster aus dem Weg zu gehen sind weitere Einstellungen notwendig. Diese sind

Tomcat: 1500 MB (xmx & xms)
ServerManager: 768 MB (xmx & xms)
Methodserver: 1200 MB (xmx & xms)
BackGroundMS: 1200 MB (xmx & xms).

---

Die Parameter -Xmx und -Xms stellen aber nicht die eigentliche Lösung für die Fehlermeldung dar. Der richtige Parameter um den PermGen-Bereich der JVM mehr Speicher zuzuweisen ist  "-XX:PermSize" bzw. "-XX:MaxPermSize". Daraufhin wollte ich eigentlich hinweisen.

Viele Grüße,
Rüdiger

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo RScholz,
vielleicht falsch angekommen. Ich gebe dir 10 Points für den Hinweis.
Danke nochmals an alle für die Antworten und den Support.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP