Ressourcengrenze überschritten

[Bitverdreher]

Hallo zusammen,

auf unserer AS/400 (V5R4M0) läuft Zend Core (Version 1.5.0) und ein Internetshop (PHP-Version 5.1.6).

In unregelmäßigen Abständen (nach ca. 9 bis 14 Tagen) erhalten wir in den Joblogs der ZendCore-Jobs (ZENDCOREAP) nach und nach die Fehlermeldung "Ressourengrenze überschritten".

Es sieht so aus, daß diese Fehlermeldung immer dann generiert wird, wenn im Internetshop versucht wird, ein SQL-Statement auszuführen.
Im Shop selbst werden dann nur noch SQL-Fehlermeldungen angezeigt. Das Zend Subsystem muß in diesem Fall immer herunter- und wieder hochgefahren werden, anschließen läuft der Shop wieder ohne Probleme.

Die ausführliche Fehlermeldung lautet:
SQL0904 Diagnose 30 10.10.07 16:39:46,523448 QSQDSCPT QSYS *STMT QSQDSCPT QSYS *STMT
Von Benutzer . . . . . . . : NOBODY
Ausgangsmodul . . . . . . . : QSQALCDS
Ausgangsprozedur . . . . . : CLEANUP
Anweisung . . . . . . . . . : 4532
Zielmodul . . . . . . . . . : QSQALCDS
Zielprozedur . . . . . . . : CLEANUP
Anweisung . . . . . . . . . : 4532
Nachricht . . . : Ressourcengrenze überschritten.
Ursache . . . . : Die Ressourcengrenze der Art 14 wurde überschritten. Der
Ursachencode ist 542. Es gibt folgende Arten von Grenzen:
( ...)
Fehlerart 14 gibt an, dass der maximal zulässige Deskriptorbereich
zugeordnet wurde. Fehlerbeseitigung: Einen der folgenden Schritte
durchführen:
( ... )
Bei Fehlerart 14 die Anzahl der zugeordneten Deskriptoren mit der Anweisung
DEALLOCATE DESCRIPTOR reduzieren.

Meine bisherigen Recherchen haben ergeben, daß DEALLOCATE DESCRIPTOR "irgendwie" mit Embedded SQL zu tun hat, allerdings verwendet die externe Firma, die den Shop programmiert, Embedded SQL überhaupt nicht.

Mich interessiert nun, was hier im Laufe der Zeit überläuft und wie man das Problem ohne ständiges Neustarten des Zend-Subsystems lösen könnte.

Danke und Grüße

[AS400.lehrling]

Hallo zusammen,

auf unserer AS/400 (V5R4M0) läuft Zend Core (Version 1.5.0) und ein Internetshop (PHP-Version 5.1.6).

In unregelmäßigen Abständen (nach ca. 9 bis 14 Tagen) erhalten wir in den Joblogs der ZendCore-Jobs (ZENDCOREAP) nach und nach die Fehlermeldung "Ressourengrenze überschritten".

Die ausführliche Fehlermeldung lautet:
SQL0904 Diagnose 30 10.10.07 16:39:46,523448 QSQDSCPT QSYS *STMT QSQDSCPT QSYS *STMT
Von Benutzer . . . . . . . : NOBODY
Ausgangsmodul . . . . . . . : QSQALCDS
Ausgangsprozedur . . . . . : CLEANUP
Anweisung . . . . . . . . . : 4532
Zielmodul . . . . . . . . . : QSQALCDS
Zielprozedur . . . . . . . : CLEANUP
Anweisung . . . . . . . . . : 4532
Nachricht . . . : Ressourcengrenze überschritten.
Ursache . . . . : Die Ressourcengrenze der Art 14 wurde überschritten. Der
Ursachencode ist 542. Es gibt folgende Arten von Grenzen:
( ...)
Fehlerart 14 gibt an, dass der maximal zulässige Deskriptorbereich
zugeordnet wurde. Fehlerbeseitigung: Einen der folgenden Schritte
durchführen:
( ... )
Bei Fehlerart 14 die Anzahl der zugeordneten Deskriptoren mit der Anweisung
DEALLOCATE DESCRIPTOR reduzieren.

Meine bisherigen Recherchen haben ergeben, daß DEALLOCATE DESCRIPTOR "irgendwie" mit Embedded SQL zu tun hat, allerdings verwendet die externe Firma, die den Shop programmiert, Embedded SQL überhaupt nicht.

Mich interessiert nun, was hier im Laufe der Zeit überläuft und wie man das Problem ohne ständiges Neustarten des Zend-Subsystems lösen könnte.

Danke und Grüße

Setz dich dochmal mit der Softwareschmiede zusammen die diesen Shop Programmiert hat, die sollten dir ganz klar auskumpft geben können

Gruß As400.lehrling

[TARASIK]

Hallo Bitver..,
ich denke dass mit dem Softwarehaus kannst Du Dir sparen, anbei ein Link auf ein fehlendes Ptf auf Deinem System:
IBM - SE27691 - OSP-DB-MSGSQL0904-T/QSQALCDS LONG RUNNING JOB END OF ABSTRACT

[TARASIK]

Hallo,
das Ptf wurde ersetzt durch SI28254

[Fuerchau]

Die Ursache MUSS nicht unbedingt damit behoben sein.
Die Frage ist, ob SQL-Resourcen wie interne SQL-Statements und Cursor auch wieder freigegeben werden.

Da Scriptsprachen häufig mit zusammengesetzten SQL's arbeiten, versucht der Optimizer intern den SQL mit Parametermarkern zu ersetzen.
Hierfür wird dann ein wiederverwendbares Statement generiert.
Sieht der SQL aber häufig anders aus, werden halt neue Statements erstellt.
Wo da die Grenze ist, weiß ich allerdings nicht.

Solange die SQL-Verbindung bestehen bleibt (der Job also noch aktiv ist), werden nicht benötigte Statements auch nicht mehr freigegeben.

Es sollte nach Möglichkeit immer mit Prepared-Statements und Parametermarkern gearbeitet werden, das ist allemal performanter und übersichtlicher.

Auch PHP unterstützt dies.

[Bitverdreher]

Die Ursache war die Standard-Konfiguration des Apache-Servers, die nicht auf den gleichzeitigen "Ansturm" vieler User ausgelegt war.

Wir haben in der httpd.conf MaxClients, StartServers, MaxSpareServers, KeepAliveTimeout, ServerLimit, ThreadsPerChild und MinSpareThreads auf Anraten eines Zend-Mitarbeiters geändert und alles hat prima funktioniert.