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.
Das mit dem Memoryverbrauch ist immer noch ein grosses Rätsel für mich.
Ausgangslage 8 CPU und 16 GB Ram, 3 workers.
Wenn ich nun auf verschiedenen Systemen mehrere Projekte gleichzeitig in den Browser lade und rein und rauszoome so wird mehr als die 16 GB alloziert und dann geht ein Teil in den Swap.
Auch wenn ich alle Browser schliesse bleibt es so. Erst mit service qgis restart wird es wieder normal. Der Swap bleibt jedoch so alloziert.
Kann das jemand mal bei sich so testen und die Beobachtung teilen?
Hallo Peter,
wie @meyerlor schon geschrieben hat, hängt der RAM-Verbrauch eigentlich nur von der Anzahl der Projekte ab.
Wieviele Projekte hast Du denn? Hast Du die alle als Preload geladen?
Das Du so schnell bei nur 3 Workers über die 16 GB kommst finde ich seltsam.
Ich habe produktiv zur Zeit auf einem Cloud-Server mit 8 vCPU und 32 GB (CCX33) 33 Projekte im Preload mit 5 Workers. Da komme ich auf eine Auslastung von 12 (von 32) GB. Im laufenden Betrieb erhöht sich diese dann nur noch geringfügig.
Ich habe nur 4 Projekte dort:
/srv/data/zuerich_1091/LK_1zu10000_vektor_zuerich_1091.qgs
/srv/data/boezen_im_wandel_der_zeit/boezen_im_wandel_der_zeit.qgs
/srv/data/boezen_im_wandel_der_zeit/boezen_flyer_vektor_min.qgs
/srv/data/Gabi/Gabi.qgs
Und am Anfang ist alles OK. Erst wenn ich diese Projekte und eines dazu lade kann ich das Beschriebene beobachten. Es hat meines Erachtens deshalb nicht mit dem Preload zu tun.
was ändert sich denn, wenn Du dieses eine zusätzliche auch mit in den preload nimmst?
Mache ich noch. Habe jedoch das preload völlig deaktiviert und dann mit dem gleichen Procedere werden max 10.5 MB RAM gebraucht.
Ich vermute, dass mit dem preload zu viele Prozesse gleichzeitig gestartet werden.
Wie ist denn dein Software-Stack auf dem Server? Läuft dein PostgreSQL auch auf der gleichen Maschine?
WIe viele Layer sind denn in deinen Projekten jeweils? Ich habe eben erst ein ziemlich komplizertes Problem debugged - habe dazu ein paar Helfer-Scripte geschrieben. Die habe ich nun auf Github veröffentlicht, vielleicht helfen sie ja auch dir, dem Problem auf die Spur zu kommen!
Die unten stehenden Beiträge wurden aus einem anderen Forenthread hier eingefügt, da diese dort Off-Topic waren und hier besser aufgehoben sind - ich hoffe das ist ok!
Auch ich möchte mich bedanken. Habe die Updates auf 3.9.2 problemlos durchgeführt. Als user www-data hat es nicht geklappt, wohl weil dieser ein spezieller User ist. Wenn dann mit root es versucht so klappt es trotzdem und auch die Rechte werden richtig gesetzt. Nur das Backup ist dann halt bei root.
Das load-test script habe ich nach einigen Problemen mit der Installation des python modules selenium zum Laufen gebracht. Habe jedoch dann eine Lösung gefunden:
"You should never install packages using sudo (in the system interpreter). That’s why it is blocking you with that error.
Use a virtual environment instead:"
python3 -m venv venv
source venv/bin/activate
pip install selenium==4.2.0
Gruss, Peter
Und - gibt es neue Erkenntnisse aus dem load-test ?
Man kann nur eine URL, also ein Projekt aufs Mal eingeben. Wenn man dann das Script auf dem Client PC (also nicht der PC auf dem Lizmap läuft) startet so geht es schon recht wild ab. Sowohl auf dem Clienten als auf dem Lizmapserver geht die CPU-Belastung sehr hoch. Das bereits allozierte Memory für py-qgis-server bleibt jedoch gleicht. Der RAM-Verbrauch geht also nicht an den Anschlag.
Was da genau gemacht wird muss ich noch herausfinden. Und ob damit eine alltägliche Lizmapbenutzersituation, mit Verschieben auf der Karte, Zoomen und Aktivieren und Deaktivieren der Layer, simuliert werden kann scheint mir zur Zeit nicht realistisch.