Ottimizzazione del comportamento della memorizzazione nella cache del disco Linux per la massima velocità effettiva

Sto riscontrando un problema di throughput massimo qui e ho bisogno di qualche consiglio su come mettere a punto le mie manopole. Stiamo eseguendo un file server a 10 Gbit per la distribuzione di backup. È una configurazione S-ATA2 a due dischi su un controller MegaRAID LSI. Il server ha anche ricevuto 24gig di memoria.

È necessario eseguire il mirroring del nostro ultimo backup caricato con la massima velocità effettiva.

Il RAID0 per i nostri backup "caldi" ci dà circa 260 MB / sec in scrittura e 275 MB / sec in lettura. Un tmpfs testato con dimensioni di 20 GB ci dà circa 1 GB / sec. Questo tipo di throughput è ciò di cui abbiamo bisogno.

Ora come posso sintonizzare il sottosistema di memoria virtuale di Linux per memorizzare nella cache gli ultimi file caricati il più a lungo possibile in memoria senza scriverli sul disco (o ancora meglio: scrivere su disco E tenerli in memoria)?

Ho installato i seguenti sysctls, ma non ci danno il throughput che ci aspettiamo:

# VM pressure fixes
vm.swappiness = 20
vm.dirty_ratio = 70
vm.dirty_background_ratio = 30
vm.dirty_writeback_centisecs = 60000

In teoria, ciò dovrebbe darci 16 GB per la memorizzazione nella cache dell'I / O e attendere alcuni minuti fino alla sua scrittura su disco. Tuttavia, quando eseguo il benchmarking del server non vedo alcun effetto sulla scrittura, la velocità effettiva non aumenta.

Aiuto o consigli necessari.

— Peter Meyer
fonte

Non avrebbe più senso iniziare a scrivere il prima possibile? Altrimenti raggiunge la dimensione massima del buffer e improvvisamente si ferma. Se scriveva da sempre, ti dà più tempo.

— Zan Lynx,

Ho 20 GB di memoria solo per i buffer, poiché le mie applicazioni (base linux + vsftpd) usano meno di 4 GB (totale 24 GB). I miei backup non superano i 20 GB. Se riesco a farli scrivere nel buffer e poi scriverli sul disco in sequenza dopo l'esecuzione del backup, ciò ridurrebbe significativamente i tempi di inattività della mia fonte di backup (server virtuali). PS: il server può arrestarsi in seguito, nessun problema. Ci sono voluti 30 minuti per recuperare :)

— Peter Meyer,

Sembra che qualsiasi applicazione in uso per trasferire i dati in rete li stia sincronizzando sul disco. Avrai voglia di non farlo in modo che i dati possano semplicemente rimanere nella cache, anche se mi chiedo perché vuoi essere in grado di far scoppiare molti dati in quel modo più velocemente di quanto i dischi possano tenere il passo. Ciò indica un difetto di progettazione da qualche parte.

— psusi,

Sembra un difetto: la tua soluzione di backup non dovrebbe richiedere che il server sia spento per tutto il tempo.

— psusi,

@PeterMeyer: anche se hai molta RAM, è ancora un errore attendere l'avvio delle scritture. L'unica volta che ha senso è se stai per modificare o eliminare i file (come un file temporaneo) prima che arrivino sul disco. Un backup non lo fa. Vuoi iniziare le scritture in background il prima possibile. Imposta il tuo background_ratio su 1 o 2.

— Zan Lynx,

Risposte:

Dando un'occhiata alle variabili che hai impostato, sembra che tu sia principalmente interessato alle prestazioni di scrittura e non ti interessi delle possibili perdite di dati dovute a interruzioni di corrente.

Avrai sempre la possibilità di scrivere in modo pigro e di usare una cache di writeback con operazioni di scrittura asincrone. Le operazioni di scrittura sincrona richiedono il commit su disco e non verrebbero mai scritte in modo pigro. Il tuo filesystem potrebbe causare frequenti flush delle pagine e scritture sincrone (in genere a causa del journaling, specialmente con ext3 in modalità data = journal). Inoltre, anche i flush delle pagine "in background" interferiranno con le letture non memorizzate e le scritture sincrone , rallentandole.

In generale, dovresti prendere alcune metriche per vedere cosa sta succedendo - vedi il tuo processo di copia messo nello stato "D" in attesa che il lavoro di I / O venga eseguito da pdflush? Vedi attività di scrittura sincrona pesante sui tuoi dischi?

Se tutto il resto fallisce, potresti scegliere di impostare un filesystem tmpfs esplicito in cui copiare i backup e sincronizzare i dati con i dischi dopo il fatto, anche utilizzando automaticamente inotify

Per quanto riguarda la cache in lettura, le cose sono significativamente più semplici: esiste l' fadviseutility fcoretools che ha il --willneedparametro per avvisare il kernel di caricare il contenuto del file nella cache del buffer.

Modificare:

vm.dirty_ratio = 70

In teoria, ciò dovrebbe darci 16 GB per la memorizzazione nella cache dell'I / O e attendere alcuni minuti fino alla sua scrittura su disco.

Ciò non avrebbe influenzato notevolmente il tuo scenario di test, ma c'è un malinteso nella tua comprensione. Il parametro dirty_ratio non è una percentuale della memoria totale del sistema ma piuttosto della memoria libera del sistema .

C'è un articolo sulla messa a punto di carichi pesanti in scrittura con informazioni più approfondite.

— the-Wabbit
fonte

Sì, sono dopo la performance di scrittura. Il tempo necessario per distribuire il backup agli slave di backup non è una delle mie preoccupazioni. Ho anche predisposto uno script per la ritrasmissione, nel caso in cui il server di backup primario non dovesse funzionare e i backup non passassero agli slave di backup. PS Ho già letto il link e messo a punto di conseguenza. Ci scusiamo per l'errore su libero vs buffer vs totale.

— Peter Meyer,

O semplicemente ottenere più dischi ... La configurazione dell'array di unità che hai non supporta tutto ciò di cui hai bisogno. Questo è un caso in cui la soluzione dovrebbe essere riprogettata per soddisfare le tue reali esigenze. Capisco che questo è solo un backup, ma ha senso evitare una correzione kludgy.

— ewwhite
fonte

Concordato. Non c'è modo che un paio di unità SATA ( SATA ? Seriamente?) Sosterranno 275 MB / s, e non stiamo nemmeno parlando degli abissali IOP che otterrai da loro.

— adattamento

Vedo dove si sta dirigendo: poiché si tratta solo di una destinazione di backup dei dati, non si preoccupa della possibilità di una perdita occasionale di dati a causa di interruzioni di corrente. E vuole ridurre al minimo il tempo necessario per una finestra di backup fornendo il throughput massimo disponibile: 20 GB di dati potrebbero essere scritti in meno di 30 secondi in questo modo. Se per qualche motivo i backup comportano tempi di inattività o impatti sul servizio, 30 secondi sono sicuramente più facili da superare di 20 minuti.

— the-wabbit,

Totalmente bene. Sto sincronizzando le immagini delle macchine virtuali (molto piccole per i nodi di calcolo) che sono inattive durante la sincronizzazione. L'app funziona come tar | ssh ma usando ftp. E bene, le simulazioni devono essere eseguite ... :)

— Peter Meyer,

Non importa quale razza SATA siano. I dischi non aziendali 7200 RPM semplicemente non possono garantire velocità effettiva o latenza.

— adattamento

@adaptr, un backup sarà una scrittura sequenziale.

— psusi,

L'uso della cache di memoria può comportare la perdita di dati come se qualcosa andasse storto, i dati che sono in memoria e non salvati su dischi andranno persi.

Detto questo, ci sono delle ottimizzazioni da fare a livello di filesystem.

Ad esempio, se si utilizza ext4, è possibile provare l'opzione mount:

barriera = 0

Quello: "disabilita l'uso delle barriere di scrittura nel codice jbd. Le barriere di scrittura impongono un corretto ordinamento su disco dei commit dei journal, rendendo sicure le cache di scrittura del disco volatile da usare, con qualche penalità di prestazione. Se i dischi sono supportati da batteria in un modo oppure, disabilitare le barriere può migliorare in modo sicuro le prestazioni. Le opzioni di montaggio "barriera" e "nobarrier" possono anche essere utilizzate per abilitare o disabilitare le barriere, per coerenza con altre opzioni di montaggio ext4 ".

Maggiori informazioni su: http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt

— Peter Senna
fonte

Sto usando un XFS fortemente sintonizzato. Maggiori informazioni a riguardo sono sintonizzati nel commento sopra :)

— Peter Meyer,

Il filesystem è stato creato con mkfs.xfs -l lazy-count = 1, version = 2, size = 256m -i attr = 2 -d sunit = 512, swidth = 1024 ed è montato con: rw, noatime, logbufs = 8, logbsize = 256k, osyncisdsync, delaylog, attr2, nobarrier, allocsize = 256k

— Peter Meyer