Workstation mit Threadripper macht schlapp bei Satellitendatenberechnung
- Ersteller el-mujo
- Erstellt am
el-mujo
Admiral Special
Hallo in die Runde.
Hier wollt ich mal ein kleines Beispiel aus der realen Arbeitswelt bringen, wo überhaupt hochgradig performante Standard-Systeme benötigt werden und dass diese u.U. auch nicht mehr ausreichen, wenn es um die wirklich großen Datenmengen geht.
Woran arbeite ich?
Ab einer Methode, Vitalitätsveränderungen an Waldflächen mithilfe von Satellitendaten zu erfassen. Ohne jetzt zu sehr über die Methodik ins Detail gehen zu wollen, komme ich an einem Punkt in der Prozessierungspipeline, wo mir meine zur Verfügung stehende 24-Kern Workstation in Aussicht gestellt hat, dass sie damit heillos überfordert ist.
Worum gehts genau?
Ein Satellitenbild der Sentinel-2 Reihe hat 120 Megapixel, bei 12 spektralen Subbändern. Also 10980x10980x12 Pixel + diverse Header und Qualitätsbänder, die für meine Geschichte nicht relevant sind. Aus diesen 12 Bändern werden sog. Vegetationsindizes berechnet. Das ist meist eine simple mathematische Beziehung der einzelnen Spektralbänder zueinander. So reduziert sich die Dimension auf nur noch 1 Band, dem Vegetationsindex. Davon haben wir aber gleich 12 verschiedene berechnen lassen. Mit Metabändern entsteht also wieder ein 20-Kanäliges Bild. Diese Vegetationsindizes reagieren auf Veränderungen der Pflanze bedingt durch Veränderung im Wasserhaushalt, der Cellulose und dem Chlorophyllgehalt. Jede dieser für uns wichtigen vitaltätsbestimmenden Komponenten hat ihre eigene 'Reflektionsbande', also ihre eigene korrespondierende Wellenlänge. Beim Chlorophyll ist das bekanntlich der Bereich des grünen Lichts um 530nm. Den Wassergehalt erfassen wir z.B. im Kurzwelleninfrarot bei 1600nm. So wir bekommen also diverse Indizes, die wiederum alle auseinanderklamüsert werden müssen, da mit für jeden Index eine sog. Zeitreihe vorliegt. Für das Testgebiet haben wir 98 Satellitenbilder runtergeladen. Diese sind mehr oder weniger gleichmäßig über's Jahr verteilt (insg. 6 volle Jahrgänge).
Was zeigt uns erstmal ein Zeitreihe für Waldflächen? Eine sog. 'Phänologiekurve'. Die beschreibt den zeitlichen Verlauf der Vitalität des Blattgrüns im Jahresgang. Und jedes Jahr auf's Neue gibts eine neue Kurve. Nun sind aber nicht jedes Jahr gleiche Witterungsbedingungen, sodass erstens, die Zeitreihe ausgedünnt wird (Wolken) und zweitens, es zu einer veränderten fernerkundlich erfassten Vitalität kommt. Will sagen, je feuchter, desto vitaler ist der Bestand.
Was gilt es zu berechnen?
Wenn ich sagen will, ob sich ein Baum oder Wald aktuell im Stress befindet, muss ich mir seine Vergangenheit anschauen und beachten, wann innerhalb des Jahres ich ihn begutachte.
Die Zeitreihe ist da ein Ansatz, die Vergangenheit der zurückliegenden Vegetationsperioden abzubilden. Man könnte jetzt die Differenz von Jetzt zu einem beliebigen Punkt in der Vergangenheit bilden, aber wer sichert denn zu, dass das Bild aus dem Gegenjahr einen halbwegs 'gesunden' Zustand abbildet, an dem wir uns ja orientieren wollen? Und interessiert also wie gut der Baum aktuell gegenüber dem Zeitpunkt seiner eigenen statistischen Vergangenheit steht, wo ja Jahre der Feuchte und Dürre dabei waren. Diesen Zustand, den ich mal als Mittelung bezeichnen würde, ist quasi die ideale Sollkurve eines Baums, den er wahrscheinlich annimt, wenn gleiche Bedingungen wie in der Vergangenheit herrschten. Wir wollen nun detektieren, wie stark von dieser Sollinie abgewichen wird, an dem entspr. Zeitpunkt im Jahr.
Mit anderen Worten, wir wenden eine Methode an, die das Bild mit dem Vegetationsindex so analysiert, dass sie die einzelnen Jahrgänge übereinander legt und darauf eine sog. '2d-Kerneldichtefunktion' ansetzt, die diesen Zustand des statistisch gesicherten Mittels der überlagerten Phänologierkurven liefert. Und das für jedes der 120Millionen Pixel einer Szene separat (4 Szenen hat das Land). Das macht die Statistiksoftware R.
Und hier genau hakt's.
Schon eine 0,3MPixel Testszene benötigte 2,5 Stunden an Rechenzeit. Hochgerechnet auf eine 120MPixel-Szene wären dass 41,6 Tage bei 47 zur Verfügung gestellten logischen Prozessoren. Das gesamte Untersuchungsgebiet umfasst jedoch 4 Sentinel-Kacheln á 120 MPixel. Und duch die Notwendigkeit die Beobachtungsdichte an Bildern für alle Zeitreihen anzugleichen und daher noch zeitlich interpolierte Daten ins System eingespeist werden, wird ein Zeitlicher Stack nicht 100 sondern eher 200-300 Bilder umfassen.
Will sagen, da bin ich mit meiner Workstation raus. Das kann nur noch auf einem größeren Cluster gerechnet werden. Also Einzel-CPU-Workstation jedenfalls ist das Gerät damit völlig überfordert.
Hier wollt ich mal ein kleines Beispiel aus der realen Arbeitswelt bringen, wo überhaupt hochgradig performante Standard-Systeme benötigt werden und dass diese u.U. auch nicht mehr ausreichen, wenn es um die wirklich großen Datenmengen geht.
Woran arbeite ich?
Ab einer Methode, Vitalitätsveränderungen an Waldflächen mithilfe von Satellitendaten zu erfassen. Ohne jetzt zu sehr über die Methodik ins Detail gehen zu wollen, komme ich an einem Punkt in der Prozessierungspipeline, wo mir meine zur Verfügung stehende 24-Kern Workstation in Aussicht gestellt hat, dass sie damit heillos überfordert ist.
Worum gehts genau?
Ein Satellitenbild der Sentinel-2 Reihe hat 120 Megapixel, bei 12 spektralen Subbändern. Also 10980x10980x12 Pixel + diverse Header und Qualitätsbänder, die für meine Geschichte nicht relevant sind. Aus diesen 12 Bändern werden sog. Vegetationsindizes berechnet. Das ist meist eine simple mathematische Beziehung der einzelnen Spektralbänder zueinander. So reduziert sich die Dimension auf nur noch 1 Band, dem Vegetationsindex. Davon haben wir aber gleich 12 verschiedene berechnen lassen. Mit Metabändern entsteht also wieder ein 20-Kanäliges Bild. Diese Vegetationsindizes reagieren auf Veränderungen der Pflanze bedingt durch Veränderung im Wasserhaushalt, der Cellulose und dem Chlorophyllgehalt. Jede dieser für uns wichtigen vitaltätsbestimmenden Komponenten hat ihre eigene 'Reflektionsbande', also ihre eigene korrespondierende Wellenlänge. Beim Chlorophyll ist das bekanntlich der Bereich des grünen Lichts um 530nm. Den Wassergehalt erfassen wir z.B. im Kurzwelleninfrarot bei 1600nm. So wir bekommen also diverse Indizes, die wiederum alle auseinanderklamüsert werden müssen, da mit für jeden Index eine sog. Zeitreihe vorliegt. Für das Testgebiet haben wir 98 Satellitenbilder runtergeladen. Diese sind mehr oder weniger gleichmäßig über's Jahr verteilt (insg. 6 volle Jahrgänge).
Was zeigt uns erstmal ein Zeitreihe für Waldflächen? Eine sog. 'Phänologiekurve'. Die beschreibt den zeitlichen Verlauf der Vitalität des Blattgrüns im Jahresgang. Und jedes Jahr auf's Neue gibts eine neue Kurve. Nun sind aber nicht jedes Jahr gleiche Witterungsbedingungen, sodass erstens, die Zeitreihe ausgedünnt wird (Wolken) und zweitens, es zu einer veränderten fernerkundlich erfassten Vitalität kommt. Will sagen, je feuchter, desto vitaler ist der Bestand.
Was gilt es zu berechnen?
Wenn ich sagen will, ob sich ein Baum oder Wald aktuell im Stress befindet, muss ich mir seine Vergangenheit anschauen und beachten, wann innerhalb des Jahres ich ihn begutachte.
Die Zeitreihe ist da ein Ansatz, die Vergangenheit der zurückliegenden Vegetationsperioden abzubilden. Man könnte jetzt die Differenz von Jetzt zu einem beliebigen Punkt in der Vergangenheit bilden, aber wer sichert denn zu, dass das Bild aus dem Gegenjahr einen halbwegs 'gesunden' Zustand abbildet, an dem wir uns ja orientieren wollen? Und interessiert also wie gut der Baum aktuell gegenüber dem Zeitpunkt seiner eigenen statistischen Vergangenheit steht, wo ja Jahre der Feuchte und Dürre dabei waren. Diesen Zustand, den ich mal als Mittelung bezeichnen würde, ist quasi die ideale Sollkurve eines Baums, den er wahrscheinlich annimt, wenn gleiche Bedingungen wie in der Vergangenheit herrschten. Wir wollen nun detektieren, wie stark von dieser Sollinie abgewichen wird, an dem entspr. Zeitpunkt im Jahr.
Mit anderen Worten, wir wenden eine Methode an, die das Bild mit dem Vegetationsindex so analysiert, dass sie die einzelnen Jahrgänge übereinander legt und darauf eine sog. '2d-Kerneldichtefunktion' ansetzt, die diesen Zustand des statistisch gesicherten Mittels der überlagerten Phänologierkurven liefert. Und das für jedes der 120Millionen Pixel einer Szene separat (4 Szenen hat das Land). Das macht die Statistiksoftware R.
Und hier genau hakt's.
Schon eine 0,3MPixel Testszene benötigte 2,5 Stunden an Rechenzeit. Hochgerechnet auf eine 120MPixel-Szene wären dass 41,6 Tage bei 47 zur Verfügung gestellten logischen Prozessoren. Das gesamte Untersuchungsgebiet umfasst jedoch 4 Sentinel-Kacheln á 120 MPixel. Und duch die Notwendigkeit die Beobachtungsdichte an Bildern für alle Zeitreihen anzugleichen und daher noch zeitlich interpolierte Daten ins System eingespeist werden, wird ein Zeitlicher Stack nicht 100 sondern eher 200-300 Bilder umfassen.
Will sagen, da bin ich mit meiner Workstation raus. Das kann nur noch auf einem größeren Cluster gerechnet werden. Also Einzel-CPU-Workstation jedenfalls ist das Gerät damit völlig überfordert.
Zuletzt bearbeitet:
Krümel
Grand Admiral Special
Entweder die Berechung so umstellen, dass auch Grafikkarten sie durchführen können (die sind bei angepassten BErechnungen deutlich schneller) oder daraus ein BOINC-Projekt machen. 
enigmation
Admiral Special
Werden denn alle 24 Kerne ausgelastet? Vielleicht mit NNCONECTIONS anpassen?
Welches OS nutzt du?
Mit welcher Geschwindigkeit läuft der RAM?
Und wenn du Pixelgruppen wie 4x4 nutzt? Ist das erlaubt?
Welches OS nutzt du?
Mit welcher Geschwindigkeit läuft der RAM?
Und wenn du Pixelgruppen wie 4x4 nutzt? Ist das erlaubt?
el-mujo
Admiral Special
Es ist das einfache Modell mit 24 Kernen und 128GB RAM. RAM ist nicht das Problem in dem Fall. Ja, es werden alle Kerne ausgelastet. Portierung auf GPU ist für mich jedenfalls nicht möglich. Und ob das unbedingt den gewünschten Erfolg bringt ist fraglich, da mit Fließkommazahlen gerechnet wird, was GPUs ja nun garnicht gerne mögen und der Threadripper nun ja auch nicht gerade wenig performant ist - da fehlt nicht mehr viel zur GPU.
Hier hilft nur mehr CPU Power durch mehr Kerne (wie damals bei CPDN schon
). Bei 4-Sockel ist derzeit bei AMD schluss. Das wären mit EPYC 64c-CPUS immerhin 256 Kerne bzw. 512 logische Kerne. Also 10 mal mehr Power als jetzt - dann wären's noch 4 Tage Berechnungszeit - das wäre durchaus noch stämmbar. Bei Intel sind 8-Sockel-Sytseme aber nur mit 24 Kernen verfügbar. Die 40Core Modelle gibt es dafür nicht. Darüber hinaus gehts dann in Cluster und Mainframes über. Aber das soll dann nicht mehr mein Problem sein. Ich kann nur die Anforderung an die Rechenleistung stellen - bereitstellen muss sie jemand Anders - und bezahlen wiederum jemand Anders
Matlab wäre schön, weil deutlich performanter. Da ist Matrixberechnung wirklich die ureigenste Spezialdisziplin von Matlab. Leider ist der Approach nunmal in R geschrieben und eine Portierung in dem Sinen nicht möglich. Der Ansatz müsste von grundauf neu programmiert werden. Vielleicht versuch ich das auch noch irgendwann.
Hier hilft nur mehr CPU Power durch mehr Kerne (wie damals bei CPDN schon
). Bei 4-Sockel ist derzeit bei AMD schluss. Das wären mit EPYC 64c-CPUS immerhin 256 Kerne bzw. 512 logische Kerne. Also 10 mal mehr Power als jetzt - dann wären's noch 4 Tage Berechnungszeit - das wäre durchaus noch stämmbar. Bei Intel sind 8-Sockel-Sytseme aber nur mit 24 Kernen verfügbar. Die 40Core Modelle gibt es dafür nicht. Darüber hinaus gehts dann in Cluster und Mainframes über. Aber das soll dann nicht mehr mein Problem sein. Ich kann nur die Anforderung an die Rechenleistung stellen - bereitstellen muss sie jemand Anders - und bezahlen wiederum jemand Anders Matlab wäre schön, weil deutlich performanter. Da ist Matrixberechnung wirklich die ureigenste Spezialdisziplin von Matlab. Leider ist der Approach nunmal in R geschrieben und eine Portierung in dem Sinen nicht möglich. Der Ansatz müsste von grundauf neu programmiert werden. Vielleicht versuch ich das auch noch irgendwann.
el-mujo
Admiral Special
Ja, das ist eher Mittelmaß. Meine 'neue' Workstation hat gar nur den 16-Kerner Threeadripper drin. Hier kam ichneulich auch an die RAM-Grenze. Ziemlich intererssant, weil der Windows-Task-Manager nur 20 von 64GByte an Auslastung anzeigte. Aber trozudem ahtte er auf der HDD gecached. Und weil der Cach auf der HDD statisch und zu klein war, brach gleich die ganze Berechnung ab. Mit nun dynamischer Cach-Größe lasten 28 laufende Prozessoren (Software-Prozessoren) die CPU fast vollständig aus und der RAM angeblich bei ~ 16-20GByte. Die wahre RAM-Auslasdtung sieht man jedoch eine Zeile tiefer. 'Comitted' oder zu deutsch 'zugesichert' ist der realre RAM-Verbrauchs-Wert. Denn der liegt aktuell bei 160 GByte.
Die neueste EPYC-CPU mit 128 Kerne wäre ganz nett, ist aber eigentlich auch viel zu klein. Aber die müsste dann schon mind. 1 TB RAM haben.
Was hat sich Gauß nur dabei gedacht?!
Die neueste EPYC-CPU mit 128 Kerne wäre ganz nett, ist aber eigentlich auch viel zu klein. Aber die müsste dann schon mind. 1 TB RAM haben.
Was hat sich Gauß nur dabei gedacht?!
Nicht direkt denn da steckt meines erachtens der Teil von der Auslagerungsdatei mit drin, sonst wäre es ganz einfach nicht möglich das mehr belegbar ist als RAM installiert ist.
Wieviel davon im RAM selbst liegt sieht man dort also nicht.
MagicEye04
Grand Admiral Special
Wenn ich weiß, dass genug RAM drin ist, dann deaktiviere ich normalerweise immer die Auslagerungsdatei.
Bei Linux gibt es ja neben der realen Belegung des RAM auch noch die vom Programm als maximal vorhergesagte Größe - vielleicht ist das in Windows mit committed gemeint. Denn dort sehe ich beim Arbeitslaptop auch regelmäßig 20-30GB und trotz nur 8GB echtem RAM merkt man nix von massiver Auslagerung etc.
Bei Linux gibt es ja neben der realen Belegung des RAM auch noch die vom Programm als maximal vorhergesagte Größe - vielleicht ist das in Windows mit committed gemeint. Denn dort sehe ich beim Arbeitslaptop auch regelmäßig 20-30GB und trotz nur 8GB echtem RAM merkt man nix von massiver Auslagerung etc.
Nicht wenn man schonmal bei den Programmen eine Ratte dabei hatte die allergisch auf die fehlende Auslagerungsdatei reagierte udn entweder nicht startet oder mit einer kryptischen Fehlermeldung abschmiert die nicht im entferntesten darauf hindeutet.
Maverick-F1
Grand Admiral Special
Die Auslagerungsdatei ganz zu deaktivieren ist auch alles andere als "recommended" - wenn dann vielleicht auf eine bestimmte Größe fixieren.
"Commited" ist der gesamte zugesicherte Speicher - inkl. Swap-File.
Aber der Task-Manager von Windows 11 zeigt die Speicherbelegung eigentlich schon recht zuverlässig an (im Gegensatz zur CPU-Auslastung) - v.a. das Balkendiagramm sollte hier die relevanten Insights liefern...
Darüberhinaus zeigt die Prozessansicht default die Spalte mit "Arbeitsspeicher (aktiver privater Arbeitssatz)" den tatsächlich belegten exklusiven physischen Speicher - das sollte auch Hinweise geben.
Ansonsten haben sich die Sys-Internal Tools als Analysewerkzeug mehr als bewährt, brauchen aber ein wenig Einarbeitungszeit...
"Commited" ist der gesamte zugesicherte Speicher - inkl. Swap-File.
Aber der Task-Manager von Windows 11 zeigt die Speicherbelegung eigentlich schon recht zuverlässig an (im Gegensatz zur CPU-Auslastung) - v.a. das Balkendiagramm sollte hier die relevanten Insights liefern...
Darüberhinaus zeigt die Prozessansicht default die Spalte mit "Arbeitsspeicher (aktiver privater Arbeitssatz)" den tatsächlich belegten exklusiven physischen Speicher - das sollte auch Hinweise geben.
Ansonsten haben sich die Sys-Internal Tools als Analysewerkzeug mehr als bewährt, brauchen aber ein wenig Einarbeitungszeit...
Linux benötigt bei mir und meinen Programmen i.d.R. übern Daumen nur halb so viel Speicher, ob RAM oder ROM auf den HDs,
Da haben z.B. 16 TB HD auch noch echte 16 TB zur verfügung.
Ansich sollte, müsste, könnte, ein professionelles Programm doch mit Linux/Unix umgehen können oder?
die großen Workstatios arbeiten eher nicht mit Windows, das hat schon Gründe!
Auch verpufft etwa bei Linux nicht so viel Rechenpower wie dem wackeligen instabileren Resourcenfresser Windows..
Oder anders herum: Linux hat mehr Rechenpower die es nutzen kann, mehr Boost-Takt und kann einiges spürbar schneller und auch i.d.R. stabiler ...
Nur mal so zum andenken, aber das wurde sicher schon erwogen, denke ich mal...
Eine Swap-File tät ich auch fest einrichten und nicht deaktivieren!
Man kann ja ermitteln wieviel das OS für den täglichen Bedarf benötigt, auch wenn der Rechner mal ne Woche am Stück arbeiten muss zudem, und entsprechend nicht allzuknapp einstellen (und ggf. korrigieren)
Da haben z.B. 16 TB HD auch noch echte 16 TB zur verfügung.
Ansich sollte, müsste, könnte, ein professionelles Programm doch mit Linux/Unix umgehen können oder?
die großen Workstatios arbeiten eher nicht mit Windows, das hat schon Gründe!
Auch verpufft etwa bei Linux nicht so viel Rechenpower wie dem wackeligen instabileren Resourcenfresser Windows..
Oder anders herum: Linux hat mehr Rechenpower die es nutzen kann, mehr Boost-Takt und kann einiges spürbar schneller und auch i.d.R. stabiler ...
Nur mal so zum andenken, aber das wurde sicher schon erwogen, denke ich mal...
Eine Swap-File tät ich auch fest einrichten und nicht deaktivieren!
Man kann ja ermitteln wieviel das OS für den täglichen Bedarf benötigt, auch wenn der Rechner mal ne Woche am Stück arbeiten muss zudem, und entsprechend nicht allzuknapp einstellen (und ggf. korrigieren)
el-mujo
Admiral Special
R läuft prinzipiell auf Linux, Mac und Windows. Mir ist es eigentlich egal, welches OS. Aber das wird hier alles vom IT-Support vorgegeben.
In jedem Falle konnte der RAM bzw. dessen Handling als Ursache ausgemacht werden.
Im 'Process Explorer' kann man das Verhalten besser beobachten als im Task Manager. Da werden dann auch korrekte CPU-Auslastungs-Werte angezeigt. Das mit der Missweisung belegten RAMS kenne ich aber seit ich Windows kenne. Faustregel: 1/2 RAM-Auslastung ist in wirklichkeit mind. doppelt so hoch. Genau deswegen fängt er ja auch schon vor erreichen der Grenze an zu cachen.
Hätte nicht gedacht, dass mich das Thema RAM im Jahr 2024 nochmal so tangiert. Seit über 20 Jahren steht eigentlich immer ausreichend RAM zur Verfügung, aber hier ist das irgendwie anders.
Ja, die RAM-Disk kenn ich auch noch Das hier ist der genau umgekehrte Fall dazu.
In jedem Falle konnte der RAM bzw. dessen Handling als Ursache ausgemacht werden.
Im 'Process Explorer' kann man das Verhalten besser beobachten als im Task Manager. Da werden dann auch korrekte CPU-Auslastungs-Werte angezeigt. Das mit der Missweisung belegten RAMS kenne ich aber seit ich Windows kenne. Faustregel: 1/2 RAM-Auslastung ist in wirklichkeit mind. doppelt so hoch. Genau deswegen fängt er ja auch schon vor erreichen der Grenze an zu cachen.
Hätte nicht gedacht, dass mich das Thema RAM im Jahr 2024 nochmal so tangiert. Seit über 20 Jahren steht eigentlich immer ausreichend RAM zur Verfügung, aber hier ist das irgendwie anders.
Ja, die RAM-Disk kenn ich auch noch
Das hier ist der genau umgekehrte Fall dazu.Ähnliche Themen
