Schreib-Cache Stockung?

Hallo evtl. habt ihr einen Tip für mich,

ich schreibe von einem Windows7-Recher live-TV-Aufnahmen auf einen SMB Share. Dabei kommt es zu Rucklern (in der Aufnahme) alle 30 Sekunden. Die Aufzeichnung erfolgt eher langsam, bei HD unter 10 MB/Sek. aber sie darf nie einbrechen, sonst kommt es zu den Rucklern. Der Server nimmt problemlos große Dateien mit 60 und mehr MB/Sek an, aber scheinbar nicht nicht kontinuierlich. Mein Verdacht ist, dass es am Schreiben des Diskcache alle 30 Sek. liegt. Was passiert in dieser Phase mit den weiter gleichmäßig eintreffenden Daten?

Danke,
Patrick

catalpa schrieb:

Der Server nimmt problemlos große Dateien mit 60 und mehr MB/Sek an, aber scheinbar nicht nicht kontinuierlich. Mein Verdacht ist, dass es am Schreiben des Diskcache alle 30 Sek. liegt. Was passiert in dieser Phase mit den weiter gleichmäßig eintreffenden Daten?

Zum Vergrößern anklicken....

Vorweg: Ich kann die versichern, dass es nicht am Festplattencache liegt. Ursache ist eher eine zu langsame und/oder zu volle Festplatte, oder keinen optimalen Einstellungen von CIFS.
Eine Festplatte mit 5600 U/Min und weniger als 64MB Cache ist definitiv nicht für einen Fileserver geeignet, es sei den du willst die User mit dem Schneckentempo ärgern. Besser ist 7200 U/Min ab 64 MB Cache aufwärts.
1600 U/Min mehr bedeutet, die Schreibleseköpfe kommen 1600 mal öfter an deinen Daten vorbei und der Lesevorgang kann effizienter abgehandelt werden.

Wir haben hier mehr als einen Cache bzw Buffer. Jede Festplatte hat einen eigenen physikalischen Cache unabhängig vom Betriebsystem.

Die Daten werden vom OS mittels eines Blocklayers (Festplatten sind blockorientierte Geräte) zyklisch geschrieben. Beim Schreib- und Lesevorgang kommt dann der IO-Scheduler ins Spiel. Der IO-Scheduler legt fest, welche Daten wie und in welcher Reihenfolge geschrieben werden.
Unter Linux sind das der CFQ (Completely Fairness Queueing), Deadline und noop. Noop wird z.b. in virtuellen Machinen verwendet, um doppeltes Caching (Hypervisor OS und Gast OS) zu vermeiden.

Deadline wird in der Regel als default Scheduler verwendet.

Darüber liegt dann das Dateisystem. Fast jedes Dateisystem hat einen eigenen Cache und wird auch von dem Dateisystem selbst verwaltet. Das OS kann lediglich die Größe limitieren. Der Cache des Dateisystems liegt im RAM.

Wenn eine Anwendung RAM beim OS anfordert, aber nicht mehr genügend RAM verfügbar ist, dann lagert das OS Teile des RAM's in den Swap aus (sofern den eine Swappartition für Linux angelegt wurde, bei Windows ist es die Auslagerungsdatei) und somit auf die Festplatte aus.

Das kann zu folgender Problematik führen:

Wenn du nicht mehr genügend RAM frei hast, dann kann es durchaus sein, dass Speicherbereiche, die Daten deiner Dateifreigabe enthalten, ausgelagert werden.
Das sorgt für jede menge zeitliche Verzögerungen, weil die mittlere Zugriffszeit (positionieren der Schreib- Leseköpfe, lesen der Daten, etc.) einer Festplatte nicht mal ansatzweise an die Zugriffszeit des RAM heran. Eine Festplatte benötigt x ms für den Zugriff, der RAM benötigt x Nanosekunden.

Daten werden als Blöcke auf die Festplatte geschrieben werden und je nach Zeitverzögerung entstehen so die Ruckler in deiner Aufnahme.

Unter Linux kann mittels Mountoptionen das Verhalten von CIFS für eine zu mountende Freigabe optimiert werden. Dazu gehört z.B. das Cacheverhalten, etc.

Hi,
vielen Dank für die ausführliche Antwort. Bei der Platte würde ich allerdings nicht ansetzen, es ist zwar wirklich eine 5400er aber die "Anwender" sind nur ich und meine Frau mit hauptsächlich Multimediadaten und nie beide gleichzeitig. Die für TV-Aufnahmen zuständige Platte (zum testen kann ich diese auch mal wechseln ist in der Regel um 50% voll und die Aufnahmen sind immer sehr große Dateien, d.h. es werden sich auch viele zusammenhängende freie Bereiche finden lassen. Geschrieben wird immer mit gleicher Datenrate, weit unter dem Maximum der Platte, in jeweils eine Datei über 1-2 Stunden. Auf den Cache komme ich wegen den 30 Sek. weil das ja auch die übliche flush-Rate ist. Der Server hat 2 GB Ram, wenn eine Aufnahme z.B. mit 5-6 MB/Sek. geschrieben wird, dann sollte der Ram nicht volllaufen da der Cache ja weit vorher, nach 30 Sek. geleert wird. Was gibt es noch, dass alle 30 Sek. auftritt und evtl. den Ablauf stört? Der Server hat keine nennenswerte CPU-Last, beim schreiben mit vollem Tempo (also z.B. hochschieben von einer 10 GB Datei von Windows aus) kommen laut top nur 1-2% Last zustande.
>... von CIFS für eine zu mountende Freigabe
Auf dem Server sind keine Freigaben gemountet, es geht nur um die per Samba exportierten Freigaben. Könnte ich hier evtl. etwas optimieren?

Danke

catalpa schrieb:

Auf den Cache komme ich wegen den 30 Sek. weil das ja auch die übliche flush-Rate ist. Der Server hat 2 GB Ram, wenn eine Aufnahme z.B. mit 5-6 MB/Sek. geschrieben wird, dann sollte der Ram nicht volllaufen da der Cache ja weit vorher, nach 30 Sek. geleert wird. Was gibt es noch, dass alle 30 Sek. auftritt und evtl. den Ablauf stört? Der Server hat keine nennenswerte CPU-Last, beim schreiben mit vollem Tempo (also z.B. hochschieben von einer 10 GB Datei von Windows aus) kommen laut top nur 1-2% Last zustande.
>... von CIFS für eine zu mountende Freigabe
Auf dem Server sind keine Freigaben gemountet, es geht nur um die per Samba exportierten Freigaben. Könnte ich hier evtl. etwas optimieren?

Zum Vergrößern anklicken....

Poste mal die Ausgabe von .

Was für Programme hast du sonst noch gestartet? Das beim kopieren einer Datei keine hohe CPU Last verursacht ist normal. Die Menge machts. Die Datei wandert durch den RAM u. es muss dementsprechend ausgelagert werden.

http://www.eggplant.pro/blog/faster-samba-smb-cifs-share-performance/

total used free shared buffers cached
Mem: 1974 1744 229 0 49 1638
-/+ buffers/cache: 56 1917
Swap: 2053 61 1992

es laufen:
Samba
Apache für beets und munin
Avahi (arbeitslos)
und die üblichen Sachen wie ssh usw.
kein xserver

Edit: dein Link habe ich gestern auch schon gefunden, n Tab offen und will es noch probieren...

Ok, Neben den Optionen für Samba kannst du mit folgenden Kernelparametern Einfluss auf das Cachingverhalten, die Zeitabstände der Schreibvorgänge auf die Festplatte,, die max. Anzahl der asynchronen IO Vorgänge ....:

vfs_cache_pressure: Legt fest wieviel Prozent des physikalischen RAM's für Dateisystemcaching verwendet werden darf.
nr_pdflush_threads: Anzahl der pdflush Threads die die Daten auf die Festplatte schreiben

dirty_ratio, dirty_bytes .... : Festlegung, wie viele Bytes and Daten als Dirty (bereit zum schreiben auf die Platte) im RAM vorhanden sein dürfen, wie oft der pdflush die Daten egschreibt usw.

file-max: max. Anzahl geöffneter Filehandles

Im Abschnitt Performance des PDF http://pserver.samba.org/samba/ftp/cifs-cvs/linux-cifs-client-guide.pdf sind die CIFS spezifischen Möglichkeiten zur Performanceoptimierung gut erklärt.

Ich habe die neue 13.2 aufgespielt und eine deutliche Verbesserung festgestellt. Bei verschiedenen Probeaufnahmen von HD-Sendern hatte ich nur bei einer noch die bekannten Ruckler, da ich mit der Softwareseite jetzt wohl durch bin habe ich eben die Platte getauscht. Alte 1TB greenWD gegen etwas neuere 2TB Samsung (letztes Model vor dem Verkauf), wenn es das nicht war tausche ich als nächtes gegen eine WD red 3TB die z.Z. anderweitig genutzt wird. Mache gerade ein paar Aufnahmen und habe noch keine Ruckler gefunden...

Update:
die Ruckler sind noch da, aber viel seltener und nicht mehr regelmäßig. Wenn man kein Timeshifting (gleichzeitiges aufnehmen und abspielen aber zeitversetzt) macht, scheint es o.k. zu sein. Ich denke das liegt jetzt wirklich nur noch am Tempo der platte, der Kopf muss dabei laufend hin&her. Eine Cacheeinstellung die jeweils sehr große Blöcke liest und schreibt wäre gut.

Du kannst den Readahead (vorausschauend lesen) der Festplatte erhöhen. Die Größe des Caches kannst du als Mountoption mitgeben. Um die Perrformance generell zu erhöhen ist ein RAID empfehlenswert. (Software-RAID, muss also kein Hardware RAID sein)