search

Deadwood-ai / deadwood-api

Main FastAPI application for the deadwood backend
GNU General Public License v3.0
0 stars 0 forks source link

Handle big data files in processing. #54

Open JesJehle opened 2 months ago

JesJehle commented 2 months ago

We have currently an error in the cog processing, of the files fro bavariannationalpark, with 70 GB. image

I think this is a good time to discuss how we should handle such sizes. @cmosig For the current process I would suggest to omit this dataset.

mmaelicke commented 2 months ago

Was genau ist denn der fehler?

JesJehle commented 2 months ago

aus den logs: Error processing COG for dataset 3545: /data/cogs/0c04075b-aadc-4e67-9b1a-b8540ba9405f_bavarianationalpark/0c04075b-aadc-4e67-9b1a-b8540ba9405f_bavarianationalpark_cog_jpeg_ts_web-optimized_q75.tif: No such file or directory

cmosig commented 2 months ago

Komisch. Klingt ja irgendwie nicht so also ob die Dateigröße hier das Problem ist. Ist das reproduzierbar?

cmosig commented 1 month ago

Ich hatte mit Teja etwas gequatscht und wir sind auf den Konsens gekommen dass wir am Besten schauen sollten was der Server maximal handlen kann an Dateigröße und alles größer ist, wird eben aufgeteilt. Das macht an sehr vielen Stellen unser Leben einfacher und es braucht kein gesondertes handling von den riesen (e.g. California) Datensätzen.

32GB sollten es aber mindestens sein können.

Der storage server hat nur 10TB storage, oder? Das ist jetzt schon nicht mehr aussreichend, wir sind bei ~15TB würde ich schätzen. Soll ich dafür ein neues issue öffnen, oder ist das einfach zu erweitern? Denke 50TB sollten wir erstmal allocaten.

mmaelicke commented 1 month ago

Ui. Wo kommen denn die ganzen Bilder her? mein letzter Stand max. 6TB. Evtl brauchen wir hierfür ein Treffen um verschiedene Strategien durchzusprechen. Der Server ist nicht erweiterbar, mir ist auch kein Provider bekannt der mehr als 10TB anbietet. Ich persönlich habe auch wenig Erfahrung, wie ein solcher Server dimensioniert sein muss, was CPU und RAM angeht, damit sich mehr als 10TB effektiv nutzen lässt.

Überlegungen die wir hier anstellen können:

In jedem Fall müssen wir einen Zeitplan aufstellen, damit ich mir ausreichend Zeit nehmen kann.

cmosig commented 1 month ago

SX65 bei Hetzner hat 4x22TB HDD und 2x1TB SSD. Würde das nicht gehen?

In der SX Reihe geht es sogar es 14x22TB.

https://www.hetzner.com/dedicated-rootserver/sx65/

Wenn man Spaß hat könnte man einen LRU Cache für die COGs auf den SSDs bauen :P

mmaelicke commented 1 month ago

Ah cool, ich hatte die 1TB SSD übersehen. Denn für die COGs ist das denke ich absolut notwendig. die können wir nicht auf die HDD packen.

Dee Sache mit der Zeit bleibt dennoch. Ich spreche mal mit Teja wegen Kohle und dann müssen wir schauen wann wir einen solchen Umbau machen. WOllen wir dann die jetzige Maschine (erstmal) zum entwickeln behalten, denn es sind ja noch wirklich viele issues offen?

cmosig commented 1 month ago

Ok nice. :+1:

Dann muss man das mit dem caching ja tatsächlich machen, wenn die HDDs für die COGs nicht ausreichen. Müsste man wohl mal testen.

Bzgl der aktuellen Maschine müsst ihr sagen ob ihr die für die Entwicklung braucht.

Zeitmäßig drängt es nicht krass. Wenn es bis Anfang nächstes Jahr auf den neuen Server migriert ist würde es von meiner Seite aus reichen. Bis dahin kann ich auch noch nicht so wichtige Datensätze zurückhalten und dann reichen die sicher 10TB bis dahin.

JesJehle commented 1 month ago

Finde ich eine gute Idee. Ich würde jetzt auch erstes Mal die Issues im bestehenden System lösen, bevor wir es so krass skalieren. Anfang nächstes Jahr ist, denke ich, gut machbar.