Bei einem Update auf enaio 64 Bit erhöhen wir aktuell die Queues auf den Applikationsservern. Hierbei ist uns aufgefallen, dass die Gesamtpoolgröße nicht höher als 64 gesetzt werden kann.
Nach einer Beobachtung des Servermonitors werden tatsächlich auch nicht mehr als 64 Queues geladen.
Gibt es hierfür eine einfache Lösung?
Hallo @danielstraub, ich hatte das bisher nicht als Problem gesehen, da ich diese Verbindung immer primär für die DBPipes der Rich-Clients verbucht hatte, aber natürlich kann dieser von Dir festgestellte Maximalwert bei steigender Anzahl von Job-Threads ein limitierender Faktor sein.
Die Anleitung von 9.10 spricht übrigens aktuell von 128 anstelle von 64 als Maximalzahl:
Das kann ich aber spontan nicht bestätigen:
Da es sich um Einträge in der Registry handelt, ist es natürlich möglich, dass dieser Wert dort künstlich auf 128 oder auch mehr gesetzt werden könnte, was dann aber sicherlich nicht „unter Garantie“ läuft.
@danielstraub Kannst du mal bei OS nachfragen wie es ist?
@danielstraub Bei dieser Pool Grösse geht es nur um die Anzahl DB Connections, oder? Wenn du die Anzahl Threads für verschiedene Namespaces erhöhen willst, dann geht es eher um den Bereich Queues, oder?
Das Ganze es aber ein recht komplexes Thema. Vielleicht kann dir hier OS ein Info liefern wie die einzelnen Werte zusammenhängen.
Welche API Calls sind bei euch besonders ausgelastet?
DMS wegen grosser Importer / Exporter Aktivitäten?
Die jeweiligen Engines sind dann den Queues zugewiesen.
Wenn sich der Eintrag tatsächlich nur auf die DB-Connections beschränkt dann reicht uns 64 aus. Die restlichen Queues haben wir entsprechend unserer Bedürfnisse erhöht.
Ich bin trotzdem sehr gespannt, ob mit einer höheren 9.10-SP-Version oder mit 10.0 der Wert auf 128 oder höher gesetzt werden kann.
Wir haben hier heute im Rahmen eines Kundenprojekts (enaio 9.10) etwas Input erhalten. Ich kopiere der Einfachheit halber den Artikel, den ich für unser internes Dokumentatitonssystem geschrieben habe.
Nach Update des enaio Servers auf 64-bit können die Queues entsprechend erhöht werden, da effektiv mehr Ressourcen (RAM) verwendet werden können. Diese sollten auf dem System also auch dementsprechend zur Verfügung stehen.
In der Praxis können die Queues allerdings nur bis zur max. Poolgröße der Job-Threads erhöht werden. Diese ist auf 64 begrenzt. Hierbei handelt es sich um einen bewussten Wert seitens OPTIMAL SYSTEMS.
Insofern können die Queues nicht einfach alle verdoppelt oder sogar vervierfacht werden, da man ansonsten leicht über die Gesamtanzahl von 64 kommt. Die Summe der einzelnen Queues (in der Rechnung werden die Workflow-Queues doppelt gezählt) darf nicht höher sein als der max. Wert von 64.
Es kann daher eine Erhöhung der Queues in folgender Form stattfinden:
Somit könnte eine Konfiguration so aussehen:
Wichtig ist, dass die Summe der einzelnen Queues (Workflow x 2) den Maximalwert von 64 nicht übersteigt. Im o.g. Beispiel im Screenshot ergäbe sich folgende Summe:
6 + 8 + 8 +1 + 16 + 4 + 1 + 8 + (6 x 2) = 64
Umgekehrt darf der Maximalwert nicht einfach pauschal auf 64 gestellt werden, wenn die Summe der einzelnen Queues weniger als 64 ergibt!
Vielen Dank Benjamin für die ausführliche Beschreibung.
Hast du eine Info erhalten, warum die maximale Anzahl auf 64 begrenzt ist?
Hallo @uw, nein - die genauen Hintergründe waren nicht bekannt. Aber dass es Gründe gibt, wurde klar kommuniziert.
