[Gelöst] ocenaudio: Nutzt swap nicht

[buhtz]

Ich habe eine etwas längere Audiodatei, die ich mit ocenaudio bearbeiten möchte. Das Ding bricht aber reproduzierbar beim Laden ab, weil die 8 GB RAM aufgebraucht sind. Den Swap rührt es allerdings gar nicht an. Der "frei" Wert hier verändert sich beim Laden nicht.

Code: Alles auswählen

$ free -h
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:      7,7Gi       786Mi       5,7Gi       122Mi       1,2Gi       6,5Gi
Swap:           70Gi       276Mi        70Gi

Welche Möglichkeiten habe ich da jetzt? Ich dachte das OS swapped automatisch? Aber scheinbar scheint es auch vom Verhalten der Anwendung abzuhängen?
Der Swap ist in einer Datei per mkswap erzeugt.

EDIT: Natürlich kann ich das die Audiodatei spliten (mpgtx, mp3split, usw). Mir geht es hier aber mehr um das Phänomen, dass eine Anwendung den Swap nicht nutzt.

[whisper]

Programme, wie deins, aber auch scanner und Grafik Bearbeitungsprogramme müssen die zu bearbeitende Datei vollständig im RAM haben swap geht nicht, das ist ganz normal.
Es gibt ein paar Programme wie spezielle Editoren, da ist das anders,

[buhtz]

Programme, wie deins, aber auch scanner und Grafik Bearbeitungsprogramme müssen die zu bearbeitende Datei vollständig im RAM haben

Bitte korrigiert mich, aber ich hab swap anders verstanden.

IMHO sieht in meinem Fall das Programm nur 78 GB Arbeitsspeicher unabhängig davon, ob dieser physikalisch als RAM oder HDD/SSD verfügbar ist.
Klar bremst es eine Anwendung extrem aus, wenn es swapped, aber manchmal ist das akzeptabel. So mache ich es mit eigenen Python-Scripten die viel RAM benötigen. Das läuft dann automatisch in den Swap über (und dauert ein paar Stunden länger).

Scheinbar ist das aber eben nicht so und die Anwendung kann explizit nur echtes RAM anfordern?

[whisper]

Da liegt an der Programmiersprache bzw. am Konstrukt, welches benutzt wird.
Python ist relativ modern und wird durchaus von virtuellen Arbeitsspeicher profitieren.
Ein Array in C z.B. oder ein Bereich mit malloc allokiert muss zwingend im RAM sein.
Nach meinem Verständnis muss ein Prozess komplett ausgelagert werden, wenn der Arbeitsspeicher nicht reicht und schläft da solange, bis das Betriebssystem ihn wieder in den Arbeitsspeicher lädt.

[MSfree]

Programme, wie deins, aber auch scanner und Grafik Bearbeitungsprogramme müssen die zu bearbeitende Datei vollständig im RAM haben swap geht nicht

Das ist falsch. Aus Sicht einer Anwendung ist RAM und Swap das Selbe, die Anwedung weiß nämlich gar nichts davon, ob eine Speicherseite schon im Hauptspeicher ist oder noch auf der Festplatte dümpelt, es braucht die Anwendung auch nicht zu interessieren, darum kümmert sich der Kernel.

@buhtz
Es gibt aber Programme, die den zur Verfügung stehenden Hauptspeicher abfragen und dann nur soviel RAM nutzen, wie zum Programmstart zur Verfügung stand. Geswapt werden kann dann aber trotzdem.

Zusätzlich gibt es API-Aufrufe, mit denen man Speicherseiten im Hauptspeichern festmachen (locken) kann, so daß die gelockten Seiten nie geswapt werden. Hier kann man natürlich immer nur soviel locken, wie Speicher vorhanden ist, ausserdem gibt es meines Wissens ein Limit pro Prozeß. Anwendungen sollten aber nie davon gebraucht machen, den kompletten Speicher zu locken, denn das kann zum Aufhängen des Systems führen.

Bei Audiobearbeitung kann aber bei geswapten Speicherseiten das Problem entstehen, daß eine Sequenz abgespielt werden soll, die gerade geswapt ist. Das würde zwagsläufig zu einem Aussetzer führen, bis die nötigen Daten von der Platte aus dem Swapt gekratzt wurden. Und das wird auch der Grund sein, warum dein Programm nur soviel Speicher nutzt, wie zum Programmstart frei war, um eben das Swappen zu vermeiden.

[MSfree]

Ein Array in C z.B. oder ein Bereich mit malloc allokiert muss zwingend im RAM sein.

Nein, muß es nicht.

[whisper]

Ein Array in C z.B. oder ein Bereich mit malloc allokiert muss zwingend im RAM sein.

Nein, muß es nicht.

Nochmal nachgelesen, hast recht, zu lange her

[uname]

@buhtz
Ich weiß ja nicht, wann du die free -h - Ausgabe gemacht hast. Aber zu dem Zeitpunkt waren nur 1.28 GB verbraucht.

Hast du wirklich 8 GB - große Audio-Dateien? Braucht man sowas?

Ok ich höre nur Radio. Bei 128 kbit/s kann ich 4 Monate Radio hören bis ich 8 GB verbraucht habe ... falls ich mich nicht verrechnet habe.

[MSfree]

Bei 128 kbit/s kann ich 4 Monate Radio hören bis ich 8 GB verbraucht habe ... falls ich mich nicht verrechnet habe.

8000000000 Bytes mal 8 geteilt durch 128000 = 500000 Sekunden, also nichtmal 6 Tage.

Und als CD-Audio (44100 Samples pro Sekunde, 2 Kanäle zu 16Bit) sind es rund 12.5 Stunden.

[uname]

Da habe ich mich wohl verrechnet.
Trotzdem sind 8 GB noch verdammt viel für ein bisschen Audio.

[wanne]

Ich dachte das OS swapped automatisch?

Ja.

Aber scheinbar scheint es auch vom Verhalten der Anwendung abzuhängen?

Anwendungen können versuchen die Entscheidung des Kernels zu beeinflussen.

Die Wahrheit wird eine andere sein: Wie die meisten Spiele fürchten sich die Entwickler vor negativem feedback, wenn das Programm hängt. Also beendet man sich lieber direkt, wenn man merhkt, dass die Ressourcen knapp werden. Wäre die Software OpenSource könntest du sicher einfach die Fehlermeldung raus patchen und alles würde (mit hänger) laufen.
So: Es gibt diverse Programme die mehr RAM vorgaukeln. Kannst du mal danach suchen.