Autor
|
Thema: VaultServer.exe läuft auf 100% CPU (V5R18) (1401 mal gelesen)
|
Mc Daniel Mitglied Dipl. Informatiker (FH) CAD Admin
Beiträge: 5 Registriert: 25.09.2008
|
erstellt am: 29. Sep. 2008 16:15 <-- editieren / zitieren --> Unities abgeben:
Hallo SmarTeamgemeinde, Systeminfos: SMARTEAM® - Editor V5R18 Service Pack 4 Oracle DB10G Windows Server 2003 und das ganze läuft auf einem VMware ESX Server Und nun zum Problem: Wir haben eine Systemupdate von R16 auf R18 durchgeführt und dabei auch die Datenbank von Microsoft SQL2005 auf Qracle DB10G migriert. Das System läuft gerade im Test unter der Version V5R18. Die Menge der User hält sich in Grenzen (1-5 im Testbetrieb). Das System läuft, allerdings kommt es mehrmals am Tag vor, dass sich der Dienst "SmarTeam Vault Service" --> "VaultServer.exe" nahezu 100% der CPU des Servers krallt und diese auch behält bis man diese manuell restartet. In den Eventlogs sind keine nützlichen Informtionen zufinden. Virenscanner ist deaktiviert. Hat jemand schon ähnliche Erfahrungen gemacht? Evtl. Lösungsmöglichkeiten? Danke und Grüße Mc Daniel Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
RSchulz Ehrenmitglied V.I.P. h.c. Head of CAD, Content & Collaboration / IT-Manager
Beiträge: 5541 Registriert: 12.04.2007 @Work Lenovo P510 Xeon E5-1630v4 64GB DDR4 Quadro P2000 256GB PCIe SSD 512GB SSD SmarTeam V5-6 R2016 Sp04 CATIA V5-6 R2016 Sp05 E3.Series V2019 Altium Designer/Concord 19 Win 10 Pro x64
|
erstellt am: 29. Sep. 2008 16:40 <-- editieren / zitieren --> Unities abgeben: Nur für Mc Daniel
Hallo, wo liegen denn die Vault-Ordner bzw. sind diese Lokal oder im Netzwerk (per "normale" Freigabe oder I-SCSI)? Hier könnten Netzwerkprobleme oder DNS-Probleme zu dem Fehler führen. Im Falle des I-SCSI könntet ihr euch sogar damit die Datenbank zerreisen. Greifen mehrere Vault-Server auf die gleichen Ordner zu? Hier könnten gleichzeitige Zugriffe das Problem verursachen, da der eine Vault-Service nicht mit dem anderen kommuniziert. Habt ihr beide Versionen auf dem selben Server laufen? Sprich hat vielleicht die VMware ein Problem? ------------------ MFG Rick Schulz Konfuzius sprach: "Wer sich das Alte noch einmal vor Augen führt, um das Neue zu verstehen, der kann anderen ein Lehrer sein."
[Diese Nachricht wurde von RSchulz am 29. Sep. 2008 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mc Daniel Mitglied Dipl. Informatiker (FH) CAD Admin
Beiträge: 5 Registriert: 25.09.2008
|
erstellt am: 29. Sep. 2008 16:56 <-- editieren / zitieren --> Unities abgeben:
Hallo, danke für die schnelle Antwort. Die Vault-Ordner liegen Lokal auf der Maschine (physikalisch im SAN). Die Systeme Produktiv und Test sind komplett unabhänig voneinander, getrennte Datenbanken und getrennte Vaults. Es greift auch nur ein Dienst auf den Vault zu. Das einzige was die Systeme verbindet, ist der gleiche ESX Server. Grüße Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
RSchulz Ehrenmitglied V.I.P. h.c. Head of CAD, Content & Collaboration / IT-Manager
Beiträge: 5541 Registriert: 12.04.2007 @Work Lenovo P510 Xeon E5-1630v4 64GB DDR4 Quadro P2000 256GB PCIe SSD 512GB SSD SmarTeam V5-6 R2016 Sp04 CATIA V5-6 R2016 Sp05 E3.Series V2019 Altium Designer/Concord 19 Win 10 Pro x64
|
erstellt am: 29. Sep. 2008 17:07 <-- editieren / zitieren --> Unities abgeben: Nur für Mc Daniel
Hmm das klingt soweit eigentlich i.O.. Es ist natürlich schwierig aus der ferne soetwas heikles beurteilen zu können. Passiert das denn sporadisch oder bei einer bestimmten Aktion? (Datenproblem) Ist vll. immer der gleich "User" der Auslöser? (Rechteproblem) Was bedeutet Physikalisch im SAN? iSCSI ist auch physikalisch im SAN... Genau dann würde es für ein Netzwerkproblem sprechen. Dabei kann es sein, dass nur bei einem Bruchteil einer Sekunde Netzwerkausfall der Vault-Server-Service abstürzt. Im normalen Betrieb fällt das nicht auf und die anderen Services laufen auch weiter. Des weiteren ist es laut DS entscheidend, dass die Oracle DB und die SmarTeam-Services auf unterschiedlichen Servern laufen. ------------------ MFG Rick Schulz Konfuzius sprach: "Wer sich das Alte noch einmal vor Augen führt, um das Neue zu verstehen, der kann anderen ein Lehrer sein."
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mc Daniel Mitglied Dipl. Informatiker (FH) CAD Admin
Beiträge: 5 Registriert: 25.09.2008
|
erstellt am: 01. Okt. 2008 08:52 <-- editieren / zitieren --> Unities abgeben:
Danke für die Tipps, Ja, ich habe auch schon versucht Gemeinsamkeiten zwischen dem Auftreten des Fehlers und bestimmten Aktionen von Usern festzustellen. Allerdings ohne Erfolg. Das Ganze passiert auch ohne dass ein User im SmarTeam arbeitet. Wir verwenden kein iSCSI, am ESX Server hängt über FC an einer NetApp System. Wir werden die Migration jetzt noch einmal durchführen, bin gespannt ob es was bringt. Kann mir jemand sagen was der Dienst "SmarTeam Vault Service" genau macht?
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
RSchulz Ehrenmitglied V.I.P. h.c. Head of CAD, Content & Collaboration / IT-Manager
Beiträge: 5541 Registriert: 12.04.2007 @Work Lenovo P510 Xeon E5-1630v4 64GB DDR4 Quadro P2000 256GB PCIe SSD 512GB SSD SmarTeam V5-6 R2016 Sp04 CATIA V5-6 R2016 Sp05 E3.Series V2019 Altium Designer/Concord 19 Win 10 Pro x64
|
erstellt am: 01. Okt. 2008 09:02 <-- editieren / zitieren --> Unities abgeben: Nur für Mc Daniel
Hallo, im Endeffekt verwaltet dieser Dienst die Rechte und stellt die Ablageordner zur Verfügung. Sprich er Prüft, ob bestimmte Verzeichnisse wie SmTemp, Config zur Verfügung stehen und stellt die Ablageordner/Vaults zur Verfügung. ------------------ MFG Rick Schulz Konfuzius sprach: "Wer sich das Alte noch einmal vor Augen führt, um das Neue zu verstehen, der kann anderen ein Lehrer sein."
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
hugin66 Mitglied
Beiträge: 106 Registriert: 06.10.2005 Win XP, ST R16SP7
|
erstellt am: 24. Okt. 2008 14:11 <-- editieren / zitieren --> Unities abgeben: Nur für Mc Daniel
Hallo, auch wenn es nicht direkt zur Lösung beiträgt: Auf unserem Testsystem mit ST R18SP5 (WinXP SP2, SQL Express, Vaults auf der Testmaschine angelegt) tritt dieses Problem auch regelmäßig auf. Wir haben noch keinen Ansatzpunkt gefunden, warum das so ist, bleiben aber dran. ------------------ mfg, hugin66 Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mc Daniel Mitglied Dipl. Informatiker (FH) CAD Admin
Beiträge: 5 Registriert: 25.09.2008
|
erstellt am: 24. Okt. 2008 14:19 <-- editieren / zitieren --> Unities abgeben:
Hallo, danke für die Info. Wir sind bei dem Thema auch noch nicht viel weiter und stochern ein wenig im Dunkeln. Mittlerweile läuft das 3 Testsystem. Auf allen 3 Sytemen tritt der Fehler ca 24h nach Serverstart auf. Wir haben einen entsprechenden Call bei Dassault aufgemacht. Falls wir zur Lösung des Problems kommen, werde ich Sie informieren. Grüße Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Mc Daniel Mitglied Dipl. Informatiker (FH) CAD Admin
Beiträge: 5 Registriert: 25.09.2008
|
erstellt am: 10. Nov. 2008 10:24 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, so wie es ausschaut haben wir die Lösung auf das Problem gefunden. Es sieht ganz danach aus, als das der Virenscanner der Schuldige ist. Nicht der lokal installiert Client, sondern ein zentrales Tool McAffee RSD Sensor was nichts anderes macht als ein bestimmtes Netzsegment nach neuen Systeme zu scannen. Bei diesem Scan hängt sich höchst wahrscheinlich der VaultServer auf. Wir haben den McAffee RSD Sensor deaktiviert und danach trat der Fehler nicht mehr auf. Vielleicht ist es uns jetzt möglich auf R18 umzustellen Grüße
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
hugin66 Mitglied
Beiträge: 106 Registriert: 06.10.2005 Win XP, ST R16SP7
|
erstellt am: 12. Nov. 2008 18:29 <-- editieren / zitieren --> Unities abgeben: Nur für Mc Daniel
|