OpenSeaMap-dev:Server Delta-alt/Analyse und Wartung

Doku der Wartungsarbeiten nach dem Crash vom Januar 2018.

Siehe auch: ToDo-Liste und Historie

2018-06-22 Thomas

• aktuelles Postgres-log( 20 GB) umbenannt / gezippt in postgresql-9.6-main_20180622.log.gz -> 1,1 GB
• VACUUM ANALYZE auf depth
• log_min_duration_statement in postgresql.conf auf 1000 zwecks Performance-Analyse (später wieder disabled)
• shared_buffers 128Mb -> 2GB
• work_mem 4MB -> 12MB

Nach obigen Operationen konnte man im Postgres-Log Statements in der Form

select "m",encode(ST_AsBinary(ST_Force2D("the_geom"),'NDR'),'hex') as geom,"id" from contoursplit where the_geom && ST_GeomFromText('POLYGON((-179.91210937501 -85.0435409456574,-179.91210937501 -0.087890615572578,-0.0878906500417799 -0.087890615572578,-0.0878906500417799 -85.0435409456574,-179.91210937501 -85.0435409456574))',find_srid('','contoursplit','the_geom'));

sehen, welche teilweise bis zu 15 Sekunden Laufzeit hatten. Parallel dazu habe ich im top immer wieder hohe Lasten durch Postgres und fastcgi gesehen.

Ein "explain analyze" bzw. auch ein "count(*)" auf obiges Statement liefert eine Größe des Resultsets von stolzen 454272 Datensätzen, die die Applikation dann irgendwie verarbeiten muß. Kein Wunder, dass da nichts mehr geht.

Wenn ich das richtig verstehe, werden da selects auf die Geometrie abgesetzt, welche die halbe Weltkugel umfassen. Ich bin kein GIS-Experte, aber das liegt mit Sicherheit nicht im Sinne des Erfinders und überfordert dann spätestens die darüberliegende Anwendung, die sicher nicht dafür gemacht ist, ein Resultset derartiger Größe zu verarbeiten.

Im catalina.out werden diverse Exceptions und jede Menge vermutliche Speicherlecks geloggt, im Postgres-Log findet man jede Menge Einträge zu abgebrochenen Client-Verbindungen. Das könnte aber eine Folge von mit der Größe der Resultsets überforderten Prozessen sein

Ein grundsätzliches Problem der Anwendung scheint zu sein, dass Fehlermeldungen nicht an den User durchgereicht werden. Beim Versuch, ein Vessel anzulegen und vor der u.g. Permission-Korrektur wurde einfach nur der Bildschirm mit einem Grauschleier überlagert und ansonsten passierte nichts.

Permissions:

• grant select, update on vesselconfiguration_id_seq to osmapi; Danach konnte ich wieder Vessels anlegen und auch einen Track hochladen.
• grant select on trackpoints_raw_8 to osmapi; (entsprechende Fehlermeldung war immer wieder im postgres-log aufgetaucht)

Log files Das Vollaufen der var-Partition habe ich jetzt erst mal händisch verhindert, aber es muss dringend ein Logrotate eingebaut werden.

Noch mal selects / resultsets

Den select auf contoursplit habe ich durch Einfügen von >>PROCESSING "NATIVE_FILTER=m in ( 1000, 2000, 5000 )"<< in /home/martin/map4sea.map ein wenig entschärft.

Wir haben aber immernoch ein Problem mit viel zu großen Resultsets. Das nachfolgende Statement wurde aus dem Postgres-Logfile gefischt:

select
	count(*)
	--"dbs",
	--encode(ST_AsBinary(ST_Force2D("the_geom"),'NDR'),'hex') as geom,
	--"gid" 
from trackpoints_raw_filter_16 
where the_geom && ST_GeomFromText('POLYGON((-82.705067384651 27.7224454127048,-82.705067384651 27.7418751333523,-82.6831161860761 27.7418751333523,-82.6831161860761 27.7224454127048,-82.705067384651 27.7224454127048))',find_srid('','trackpoints_raw_filter_16','the_geom'));

count
712725

Da werden mal eben 700.000 Geometriedatensätze an mapserv zurückgeliefert.

Sehr seltsam. Die Tabelle enthält 7,7 Mio. Datensätze. Das angefragte Rechteck ist ca. der 6*10^-9 te Teil der Erdoberfläche. Trotzdem wird fast 1/100 des Tabelleninhalts zurückgeliefert. Entweder ein sehr seltener Zufall, oder da ist etwas mit den GIS-Abfragen megafaul.

Nachtrag: Ein Blick in die Tabelle zeigt, dass in diesem Polygon tatsächlich Unmengen an Punkten vorhanden sind. Bleiben die Fragen:

• warum ist das so
• warum werden mit erstaunlicher Treffsicherheit permanent Abfragen auf so stark besetzte Gebiete ausgeführt?