Då har jag jobbat med ett väldigt specifikt typfall i QGIS som tar fruktansvärt lång tid. Jag jämför inte med någon annan lösning, men nyfikenheten om varför tog lite överhand och ”felsökningen” ledde till ett oväntat resultat.
Jag har precis startat igång en ny server, där jag kör PostGIS för alla mina klienter. Naturligtvis så ville jag ladda in Lantmäteriets terrängkarta i vektorformat, och naturligtvis ville jag ha hela Sverige med.
Detta är sammantaget massiva mängder data! Vissa lager är till och med uppdelade i regioner för att vara rimliga att hantera i leveransformatet Esri Shape. Att ladda PostGIS med dessa brukar ta tid, men jag tycker ändå att jag minimerat flaskhalsarna så gott jag kan. Det är naturligtvis inte så att jag tycker att QGIS generellt är långsamt, utan det är just den här specifika uppgiften som tyvärr tar väldigt lång tid.
Servern gör i princip bara en sak och när jag kör diagnosprogram under körningarna så ligger Ram och CPU belastningen på enstaka procent, så där verkar det inte vara några problem.
Nätverket har jag mätt upp till nära på 1 Gbit/s mellan klient och server, och trafiken ligger inte ens på 1 Mbit/s normalt under körningen, så nätverket verkar inte heller vara problemet…
Klienten är en Intel i7 med fyra kärnor (åtta trådar), SSD diskar i RAID 0 och 32 Gb Ram. Dessutom ett nVidia grafikkort med 4 Gb, även om det i sammanhanget mest är av akademisk betydelse.
När jag kör HTOP på datorn så börjar begränsningarna uppdagas.
Av åtta trådar är det bara en i taget som jobbar med QGIS och uppladdningen av data till PostGIS. Det är en begränsning jag inte kan göra mycket åt, annat än att försöka ladda upp data från flera QGIS instanser parallellt, men det hjälper inte direkt när enbart allmänna vägar är 400 Mb i ett lager och höjdkurvorna är 3,3 Gb uppdelat i tre, och så vidare.
Det finns säkert snabbare sätt att ladda PostGIS med data, exempelvis från terminalen, men detta är den grafiska metoden som de flesta säkert använder.
Nej, den riktiga flaskhalsen, som jag i alla fall teoretiskt kan göra något åt är att öka på mängden Ram. Men skall verkligen hantering av 3,3 Gb data ta upp över 20 Gb Ram?
Det är ganska tydligt att 32 Gb Ram inte är tillräckligt för denna typ av arbete. När jag avslutar en del andra processer för att frigöra ytterligare Ram så verkar dock inte QGIS suga åt sig dessa, utan ligger kvar på den minnesmängd som togs i anspråk från början. Om detta är en QGIS grej, eller något som operativsystemet reglerar vet jag inte.
Jag kan i alla fall inte dra någon annan slutsats än att det dels är ett suboptimalt utnyttjande av CPU kärnor i QGIS för den här typen av arbete, samt att oavsett hur mycket Ram du tror att du behöver när du skall skaffa en ny dator, så bör du dubbla det direkt.
Jag vet inte hur svårt det skulle vara att få QGIS att använda fler CPU kärnor för den här typen av arbete. Det är troligtvis betydligt mer komplicerat än att skicka olika processer till egna CPU kärnor och köra dessa i bakgrunden (vilket fungerar utmärkt sedan ett par versioner tillbaka).
Hur ser belastningen ut på servern som tar emot?
Kan det vara så att Qgis lägger in data med insert? Det är i så fall betydligt långsammare än om den gör det med copy. I shp2pgsql finns det en option som bestämmer vilken metod som används. Denna finns även i shp2pgsql-gui under options. Jag tror den ståt på copy som default.
Du kör väl ubuntu-baserat distro? Då skall shp2pgsql-gui finnas i repo tror jag. Tror den heter postig-gui. Så skall du få shp2pgsql-gui i program-meny
shp2pgsql samt ”gui” programmet fungerar utmärkt speciellt om det är många lager som skall laddas in, men det snabbar inte upp processen märkbart för mig. I QGIS används olika mekanismer i bakgrunden. Om man går via databashanteraren så vet jag inte exakt vad som används, men det är bättre att hitta ett processverktyg som gör motsvarande, så att inte hela QGIS gränssnittet låser sig medan bearbetningen pågår (vilket görs via databashanteraren). Då kan man nämligen starta en ny uppladdning av ännu ett vektorlager parallellt med tidigare processer. Bland verktygen finns det de som använder ogr2ogr och de som använder ren sql, där det framför allt är ”INSERT” som används. Jag känner inte till om QGIS har något verktyg inbyggt som använder ”COPY”, vilket skall vara snabbare.
Här kommer en alternativ jämförelse. Hela terrängkartan är en mastig munsbit. Min senaste nedladdning innehåller 20,8 miljoner poster. Bara zip-filen är 5,7 GB och tog 11 minuter att hämta på min lina. Jag laddade upp hela kartan till PostGIS på en beskedlig (2C 4GB) Ubuntu-maskin hos City Cloud. Processen tog 2 tim 57 min med en standard kontorslaptop, som jag jobbade med annat på samtidigt.
Det finns en o-öppen programvara som jag inte skulle kunna vara utan en dag, och det är FME, som jag har använt i exemplet ovan. En fördel är att programmet läser shapefilerna direkt i zip-filen, dvs jag behöver inte packa upp den.
Jag gjorde ett försök att slå ihop de ”kartbladsklippta” yt-objekten (som ibland stör renderingen) på vägen, men fick bryta den processen efter ett dygn. Det blev för mycket. Det går dock utmärkt på länsnivå.
Oj, det måste man ju nästan ta som en utmaning. Har inte provat FME på många år, men för 5-10 år sedan så var det många gånger snabbbare med ogr2ogr eller shp2pgsql. Jag tror det berodde på att FME åtminståne då hade en tung internstruktur som den skull konvertera allt till först. Om FME slår shp2pgsql eller ogr2ogr nu så måste vi göra något åt det och få fart på dem 🙂
Testade nu, och shp2pges gör det bra. Jag brukte gui-versionen och bara la in alla tabeller i public utan någon konvertering av något slag. Rutnt krockade med samma namn så tog inte med den. Blev ca 60 lager.
Jag skapade inga spatiala index, det får man göra i efterhand.
Databasen blev 12 GB (alltså utan index).
Det tog runt 11 min 🙂
Det var en lite vassare laptop med 16 GB minne och i7 processor. Men den använde under 1 % minne till postgres och under 1 % minne till shp2pgsql. De fick varsin process, så den använde 2 trådar för att göra jobbet.