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:



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

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.

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

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:

	Source code
1 2	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