disco RAM write-through o ingombranti caching del file system?

Question

Ho un programma che sta colpendo molto pesantemente il file system, leggendo e scrivendo su un insieme di file di lavoro. I file hanno dimensioni di diversi gigabyte, ma non così grandi da non adattarsi a un disco RAM. Le macchine su cui gira questo programma sono in genere caselle Linux di Ubuntu.

C'è un modo per configurare il gestore di file per avere una cache molto grande, e anche per scrivere in cache in modo che colpiscano il disco in seguito?

Oppure c'è un modo per creare un disco RAM che scrive attraverso il disco reale?

Answer 1

Per impostazione predefinita, Linux utilizzerà la RAM libera (quasi tutto) per memorizzare gli accessi al disco e ritarderà le scritture. L'euristica utilizzata dal kernel per decidere la strategia di caching non è perfetta, ma batterli in una situazione specifica non è facile. Inoltre, su journalling di filesystem (cioè tutti i filesystem di default al giorno d'oggi), le scritture effettive sul disco verranno eseguite in un modo che resiste agli arresti anomali; questo implica un po 'di spese generali. Potresti voler provare a giocherellare con le opzioni del filesystem. Ad esempio, per ext3, provare a montare con data=writeback o anche async (queste opzioni possono migliorare le prestazioni del filesystem, a scapito della ridotta resilienza verso gli arresti anomali). Inoltre, utilizzare noatime per ridurre l'attività del file system.

A livello di programmazione, è possibile anche eseguire gli accessi al disco tramite i mapping di memoria (con mmap). Questo è un po 'pratico, ma dà più controllo sulla gestione e ottimizzazione dei dati.

Answer 2

Hai controllato se i tuoi dischi stanno utilizzando la cache di scrittura integrata? Può fare una notevole differenza. Su Linux, è possibile alternare il comportamento con hdparm:

/sbin/hdparm -W 0 /dev/hda 0 Disable write caching 
/sbin/hdparm -W 1 /dev/hda 1 Enable write caching 

Ovviamente, se la cache di scrittura è abilitata, allora c'è il rischio di perdita o danneggiamento dei dati se il sistema si spegne non pulito (ad esempio potenza di taglio).

In termini di software, il kernel di Linux utilizza due numeri principali per parametrizzare il comportamento di scrittura.

/proc/sys/vm/dirty_ratio 
/proc/sys/vm/dirty_background_ratio 

default moderni sono di scrivere più frequentemente, per evitare huge write spikes. Potresti provare a sintonizzarli in base alle tue esigenze. Ecco uno excellent discussion dei parametri disponibili e come si potrebbe provare a regolarli.

Answer 3

È possibile creare un ramdisk e RAID-1 con una partizione fisica. Guarda le opzioni --write-prevalentemente e --write-behind. È possibile utilizzare quelli per rendere il disco fisico uno da cui non deve essere letto (solo scritto su) e per impostare il numero di operazioni di scrittura in sospeso, rispettivamente.

In alternativa, consultare la documentazione per pdflush. C'è una buona pagina qui: http://www.westnet.com/~gsmith/content/linux-pdflush.htm (anche collegata da ire_and_curses) Oltre a ciò che ho menzionato, probabilmente vorrai fare lo swappiness fino a 100 per favorire la cache del disco su swap.

Ma vale la pena di imparare come funziona e sintonizzarlo sulla tua app specifica. Linux è già ottimizzato per il caso generale e solo tu sai come si differenzia la tua situazione specifica. :)

Answer 4

Potrebbe essere necessario un disco SSD basato su RAM?

Answer 5

La domanda qui è davvero quanto la durata richiede?

Normalmente Linux userà tranquillamente tanto ram quanto c'è da mettere in cache i file per un po ', quindi scriverà le modifiche. Questo è normalmente quello che vuoi, quindi perderai alcuni dati, ma non troppo, in caso di crash.

Le applicazioni possono ovviamente forzare una riscrittura con (ad esempio) fdatasync() e fsync().

Per ottenere prestazioni migliori, è possibile chiamare fdatasync meno spesso, ad esempio, sacrificando la durata.