bobo-0815
Goto Top

IIS 6.0 Prozessverwaltung produziert Speicherleichen

Auf meinem Windows 2003 (x64) Server läuft ein IIS 6.0 im 32-Bit-Modus. Er läuft deshalb im 32-Bit-Modus, weil ich PHP nutze und dies mit Isapi eingebunden habe. Der IIS 6.0 Anwendungspool ist mit den Standardberechtigungen konfiguriert. D. h. der Anwendungspool wird mit dem User „NETWORK SERVICE“ ausgeführt.

Nach dem Auftreten der Ereignisse unterhalb habe ich einen gestorbenen w3wp.exe-Prozess, der mit 67,932K den Speicher belegt. Ich kann diesen Prozess als Administrator nicht beenden und auch der IIS 6.0 selber schafft es nicht.

Nur mit einem Neustart bekomme ich den Speicher wieder frei.

- Ich frage mich warum der IIS 6.0 es nicht schafft die Worker ordnungsgemäß zu Recyclen?
- Liegt es vielleicht am NETWORK SERVICE und seinen eingeschränkten Berechtigungen?
- Warum kann ich mit dem Administrator-Account den Prozess nicht beenden?
- Warum stirbt nur einer der 3 Worker und bleibt im Speicher hängen?

Es müssten 4 w3wp.exe-Prozesse laufen 1x für den DefaultAppPool und 3x für xxxxxxxxxxxxx.de.

078f2b354f507ef1e71deb468f27a320-unbenannt-1


9:57:08 AM / W3SVC / Event-ID 1077
Ein Arbeitsprozess mit Prozesskennung "63976" für Anwendungspool "xxxxxxxxxxxxx.de" hat eine Wiederverwendung angefordert, da dessen virtuelles Arbeitsspeicherlimit überschritten wurde.

9:57:46 AM / W3SVC / Event-ID 1077
Ein Arbeitsprozess mit Prozesskennung "65104" für Anwendungspool "xxxxxxxxxxxxx.de" hat eine Wiederverwendung angefordert, da dessen virtuelles Arbeitsspeicherlimit überschritten wurde.

9:58:04 AM / W3SVC / Event-ID 1077
Ein Arbeitsprozess mit Prozesskennung "50788" für Anwendungspool "xxxxxxxxxxxxx.de" hat eine Wiederverwendung angefordert, da dessen virtuelles Arbeitsspeicherlimit überschritten wurde.

9:58:14 AM / Application Popup / Event-ID 26
Anwendungspopup: w3wp.exe - Application Error: The exception unknown software exception (0xc0000005) occurred in the application at location 0x031b92c6.
Click on OK to terminate the program

9:58:36 AM / W3SVC / Event-ID 1013
Bei einem Prozess für Anwendungspool "xxxxxxxxxxxxx.de" hat während des Herunterfahrens ein Zeitlimit überschritten. Die Prozesskennung lautet "63976".

9:59:15 AM / W3SVC / Event-ID 1013
Bei einem Prozess für Anwendungspool "xxxxxxxxxxxxx.de " hat während des Herunterfahrens ein Zeitlimit überschritten. Die Prozesskennung lautet "65104".

9:59:35 AM / W3SVC / Event-ID 1013
Bei einem Prozess für Anwendungspool "xxxxxxxxxxxxx.de" hat während des Herunterfahrens ein Zeitlimit überschritten. Die Prozesskennung lautet "50788".

9:59:48 AM / W3SVC / Event-ID 1000
Ein Prozess für Anwendungspool "xxxxxxxxxxxxx.de" konnte nicht auf einen Ping reagieren. Die Prozesskennung lautet "48400".

10:01:47 AM / W3SVC / Event-ID 1077
Ein Arbeitsprozess mit Prozesskennung "48752" für Anwendungspool "xxxxxxxxxxxxx.de " hat eine Wiederverwendung angefordert, da dessen virtuelles Arbeitsspeicherlimit überschritten wurde.

10:03:17 AM / W3SVC / Event-ID 1013
Bei einem Prozess für Anwendungspool "xxxxxxxxxxxxx.de" hat während des Herunterfahrens ein Zeitlimit überschritten. Die Prozesskennung lautet "48752".

10:13:07 AM / W3SVC / Event-ID 1011
Bei einem Prozess für Anwendungspool "DefaultAppPool" ist ein schwerwiegender Kommunikationsfehler mit dem WWW-Publishingdienst aufgetreten. Die Prozesskennung lautet "36820". Die Fehlernummer steht im Datenfeld.

Im 10-20 min Takt folgen pro Worker (3x) 1077 für den AppPool -> xxxxxxxxxxxxx.de und anschliessend pro Worker 1013.

Vielleicht fällt jemandem ein Konfigurationsfehler auf, nach dem Problem hab ich jetzt schon ein paar Tage gegoogelt, und bin meistens nur über irgendwelche Umwege auf die Standard-MSDN-Guides gestoßen die eine absolut schlicht gehaltene Anleitung zur Konfiguration eines IIS liefern.

Wäre für Tipps, woran es liegen könnte, Dankbar.

MfG

Bobo

Content-Key: 99238

Url: https://administrator.de/contentid/99238

Printed on: April 26, 2024 at 16:04 o'clock

Member: bobo-0815
bobo-0815 Oct 15, 2008 at 09:37:11 (UTC)
Goto Top
Update:

Das ganze schaukelt sich mit der Zeit so auf, dass erst einer, dann zwei, dann drei, ... Prozesse als Leichen im Speicher rumhängen. Bis der Server im Laufe des Tages komplett den Geist aufgibt, weil die normalen Dienste nicht mehr in den Speicher schreiben können.