Habe nun mit dem Script es hingekriegt eine lauffähige Version als VMware Image hinzukriegen.
Es laufen jedoch nicht mehr als 4 py-qgisserver Prozesse. Kann man das ändern?
Auch werden nicht mehr als 8GB Ram verwendet obschon ich 32 GB Ram zur Verfügung habe. Wie sieht das bei euch aus?
Hallo Peter,
die Anzahl der “Workers” kannst Du in der Datei “/srv/qgis/server.conf” definieren.
Die Gesamtanzahl der Prozesse setzt sich dann wie folgt zusammen (wenn ich es richtig verstanden habe):
Main process + supervisor + controller (spawn server) + n configured workers
Ist die Frage, ob man dann für Workers z.Bsp. Anzahl der Prozessoren -3 setzt.
Mit der Speicherauslastung bin ich auch noch nicht zufrieden.
Diese hängt jedoch von der Anzahl der Workers ab. Jeder Worker bekommt eine Kopie des Speichers.
Wenn Du also z.Bsp. 16 Kerne hast und z.Zt. nur 4 Workers, dann wird bei 16 Workers auch der Speicher x 4 auf 32 hochgehen.
Wenn das zutrifft, würde ich auf jeden Fall die 3 von oben abziehen.
Bei meinen z.Zt. 8 Workers werden aktuell gut 3 von 16 GB genutzt. Ich hoffe das erhöht sich noch im Produktivbetrieb. Sollte man auf jeden Fall beobachten (z.Bsp. mit dem Befehl top oder free -h)
Schönes Wochenende und Grüße
Günter
Kurzer Zwischenbericht. Pro Worker wird etwa 4 GB verbraucht. Also mit 16 GB Speichet reicht es knapp. Wenn das RAM nicht reicht so wird der Auslagerungspeicher verwendet aber dann wird alles langsam. Wird also schwierig die ideale Konfiguration zu finden.
Das Laden der QGIS Files beim Starten ist sehr nützlich. Lorenz hat das ja gut beschrieben.
Mein Vektorlayer Projekt mit 65 Vektor Layern ist nun auch viel schneller aber das Caching funktioniert nicht über alle Zoomstufen.
Vielleicht hat Lorenz auch noch was Nützliches zu sagen?
Zum Testen kann ich Speicher bis 45 GB durchexerzieren da mein Testsystem auf einer virtuellen Machine läuft.
Nun eine weitere Frage zu py-qgisserver. Ist dies nun die finale Lösung und soll ich meine produktiven System so anpassen?
Der RAM verbrauch pro Worker hängt davon ab, wie viele Projekte du in den RAM laden willst - umso mehr einzelne Projekte du “predloadest”, umso mehr RAM pro Worker wird benötigt.
Gecached wird da erstmal noch nix - nur das Projekt eben schonmal geladen (die Zeit, die QGIS Desktop auch bräuchte ab da, wo du eine .qgz oder .qgs öffnest)
Caching läuft nach wie vor im plugin “per layer” oder via Kommandozeile und pre-seeding. - damit habe ich aber noch keine großen Erfahrungswerte - habs letzte Woche mal versucht mit einem Rasterbild (DOP 10cm) - dafür musste ich’s auf “tiled” umstellen und schneller wurde es dann trotz pre-seeding der tiles nicht. Also zumindest für Rasterbilder lohnt es sich meiner Meinung nach nicht. Das wäre mal ein spannender Diskussionthread fürs Englisch-Sprachige Forum, was so die Erfahrungen mit verschiedenen Caching-Strategien sind!
Peter, zu Deiner Frage (außerhalb dieser Beiträge) zum RAM ein paar Gedanken:
Ich vermute 32 GB sollten es langfristig schon sein. Habe aber leider immer noch keine Erfahrungen aus dem Produktivbetrieb. Für diesen hatte ich zuerst einen neuen Dedicated-Server (Hetzner AX102) installiert. Das lief gut aber es fehlt mir doch das Backup/Snapshots der Cloud-Server. Die fertige Installation regelmäßig und zusätzlich bei Bedarf zu sichern und schnell auf einen anderen Server zu übertragen hat schon was.
So habe ich den AX102 jetzt durch 2 Cloud-Server ersetzt. Zwei, da ich weiterhin das Problem habe, dass ich mit dem Py-QGIS-Server keine eigenen WMS-Dienste vom selben Server nutzen kann. Und in der Vergangenheit hat sich die Aufteilung auch aus Performancegründen bewährt.
Begonnen habe ich mit 2 CPX41. Ich denke aber, dass ich im Produktivbetrieb wegen der “Shared vCPU” mind. zu den CCX33 wechseln werden. Die haben dann 32GB und 8 Kerne. Man kann dann ja ggf. nur 5-6 Workers definieren, je nach RAM-Auslastung.
Das schöne ist, man kann es einfach testen. Nur bei der Festplattengröße muss man bleiben. Zurück auf eine kleinere geht nicht!
Mit dem Seeding (vordefineren der Kacheln) habe ich auch keine aktuellen Erfahrungen. Das habe ich früher getestet aber 2x mal ohne wirklichen Erfolg/Nutzen. Das Erstellen der Kacheln war extrem langsam und es gab dann anschließend keinen spürbaren Geschwindigkeitsvorteil. Ich hatte mir dann lieber den MapProxy installiert. Aber auch hier lohnt sich der Aufwand für einen, wenn überhaupt geringen Geschwindigkeitsvorteil meiner Meinung nach nicht. Das ist aber sicherlich individuell von den Projekten und Zugriffen abhängig.
Und - bei der Verwendung der Cloud-Server (siehe oben) wird dann ggf. auch schnell der Festplattenspeicher knapp. Wobei man die Kacheln auf eine zusätzliche Platte auslagern kann, die müssen ja nicht gesichert werden.