---

Ich wende mich nun schon relativ frustriert an Euch, und hoffe jemand kann DEN Tipp geben, der mir das Leben massivst erleichtert.

Wir haben wie im Titel schon zu lesen ist 9.1 (M030) im Einsatz, und das auf mehreren Standorten (Österreich, Deutschland, Holland... und ab März 2012 gehen wir auch in Brasilien Live).

Leider bekommen unsere User immer wieder, und das nicht zu selten die Meldung "Server nicht verfügbar, wollen Sie offline weiter arbeiten". Diese Meldung erscheint immer dann, nachdem ProE quasi einfriert, und das dann manchmal auch ohne Grund. Sobald ProE dann wieder reagiert, erscheint diese Meldung. Da zu diesem Zeitpunkt die Verbindung scheinbar wieder vorhanden ist, kann nach einem klick auf "NEIN" normal weiter gearbeitet werden, als ob nichts war.

Wir haben nun schon die komplette Infrastruktur durchgeforstet, die Leitungen getestet usw. Leider hat sich bislang keine Besserung erzielen lassen. Mir ist hier ein Thread ins Auge gestochen, wonach dieser Fehler aus 8.0 scheinbar bekannt war/ist und durch diverse CONFIG's im zB Apache gefixed wurde. Ich habe mir diesen Wert rein interessehalber nun auch angesehen, und testweise mal angepasst. (KeepAliveTimeout).

Hat noch jemand mit diesem Phänomen zu kämpfen, oder bleibt mir nichts anderes über, als den Kampf gegen die Windmühlen alleine weiter zu kämpfen? 

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

---

Hallo stanztho

am Montag, 2.1.2012 wird sich ein Kollege bei Dir/Ihnen melden.

Guten Rutsch
tbauer

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

---

Zitat:

---

Original erstellt von stanztho:
Hat noch jemand mit diesem Phänomen zu kämpfen

---

Ja, wir. Betrifft bei uns am häufigsten unsere PDMLink-Nutzer in Übersee. Läßt sich nach unserer bisherigen Erfahrung etwas abmildern durch das Hochsetzen bestimmter Time-Out-Werte in der Konfiguration des Methodenservers. Unser Dienstleister hat damit für die User an unserem Heimatstandort in Deutschland eine spürbare Verbesserung erreicht, insbesondere, was das Einfrieren von Pro/E betrifft.

Für die User in Übersee läßt sich dieses Problem letztendlich aber nur durch eine performantere und stabilere Netzwerkverbindung zwischen Clientrechnern und Servern beheben.

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

---

Nachtrag:

Schaut mal in Eure Methodenserver-Log-Files, ob dort folgende Fehlermeldung auftaucht:

ERROR [SimpleTaskDispatcher7] wt.adapter.exception - exception
java.net.SocketException: Software caused connection abort: socket write error

In diesem Fall könnte das Anpassen folgender Windchill-Optionen helfen:

com.ptc.windchill.cadx.chunk_size
wt.pom.mindbconnections

Die Option com.ptc.windchill.cadx.chunk_size steht in der wt.properties, die Option wt.pom.mindbconnections steht in der db.properties.

Empfehlungen für die einzustellenden Werte findest Du hier:
http://www.ptc.com/WCMS/files/112455/en/WCConfigAssistantInstalUsage.pdf

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

---

Hallo, und nun erst mal "PROSIT" und Alles Gute im neuen Jahr! Urlaub vorbei, jetzt gehts weiter mit Fehlersuche.

Diese Meldung taucht in der Tat wie folgt auf:
=====================================================
2012-01-09 09:53:21,390 ERROR [SimpleTaskDispatcher7] wt.adapter.exception - response write error
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at com.infoengine.soap.util.ChunkedOutputStream.flush(ChunkedOutputStream.java:96)
at com.infoengine.soap.util.ChunkedOutputStream.close(ChunkedOutputStream.java:73)
at com.ptc.core.adapter.server.impl.SimpleTaskDispatcher$ServiceThread.processRequest(SimpleTaskDispatcher.java:1149)
at com.ptc.core.adapter.server.impl.SimpleTaskDispatcher$ServiceThread.run(SimpleTaskDispatcher.java:532)
=====================================================

In Anbetracht dessen, dass ich die Windchill-Logs grad nur Tagesaktuell zu verfügung habe (Neustart täglich am 4Uhr morgens), bin ich "froh" das rein zufällig der Fehler gegen 9:53 aufgetaucht ist.

Ich finde nur leider weder den Wert in der wt.properties nicht (com.ptc.windchill.cadx.chunk_size) 

MinDBConnections ist auf 15 gesetzt, wie es auch in deinem angehängten Dokument "empfohlen" wird. Welchen Wert verwendest Du, wenn ich das so direkt fragen darf? Würde ein hochsetzen auf 20 Besserung bringen? Könnte ich mir schon vorstellen... man weiß ja nie  

Und meintest du mit "bestimmte Time-Outs" aus deinem ersten Post diese Werte, oder gabs da noch andere, die bei Dir Besserung gebracht haben?

[Diese Nachricht wurde von stanztho am 09. Jan. 2012 editiert.]

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

---

Zitat:

---

Original erstellt von stanztho:
Diese Meldung taucht in der Tat wie folgt auf:
=====================================================
2012-01-09 09:53:21,390 ERROR [SimpleTaskDispatcher7] wt.adapter.exception - response write error
java.net.SocketException: Software caused connection abort: socket write error

---

Dann liegt die Ursache für Eure Probleme eindeutig in einer instabilen oder nicht ausreichend performanten Netzwerkverbindung.

Wie schon geschrieben: Abmildern könnt Ihr das möglicherweise mittels der beiden genannten Optionen. Welche Werte für Euch zu empfehlen sind, läßt sich von außen nicht abschätzen, das hängt von der Größe Eurer Datenbank, Eurer Nutzerzahl, Eure Serverhardware und dem Netzwerkdurchsatz ab.

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

---

Hi Callahan,

danke erstmal für die Hilfe. Es ist nun aber so, dass wir klarerweise auch schon mit unserer Infrastrukturmannschaft einen ausführlichen Check der Performance/Leitung durchgeführt haben. Die Jungs schwören aber Bein und Stein, dass die Leitung vollkommen ok ist. Ich hab mir die Werte (mit Wireshark ermittelt) angesehen, und die Geschwindigkeit ist absolut ok und sieht gut aus. Auch 100MB Testfiles udgl. wurden im Netz in guter Zeit geöffnet/ausgecheckt.

Wie können wir unser Netzwerk in diese Richtung noch weiter überprüfen? Was würdest du mir raten? Ich bin was Infrastruktur angeht hald auch ein wenig an die entsprechende Abteilung ausgeliefert und muss glauben, dass alles Eitel-Wonne ist...  
BTW: Auch Hausintern treten "Server nicht verfügbar" Meldungen auf. Prozentuell keineswegs so häufig wie auf dem Standort in Deutschland, aber trotzdem...

Achja, nochwas: Die Meldung des SimpleTaskDispatcher7 tritt sehr sehr selten auf. Also vl. max. 3 mal pro Tag. Ich kann derzeit nicht sagen, ob zeitgleich dazu auch jemand diese Fehlermeldung erhält. Wesentlich öfter erscheint jedoch "ERROR [SimpleTaskDispatcher7] com.ptc.windchill.uwgm.proesrv.cache.AddToWorkspaceInstructionCacheAdapter".. obs was damit zu tun hat weiß ich allerdings nicht.

Noch was zu den Fakten:
- Oracle Datenbank (~40-50GB)
- ~60 User (52 in Ö, 8 in D ... zukünftig noch eine Hand voll weitere in Brasilien und Holland)
- Server laufen virtuell (Win Server 2003) - auch das soll angeblich keine Performanceprobleme mit sich bringen

[Diese Nachricht wurde von stanztho am 10. Jan. 2012 editiert.]

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

---

Hi stanztho,

wir hatten auch mal das Problem, dass in der Pro/E Sitzung die Verbindung zu PDMLink abgebrochen und Pro/E danach sogar eingefroren ist. Wir haben das mit folgendem Ansatz gelöst:

Pro/E und das integrierte PDMLink müssen sich den verfügbaren Hauptspeicher (bei 32bit PCs sind das max. 3GB) teilen.
Ist der verfügbare Hauptspeicher durch geladene Modelle aufgebraucht, kann keine Kommunikation mit dem PDMLink Server  mehr stattfinden - die Verbindung bricht ab.
Bei den Konfigurationseinstellungen muss ein Kompromiss zwischen Arbeitsgeschwindigkeit und Stabilität der PDMLink Verbindung mit Pro/E gefunden werden.

Folgende Einstellungen haben sich bei uns bewährt:
config.pro:
dm_network_request_size (z.B. 100000)
dm_network_threads (z.B. 2)
dm_offline_after_event no
Umgebungsvariable:
uwgm_background no
Server:
KeepAliveTimeout (z.B. 30)
nokeepalive ssl-unclean-shutdown

Die konkreten Einstellungswerte hängen natürlich von Eurer Umgebung ab, aber das sind die Schrauben, an denen man drehen kann ...

Wünsche viel Erfolg!

Gruß Marianne

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

---

Bei uns sind 64bit mit 8GB Standard. Arbeitsspeicher kann dann wohl eher nicht der Grund sein oder?

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

---

Nein, dann ist Arbeitsspeicher wohl nicht der Grund ...
Dann kannst Du die Optionen für die config.pro schon mal igorieren. Außer vielleicht dm_offline_after_event.
Die Server-Einstellungen solltest Du dir aber trotzdem anschauen.

Gruß Marianne

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

---

Ich sollte noch erwähnen, dass ich in der Apache-Config (http-default) den Wert KeepAliveTimeOut erhöht habe. Hier gab es in PDM-Link 8 einen von PTC erkannten Bug, der mich mal auf diesen Wert aufmerksam gemacht hat. Seit dem sind keine Meldungen ("Server nicht verfügbar") mehr von User gemeldet werden (Ticket/Report-System).

Ich werde Euch auf dem Laufenden halten, ob und in welcher Form sich hier nun was am System verändert/verbessert hat.

Dann drücke ich mir mal selbst die Daumen 

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

---

Nun denn... Scheinbar ist der Fehler nun doch wieder aufgetreten, und nur nicht gemeldet worden 

Nochmal kurze Frage @Marianne:
Wenn du schreibst es kann Probleme mit dem Speicher geben, wäre dann auch die Auslagerungsdatei denkbar? Wir haben diese (mMn LEIDER) standardmäßig aktiviert (2-4GB). Macht es Sinn diese zu Testzwecken vl. mal zu deaktivieren?

Danke für Eure geschätzten Meinungen und Hilfe.

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

---

Hallo stanztho,

zum Thema Auslagerungsdateien habe ich leider gar keine Erfahrung. Ich weiß nicht mal, was bei uns eingestellt ist.

Gruß Marianne

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

---

Weiss nicht ob dieses Thema noch aktuell ist:

Wir hatten dieses Verhalten während der Testphase auch.
Bei uns war es die Proxy-Konfiguration des IE (.pac-Datei)
Hier mussten wir den Server angeben und siehe da die Meldungen waren verschwunden mit verbesserter Performance.

Gruß

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

---

Guten Morgen,

das Thema ist leider nach wie vor aktuell. Doch die Proxyeinstellungen (auch das .pac-File) sind bereits überprüft worden, und arbeiten korrekt. Die Zugriffe funktionieren korrekt. Danke aber trotzdem für den hint.

So langsam wird es mühsam, da beim besten Willen kein Muster für diese Meldung erkennbar ist... 

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

---

Und was sagt der Support Eures Dienstleisters? Der schrieb doch etwas weiter oben in diesem Thread, sich schon am 2. Januar um das Problem kümmern zu wollen. Allzu weit scheint er damit ja wohl noch nicht gekommen zu sein.

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

---

Wir loggen derzeit ProE mit und das Ganze ist ein Call bei PTC. Wirklich weiter kommen wir aber nicht.

Kurzfristig sah es so aus, als ob eventuell ein Userprofilkonflikt zwischen den verschiedenen Standorten der Fehler sein könnte, aber wirklich reproduzierbar ist auch das leider nicht.

Zur Info: Es ist eine 2Mbit Leitung im Einsatz und ein File- bzw. Replikationsserver ist ebenfalls vorhanden. Dieser arbeitet sauber und die Reaktionszeiten beim Öffnen von Baugruppen konnte auch verbessert werden. Hin und wieder hat Windchill aber böse Ruckler/Hänger, die dann häufig mit dieser - Server nicht verfügbar Meldung - "ausgeschmückt" werden.
Einfachste Windchillkommandos (wechseln in den Workspace; Suchen von Nummern; usw...) führen zu teils extremen Wartezeiten oder zum kompletten Einfrieren.

Seltsam: Wenn die Bandbreite bewusst voll belegt wird, wird Windchill träge --> ok, ist auch legitim. QoS regelt das mittlerweile recht brav. Aber selbst bei minimaler Auslastung der Bandbreite (20%) kommt es zu diesen Aussetzern.

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

---

Nach längerer Abwesenheit würde ich euch gerne ein Feedback der neuen Situation geben.

Nach ewiger Suche, und schlussendlicher Eskalation bei PTC wurden uns diverse Tipps und Einstellungen genannt, anhand welcher wir die Performance in den Griff bekommen können.

1. Änderung der Oracle Datenbank: Speichererhöhung der Prozesse. Wir belasten den Server jetzt beinahe Richtung Maximum. Was bedeutet, 30 von 32GB des Arbeitsspeicher sind für die Prozesse vorbelegt. --> läuft stabil und bislang unauffällig

2. Änderung der Windchill-Konfig: Der KeepAliveTimeout (Apache), welchen ich bereits vor Monaten gefixt habe, und so auch an unseren Support weitergeleitet habe, wurde nun auf Anraten von PTC nochmals angegriffen (vom Support). Scheinbar gibts den Wert in einer weiteren konfig nochmal, die ich nicht kannte (und mir leider bis dato auch nicht genannt wurde). Ich habe vermutlich an der falschen Stelle adaptiert, und wurde vom Support eher "belächelt" als "geholfen" 

Fazit: Derzeit läufts (relativ) rund, und die "Offline"-Meldung ist FAST zu Gänze verschwunden! Im Endeffekt hab ich trotz damalig noch sehr wenig Erfahrung immerhin in die richtige Richtung gedacht und hätte den Fehler eigentlich sogar fast selbst behoben 

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