Problem - Konfiguration oder Anwendung?

Ich bin mir relativ sicher, dass es an den Triggern liegt.

In wie weit man das aber wirklich verbessern kann, kann ich so auf die Schnelle nicht sagen, dazu müsste man sich die Trigger mal genauer ansehen. Die vielen FOR loops sind auf jeden Fall schon mal eher zweifelhaft. Was die Funktionen genau machen, und ob man das optimieren kann, ist natürlich ohne den Code gar nicht zu sagen. Auffällig ist jedenfalls, dass die Trigger in SQLite deutlich weniger machen (und die Funktionen dort ja gar nicht existieren)

Nicht wirklich. Das Resultat der Funktion(en) muss so lange im Speicher gehalten werden wie die Trigger läuft. Danach wird der Speicher automatisch freigegeben.

Danke für Deine Hilfe.
Mal gucken, ich habe jetzt den Entwickler angeschrieben. Vermutlich kommt zwar “ja nee es ist alles super”, aber vielleicht wird es sich das konkrete Szenario doch anschauen.

Moin,
ich habe den Entwickler angeschrieben und auch eine Antwort bekommen. Er sieht keine Probleme mit seinen Triggern und For loops. In dem Zusammenhang meint er die Anwendung wurde etwas anders arbeiten als man es mit reinem auslesen der Datenbank vermuten lässt.

Weiter meinte er, es ist eher ein Problem von dem bei mir darunterliegendem Linux als mit der Datenbank und hat mir auch einen Link geschickt. Es geht dabei um das Out-Of-Memory wie schon Ihr beide es gemacht habt.

Was mir dabei überhaupt nicht klar ist, sind die Werte/ befehle mit “sysctl”, besonders die ersten 2.
Mein System liefert

cat /proc/sys/kernel/shmmax
18446744073692774399
cat /proc/sys/kernel/shmall
18446744073692774399

also doch viele größere Werte als es mit den Befehlen gesetzt werden. Erlaubt also Linux zu viel, weil es nun mal deutlich mehr als die 19GB bzw. 4MB die gesetzt werden?
(Zumal in der PostgreSQL Dokumentation zu Version 14 lese ich, dass die Standardwerte die neueres Linux Kernel liefert völlig OK sind , zumindest wenn man wie bei mir “dynamic_shared_memory_type = posix” stehen hat.

Nach seiner Aussage unter Windows hätte ich keine Probleme mit meiner Konfiguration und seiner Anwendung. Leider testen kann ich es nicht, Es wäre zumindest mit sehr großen Aufwand verbunden.

Es scheint ein unlösbares Problem zu sein.
Stelle ich bei der Linux VM den Parameter ein: “vm.overcommit_memory=2” wird nicht mehr der ganze Server wegen OOM abgeschossen , sondern einige Verbindungen der Anwendung.
Manchmal macht sich die Anwendung nichts draus. Manchmal zeigt die es schon als Fehler.

Ein versucht PostgreSQL auf einer Windows Server 2019 VM zu installieren brachte für mich auch auch keine Neue Erkenntnisse. SO bald eine Verbindung zwischen der Anwendung und Server steht und Daten fließen sollen, geht die CPU Last auf allen 8 Kernen auf dem Server auf 100% und alles geht unbrauchbar langsam.
Woran das liegt/ liegen kann habe ich auch nicht herausgefunden.
Irgendwo im Netz allerdings in Bezug auf PostgreSQL 9.x habe ich was von Problemen gelesen, wenn die Kodierung auf UTF8 steht. Der Server selbst hat zwar die Einstellung Windows1252 (oder so ähnlich) aber die Datenbank der Anwendung ist UTF8. Ob das das Problem sein kann… K.A

Dieses Thema wurde automatisch 60 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.