Theli-Forum

Code: Alles auswählen

#!/bin/bash
# set swappiness to 10 %, default is 60
sudo sysctl vm.swappiness=10
# or edit /etc/sysctl.d/99-sysctl.conf: add vm.swappiness=10
echo  edit /etc/sysctl.d/99-sysctl.conf: add vm.swappiness=10

Damit setzt man sich unter ubuntu die swap Aktivität herab. Der default ist sehr konservativ und es bedeutet, ab 40% RAM Nutzung beginnt es zu swappen.
10% scheint ein guter Ansatz, zur Reduzierung zu sein, also ab 90% RAM Nutzung wird geswappt,

Interessant, das wusste ich nicht!

Danke, mischa

Moin,

hat das denn irgendeine Auswirkung auf die Arbeit mit Theli?
Speicherseiten, die ständig im Zugriff sind, wenden ohnehin nur ausgelagert, wenn es nicht mehr anders geht.
Wenn Du Theli startest, alle Bilder lädst, dich ins Bett legst und erst am nächsten Morgen auf "Start" klickst, sollte das eine Auswirkung haben, sonst nicht.

Dietmar

hat das denn irgendeine Auswirkung auf die Arbeit mit Theli?

Miss doch nach:
vor theli Start:

Code: Alles auswählen

Swap: 2048 MiB gesamt , 2048 davon frei

Wenn scamp läuft:

Code: Alles auswählen

Swap: 2048 MiB gesamt , 1884 davon frei

=========================

Code: Alles auswählen

Tasks: 211 gesamt,   4 laufend, 207 schlafend,   0 gestoppt,   0 Zombie
%CPU(s): 93,2 be,  6,6 sy,  0,0 ni,  0,0 un,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
MiB Spch :   4227,8 gesamt,    829,5 frei,   2579,7 belegt,    818,5 Puff/Cache
MiB Swap:   2048,0 gesamt,   1884,2 frei,    163,8 belegt.   1380,9 verfü Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL   
  14839 theli     20   0 3758884   1,3g  11972 S 338,9  31,1  87:28.96 scamp   
   1658 theli     20   0 4819352 309208  69848 S  40,9   7,1  20:06.96 gnome-s+
   1047 theli     20   0  857404  64060  27456 R  11,3   1,5   4:15.78 Xorg     
   2069 theli     20   0  970840  36864  23340 R   5,3   0,9   0:14.36 gnome-t+


moos hat geschrieben:Miss doch nach:

Bei mir swappt's ja nicht

Solange der belegte Swap soviel kleiner ist, als das freie RAM, ist das nur Zeug, das gerade nicht gebraucht wir dund ausgelagert wurde im Platz zu machen für weitere Speicheranforderungen von Theli (bei mir laufen auch etliche Prozesse, von denen ich gar nicht weiss, was die überhaupt machen).
Theli wird dadurch nicht langsamer. Erst wenn der belegte Swap größer wird als das freie RAM wird geswappt und das System wird langsam. Dann gehen aber auch System und Waiting rauf.

Übrigens:
Mit nur 6G virtuell DSLR-Daten durch Theli zu jagen ist schon sportlich

Dietmar

dietmar hat geschrieben:Bei mir swappt's ja nicht

Das ist doch relativ kurzsichtig. Theli geht im RAM so hoch wie es kann. Machst Du größere Theliprojekte oder Mittelformat-DSLR, swappts da bei Dir doch auch. Aber kannst ja das swappen so lassen.

dietmar hat geschrieben:Mit nur 6G virtuell DSLR-Daten durch Theli zu jagen ist schon sportlich

Ging schon vor 10 Jahren mit weniger; also warum jetzt sportlich? Brauche doch keinen Ferrari, um 10x im Jahr damit zu flitzen. Bin da bescheiden.
Außerdem werden Programme auf den kleinen Systemen getestet und optimiert, weil sie auf den großen ja keine Probleme haben. Aber für die Effizienz sind die kleinen Maschinen viel sensibler. Und läuft ein Prozess dann nicht auch auf den großen Maschinen erst richtig gut?

moos hat geschrieben:Das ist doch relativ kurzsichtig.

Ich hab' derzeit keine Rohdaten, die meine Maschine zur swappen bringen. Das wird sich in absehbarer Zeit auch nicht ändern, denn:
1. Ich bin ein bischen ein Messie, ich schmeiß meine Rohdaten nach der Coaddition nicht weg. Dadurch sammelt sich im Laufe der Zeit was an. Damit die Datenmengen dennoch nicht explodieren belichte ich so lange wie möglich und mache dafür entsprechend weniger Einzelbilder. Zudem habe ich zwischen dem Balkon über mir und dem aufgehellten Horizont mit miserablem Seeing nur ein Zeitfenster von 60-90min. Das macht 12-18 Frames a 5min. Bei Objekten mit hoher Flächenhelligkeit schon mal mehr.

2. Als ich vor 'nem halben Jahr die Kiste hier zusammengeschraubt hab', hab' ich gerade im Hinblick auf Bildverarbeitung (vorläufig) ausreichend RAM reingestöpselt. Auch 'n Buildlauf geht schneller, wenn Header-Files aus dem Cache gelesen werden, anstatt jedes mal neu von der Platte, vor allem, wenn man dafür alle Kerne benutzt.

moos hat geschrieben:Ging schon vor 10 Jahren mit weniger; also warum jetzt sportlich?

Weil die Kameras von 10 Jahren halb soviele Pixel hatten.

Aber wir kommen vom Thema ab. Die Frage war: läuft deine Astrometrie jetzt spürbar schneller?

Dietmar

moos hat geschrieben:

dietmar hat geschrieben:Außerdem werden Programme auf den kleinen Systemen getestet und optimiert, weil sie auf den großen ja keine Probleme haben.

So ist es bei THELI nicht. ich entwickle es nicht fuer euch, sondern fuer wissenschaftliche Anwendungen. Wenn da jemand ein performance-Problem haben sollte, dann kann er sich an seinem Institut auf einer grossen Maschine einloggen und es da laufen lassen, oder die IT soll dem user doch bitteschoen einen groesseren Rechner beschaffen.

Natuerlich will ich auch das es nach Moeglichkeit auch in einer VM auf einem schwachbruestigen Laptop laeuft, weil nicht jeder Student in Suedamerika diesen Luxus hat. Aber das ist nicht meine Leitlinie bei der Entwicklung.

mischa

Hi Mischa

mischa hat geschrieben: ich entwickle es nicht fuer euch, sondern fuer wissenschaftliche Anwendungen

nun bin ich deprimiert
Gruß
Karsten

spiegelei hat geschrieben:

mischa hat geschrieben: ich entwickle es nicht fuer euch, sondern fuer wissenschaftliche Anwendungen

nun bin ich deprimiert
Gruß
Karsten

Na na, *schulter-klopf*, *wird-schon-wieder*

mischa

moos hat geschrieben:Außerdem werden Programme auf den kleinen Systemen getestet und optimiert

Das trifft auch nur im Embedded-Bereich zu, wo gr0ße Stückzahlen produziert werden und man jeden Cent an der Hardware sparen will.
Wie sonst erklärst Du dir die Beliebtheit von Java, C# und dem ganzen neumodischen Teufelszeug

Dietmar

oh, hier ist ja was hin und her geschwappt.
ich lasse jetzt mal die die Grundsatz-Diskussionen sein.
Theli auf einem embedded-system, integriert in die EOS 2025T, passiv gekühlt, die scamp plots auf dem Kamera-Display mit touch/voice-Bedienung, schöne Vorstellung...

Ich werde mal messen, was die swap Einstellung in Zeit ausmacht. Aber erst mal die Ernte einfahren. Habe jetzt
eine Version (1) mit collapsed, subsky mit sky-model
eine Version ohne collapsed mit subsky sky-model
u. eine Version ohne collapsed , subsky constant region.

Um die Galaxie hatte sich in Version 1 ein dunkler Bereich gebildet. Es kommt entweder vom collapsing ( heisst das so?) oder subsky.

moos hat geschrieben:Um die Galaxie hatte sich in Version 1 ein dunkler Bereich gebildet. Es kommt entweder vom collapsing ( heisst das so?) oder subsky.

Wenn du ein Photo hochlaedst, sag ich dir was es war.

mischa

wenn ein jpeg reicht
Aber ich habe schon einen klaren Verdacht:
links collapesed & skymodell, mitte nur skymodell und rechts nur constant sky region

Gehen eigentlich auch viele Sky Regions für constant sky oder gilt immer der letzte Kreis?

Das ist ganz klar eine Ueberkorrektur durch die skysub Modellierung. Am besten kommst du dem wohl mit einem mask expansion faktor bei, vielleicht 2-3, musst du ausprobieren. Aber das Bild mit konstantem Abzug sieht auch sehr gut aus, da glaube ich brauchst du keine Modellierung.

Du kannst so viele Messpunkte angeben wie du willst, da wird bei "constant sky" dann der Mittelwert genommen. Im Grunde reicht einer.