Mehr

Wie werden verwaiste gsrvr.exe-Prozesse erstellt?

Wie werden verwaiste gsrvr.exe-Prozesse erstellt?


Ich habe gerade einen Server mit SDE-Anwendungsserver 10.1 gegen eine Oracle 11g-Datenbank geerbt. Ich stelle fest, dass viele Verbindungen nicht richtig abgebrochen werden und als Waisen bleiben. Schließlich ist die Anzahl der Oracle-Verbindungen erschöpft und neue Benutzer können keine Verbindung herstellen.

sdemon -o info -I Benutzer

zeigt nur eine Handvoll gültiger Verbindungen an aber Der Windows-Task-Manager zeigt viele Hunderte von gsrvr.exe-Prozessen an und die Oracles v$session-Tabelle zeigt auch viele Hunderte von Verbindungen an, die meisten mit dem Status "killed". Die einzige Möglichkeit, diese Sitzungen tatsächlich zu entfernen, besteht darin, den entsprechenden gsrvr.exe-Prozess im Task-Manager zu beenden. Dadurch wird die v$session-Tabelle gelöscht und es können neue Benutzer eine Verbindung herstellen.

Meine Frage ist also, wie diese Waisenkinder erzeugt werden und wie ich das verhindern kann. Gibt es auch eine automatisierte Möglichkeit, dann zu töten, anstatt manuell über den Windows-Task-Manager zu gehen?


Esri verfügt über zwei Mechanismen zum Herstellen von Datenbankverbindungen, die in die ArcSDE 'C'-API eingebettet sind. Das erste (ursprüngliche) Protokoll verwendet einen Anwendungsserverprozess (giomgr), der normalerweise auf dem Datenbankserver ausgeführt wird, um Netzwerkverbindungen zu akzeptieren, und überlässt die Verbindung dann einem untergeordneten (gsrvr) Prozess, um die Datenbankinteraktion im Namen des Clients zu verwalten. Das Anwendungsserver-Paradigma ist zwar effizient in Bezug auf die Netzwerklast, hat jedoch seine Fehler:

  • Es erhöht die CPU- und RAM-Auslastung auf dem Datenbankserver
  • Es erhöht die Lizenzkosten, wenn es nicht auf dem ArcGIS Server-Host ausgeführt wird (und die CPU-Last, wenn es auf dem AGS-Server ausgeführt wird).
  • Es unterliegt vorübergehenden Ereignissen, die dazu führen, dass der Dienstprozess hängen bleibt und verwaiste Sitzungen erstellt

ArcSDE hatte schon immer die Möglichkeit, laufende Sitzungen zu beenden (mitsdemon -o kill) und hat die Option, TCPKEEPALIVE zu aktivieren (was ein irreführender Name ist, da es dazu dient, abgestorbene Netzwerksitzungen zu lokalisieren, hauptsächlich durch Erhöhung des Datenverkehrs [es "geschwätzig], so dass stille Sitzungen beendet werden können), aber verwaist" Sitzungen können sich im Laufe der Zeit immer noch ansammeln. Ein Neustart des Anwendungsservers löscht die angesammelten Sitzungen, wird aber auch beendet alle aktive Sitzungen, daher ist es nicht in allen Umgebungen verfügbar.

Das neuere (und jetzt standardmäßige) Direct Connect-Protokoll verwendet genau denselben Code wie das gsrvr, bündelt es jedoch als DLL, um als separater Thread in der Client-Anwendung ausgeführt zu werden und die Datenbanklast auf die Clients zu verlagern (die viel mehr sind). leistungsfähiger als bei der ursprünglichen Veröffentlichung von Direct Connect). Die Nachteile bei der Verwendung von Direct Connect sind:

  • Administratorrechte sind für den 'SDE'-Benutzer erforderlich, um Direct Connect-Sitzungen zu beenden
  • Ältere Versionen waren im heterogenen Geodatabase-Betrieb nicht so flexibel (binärer Client stimmte nicht mit der Geodatabase-Instanz überein)
  • Die Clients müssen jeweils über eine funktionsfähige Datenbank-Client-Installation verfügen

Die meisten Datenbank-Clients sind relativ klein, aber bis vor kurzem benötigte der erforderliche Oracle-Client mindestens 500 MB. Glücklicherweise ist dies nicht mehr der Fall -- Die Installation von "Oracle Instant Client" ist in den letzten ArcGIS Desktop- und Server-Installationen enthalten und wiegt näher als 60 MB, mit einer bereitgestellten Größe von weniger als 150 MB. und Es erfordert keine Installation von "Setup.exe", sodass der Client keine Administratorrechte für die Bereitstellung auf Windows-Betriebssystemen benötigt.

Ähnlich wie der "Doctor, Doctor"-Witz ("Doctor, Doctor! Es tut weh, wenn ich es tue" Das"), lautet die Lösung für das Aufhängen von Anwendungsservern: "Tun Sie das nicht." Die Situationen, in denen verwaiste Anwendungsdienstprozesse erstellt werden, sind nicht einfach zu lösen, aber die Verwendung von Direct Connect macht das Problem strittig (wenn auch mit einer komplizierteren "Kill"-Lösung für ansonsten operative Kunden).

Auch wenn Sie eine ältere ArcGIS-Version verwenden, sollten Sie sich auch bewusst sein, dass die Verwendung von Anwendungsservern in ArcGIS 10.2 veraltet war und in ArcGIS 10.3 nicht verfügbar ist (obwohl Anwendungsserver-Client-Verbindungen mit Geodatabases vor Version 10.3 weiterhin möglich sind). Es ist wahrscheinlich ein guter Schritt, sich in die Richtung zu bewegen, die Esri in den letzten fünf großen Veröffentlichungen befürwortet hat.