• 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

  • Hi,

    wie viel Speicher ist im aktuellen Verzeichnis frei? (unter Linux werden die Temp Dateien dorthin geschrieben)

    Quote

    Auch ist ohne Quellcode mein mögliches Debugging begrenzt.

    der Code dahinter is eigentlich ganz simpel - es wird mittels fwrite() ein Datenblock geschrieben und dabei überprüft ob auch wirklich alle Bytes geschrieben werden konnten - ist das nicht der Fall - kommt diese Fatalerror Meldung...

    Schöne Grüße,
    Klaus

  • 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.

    Edited 3 times, last by schattenfell (September 26, 2011 at 10:14 AM).

  • Hi,

    Was genau ist mit "aktuellem Verzeichnis" gemeint?

    das aktuelle Verzeichnis von dem der Prozess aus gestartet wurde,

    wenn aber genug Speicher frei ist, dann könnte es eventuell auch noch daran liegen das, dass System/der Prozess keine freien Filehandles mehr hat... was allerdings etwas seltsam wäre... oder es ein Limit voreingestellt...

    probiere eventuell dieses Limit zu erhöhen, z.B. mittels:

    Code
    ulimit -n 99999

    (eventuell sind aber noch weitere Einstellungen notwendig...)

    mehr Informationen z.B. hier:
    http://www.cyberciti.biz/faq/linux-incr…-of-open-files/

    Schöne Grüße,
    Klaus

  • Eventuell könnte es auch noch an der Hardware liegen. Als ich die Fehlerbeschreibung gelesen habe dachte ich an defekten Speicher oder defekte Festplatte.
    Ich würde den Speicher mal mit memtest prüfen. Bei der Festplatte eventuell mal mit einem S.M.A.R.T. Tool nachschauen, die melden sich normalerweise relativ früh.

    So wie es Klaus den Code beschrieben hat scheint mir ein Softwarefehler von krpano sehr unwahrscheinlich.

    Grüße
    Marcus

  • 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

  • Das ist ja schon mal was.
    Vielleicht kannst Du mit strace mehr erfahren. Eigentlich finde ich es aber kurios dass es mal klappt und dann wieder nicht. Die Rechte scheinen also zu stimmen...
    Und dann die Abhängigkeit von I/O und Nutzer - misteriös - aber auch interessant.

    Grüße
    Marcus

  • Hi,

    nach der Beschreibung nach, würde ich sagen, es liegt daran, dass es nicht möglich ist die Swap-Dateien zu schreiben - vermutlich aufgrund fehlender Schreibrechte im 'aktuellen' Verzeichnis.

    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).

    D.h. in den Situation ohne Last wird wahrscheinlich immer genug freier Arbeitsspeicher zur Verfügung gestanden haben - und in den Situation ohne Last eben nicht - wodurch das Tool 'Swap'-Datei erzeugt, was aufgrund fehlender Schreibrechte fehlschlägt.

    Es gibt seit wenigen Minuten auch eine neue krpano Version - siehe hier:
    krpano 1.0.8.14

    Ich habe darin noch ein paar Anpassungen diesbezüglich vorgenommen:

    • Unter Linux wird jetzt auch das Standard TEMP-Verzeichnis (meist /tmp/) für die Swap-Dateien verwendet.
    • Weiters ist das TEMP-Verzeichnis auch per "-tempdir=###" oder in der .config einstellbar.
    • Und es gibt genauere Fehlermeldung wenn das Schreiben der Swap-Dateien fehlschlägt.


    Schöne Grüße,
    Klaus

  • 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

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!