Beiträge von schattenfell

  • kvmem - fatalerror

    Hallo Klaus,

    deinen Ausführungen folgend, habe ich jetzt eine starke Vermutung, was die Ursache sein könnte:

    "Das kmakemultires Tools überwacht den aktuellen freien Arbeitsspeicher und legt nur solange neuen Speicher an, solange auch wirklich etwas frei ist. Dabei wird auch etwas 'Luft' für das System gelassen um zu verhindern das, dass System selbst ins Swappen kommt und damit alles noch weiter ausbremst (vor allem unter Windows)."

    Jetzt ergibt die "Anomalie" für mich unter Linux Sinn. Die Überwachung des freien Arbeitsspeichers sollte unbedingt entfernt werden. Linux ist stets bestrebt, den freien Arbeitsspeicher maximal zu nutzen. Dadurch werden lokalen Dateien bei deren Verwendung sofort gecached, wenn Arbeitsspeicher zur Verfügung steht. Bsp. "top" unter Linux:

    Code
    Mem:  12327760k total, 11577724k used,   50036k free,  1703508k buffers
Swap:  4194296k total,   0k used, 4194296k free,  8441060k cached

    In diesem Szenario werden über 8GB an Dateien gecached. Wichtig zu wissen ist nun aber: Sobald ein Prozess Arbeitsspeicher anfordert, fliegen bei Bedarf sofort die Dateien aus dem Cache, um Speicher bereitzustellen. In dem obigen Beispiel sind also nicht nur etwa 50 MB Ram für Prozesse verfügbar, sondern über 8 GB an nativem Ram.

    Jetzt ist es auch plausibel, warum bei uns Nachts, wenn die Backups laufen, das Skript ausfällt. Während des Backups werden tausende Dateien kopiert, die dann bei Zugriff sofort gecached werden. Entsprechend steigt "cached" dann immer immens an und "free" sinkt, was dann in finaler Konsequenz den KRPano Fehler auslöst.

    Dass das Skript als root durchläuft lässt sich in dem Moment auch sehr einfach erklären, da der Linux Kernel nichtpriviligierte Nutzer stets davon abhält, allen verfügbaren Speicher zu verbrauchen. Er reserviert einen Teil speziell für den root user.

    Ich würde mir daher wünschen, dass entweder:

    a) die Überwachung des Arbeitsspeichers entfernt wird (sie ergibt für mich auch keinen Sinn unter Linux, wenn kein Speicher mehr allokiert werden kann, kann man dies auch im Skript abfangen, das angesprochene Last Kriterium ist es aber definitiv nicht)

    oder

    b) zumindest eine neue Option eingeführt wird, diese bei Bedarf deaktivieren zu können (falls dies für Windows Nutzer essentiell ist, hier kenne ich mich jedoch nicht tief genug aus).

    Beste Grüße
    Michael

  • Feature request / Bug Temp Verzeichnis

    Hallo,

    im Moment setzen wir "kmakemultires 1.0.8.14 - 64bit Linux (build 2011-09-12)" automatisiert ein, um Panoramen umzuwandeln.

    Dabei werden temporär die Dateien "[...]tempcube[...].kro" in dem Verzeichnis erstellt, wo sich das Originalbild befindet und nicht im lokalen Temp-Verzeichnis.

    Ist dieses Verhalten so gewollt? Falls ja, wäre es schön, wenn man per zusätzlichem Parameter das zu verwendende Temp-Verzeichnis angeben könnte. Dies würde es ermöglichen, die Laufzeit des Programmes gerade in einer Cluster-Umgebung mit shared volumes deutlich zu steigern (Verwendung einer Ramdisk oder lokaler Temp-Verzeichnisse anstatt von Netzlaufwerken etc.).

    Beste Grüße
    Michael

  • kvmem - fatalerror

    Hallo,

    an den Limits liegt es nicht, diese sind bei uns bereits sehr hoch eingestellt (500.000+ pro lokalem Nutzer). Ebenso sind RAM- oder Festplattendefekte ausgeschlossen, da diese permanent geprüft und überwacht werden.

    Inzwischen konnte ich das Problem jedoch weiter einkreisen und die vermutliche Ursache finden:

    Aus Sicherheitsgründen läuft bei uns die Umwandlung per Skript mit den Rechten eines einfachen lokalen Nutzers.

    Testweise habe ich ich das Skript nun als root laufen lassen und siehe da: es läuft ohne Probleme durch. Selbst ein 48h Dauertest unter sehr hoher Nebenlast verlief ohne Abbruch.

    Dieser Zustand ist allerdings sehr unbefriedigend, da ich dem Skript auf Dauer keine root-Rechte reinräumen möchte.

    Zusammenfassend lässt sich für uns sagen:

    -> kmakemultires als root ausführen: keine Probleme (auch unter hoher Last des Servers)
    -> kmakemultires als unterprivilegierter Nutzer starten: sporadische Abstürze (unter hoher I/O Last bis zu 90% Absturzrate)

    Der unterprivilegierte Nutzer hat für alle Verzeichnisse die notwendigen Rechte. Da es nur zu sporadischen Abstürzen kommt (vorallem unter hoher Last) und ein erneuter Aufruf irgendwann dennoch sauber durchläuft, vermute ich den Fehler weiterhin auf KRPano Seite. Kmakemultires scheint in unserem Szenario nur mit root Rechten 100%ig zu funktionieren, was unbedingt für die Zukunft abgestellt werden sollte.

    Ich hoffe dass diese weiteren Informationen helfen, die Ursache zu finden. Wie gesagt, ohne höhere Debugging Level oder Quellcode stochere ich auch nur im Heuhaufen ;)

    Beste Grüße
    Michael

  • kvmem - fatalerror

    Was genau ist mit "aktuellem Verzeichnis" gemeint?

    - im Verzeichnis wo "kmakemultires" liegt, 100 GB frei (ext3 file system)
    - im Linux Temp Verzeichnis, 20 GB frei (ext3 file system)
    - im Zielordner für die Panoramen, mehrere TB frei (ocfs2 file system)

    Etwa 10 GB RAM standen beim Skriptdurchlauf für den Prozess zur Verfügung (swap wurde nicht benötigt). Im Zeitraum, als der Fehler auftrat, habe ich auch das Temp Verzeichnis überwacht. Es war immer ausreichend Speicherplatz vorhanden, dennoch brach es mitunter bei 0% ab.

  • kvmem - fatalerror

    Hallo,

    im Moment setzen wir "kmakemultires 1.0.8.14 - 64bit Linux (build 2011-09-12)" automatisiert ein, um Panoramen umzuwandeln.

    Sporadisch tritt dabei folgender Fehler auf:

    Code
    loading inputimage ... 0% 1% 2% 3% [...]   kvmem - fatalerror - kvmem_sys_saveswapdata() failed

    Im Forum wurde bereits über diesen Fehler diskutiert, mit keinem eindeutigen Ergebnis.
    Sowohl RAM als auch freier Speicher im TMP Verzeichnis sind ausreichend vorhanden.
    Auch sind die Panoramen nicht besonders groß (im Schnitt 30 MB und 15.000 Pixel Breite).

    Feststellen konnten wir bisher nur:

    -> der Fehler tritt gehäuft auf, wenn auf dem System eine gewisse I/O Grundlast herrscht (Kopiervorgang / Backup läuft nebenbei)
    -> die Konvertierung bricht gehäuft bei bestimmten Prozentzahlen ab, in fast allen Fällen bei 80% oder 3% oder 0%

    Im Moment nutzen wir als workaround die Tatsache, dass es bei erneutem Aufruf irgendwann durchläuft.

    Da der Fehler sporadisch auftritt, kann ich leider keinen Testcase liefern. Auch ist ohne Quellcode mein
    mögliches Debugging begrenzt.

    Hints are always welcome... thanks in advance!

    Beste Grüße
    Michael

  • falscher exit code

    Hallo,

    im Moment setzen wir "kmakemultires 1.0.8.14 - 64bit Linux (build 2011-09-12)" automatisiert ein und nutzen den exit code, um im Fehlerfall reagieren zu können.
    Dies klappt bei diversen Fehlern sehr gut, tritt jedoch ein:

    Code
    loading error - only 8 or 16 bit RGB or RGBA format supported!


    Fehler auf, wird als exit code weiterhin 0 zurückgegeben, was unter Linux standardmäßig "successful termination" bedeutet.

    Vielleicht kann dies demnächst mit gepatcht werden. Aktuell nutzen wir einen workaround.

    Beste Grüße
    Michael