Posso configurare il mio sistema Linux per una cache del file system più aggressiva?


119

Non mi preoccupo né dell'utilizzo della RAM (visto che ne ho abbastanza) né della perdita di dati in caso di spegnimento accidentale (dato che la mia alimentazione è supportata, il sistema è affidabile e i dati non sono critici). Ma faccio un sacco di elaborazione dei file e potrei usare un po 'di aumento delle prestazioni.

Ecco perché mi piacerebbe impostare il sistema in modo da utilizzare più RAM per la memorizzazione e la memorizzazione nella cache del file system, per precaricare i file in modo aggressivo (ad esempio, leggere in anticipo l'intero file a cui accede un'applicazione nel caso in cui il file sia di dimensioni normali o almeno leggere in anticipo un grosso pezzo di esso altrimenti) e svuotare i buffer di scrittura meno frequentemente. Come raggiungere questo obiettivo (può essere possibile)?

Uso i file system ext3 e ntfs (uso molto ntfs!) Con XUbuntu 11.10 x86.


6
Se hai molta RAM, preoccupati molto delle prestazioni e non preoccuparti della perdita di dati, copia tutti i tuoi dati su un disco RAM e servili da lì, scartando tutti gli aggiornamenti in caso di arresto anomalo / arresto. Se ciò non funziona per te, potresti dover qualificarti "abbastanza" per la RAM o quanto i dati non siano critici.
James Youngman,

1
@Nils, il computer è un laptop, quindi, credo, il controller è piuttosto ordinario.
Ivan

1
Un modo per migliorare le prestazioni è saltare la durata dei dati. Disabilita semplicemente la sincronizzazione su disco anche se alcune app richiedono la sincronizzazione. Ciò causerà la perdita di dati se il dispositivo di archiviazione subisce mai una perdita di elettricità. Se vuoi farlo comunque, esegui sudo mount -o ro,nobarrier /path/to/mountpointo modifica semplicemente /etc/fstabper includere nobarrierper qualsiasi filesystem che sei disposto a sacrificare per migliorare le prestazioni. Tuttavia, se il dispositivo di archiviazione ha una batteria interna come la serie SSD Intel 320, l'utilizzo nobarriernon provoca alcuna perdita di dati.
Mikko Rantalainen,

1
L'uso di nobarrier non è più raccomandato in Red Hat Enterprise Linux 6 poiché l'impatto negativo sulle prestazioni delle barriere di scrittura è trascurabile (circa il 3%). I vantaggi delle barriere di scrittura in genere superano i vantaggi in termini di prestazioni della loro disabilitazione. Inoltre, l'opzione nobarrier non dovrebbe mai essere utilizzata su dispositivi di archiviazione configurati su macchine virtuali. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Ivailo Bardarov

1
Due punti - 1) Ci sono distribuzioni Linux basate su Debian o Ubuntu, come Puppy Linux e AntiX Linux, e molti altri che mettono l'intero sistema operativo in partizioni ramdisk a strati (cioè AUFS o overlayfs) e lo gestiscono in modo trasparente. Molto veloce! - 2) Abbiamo scoperto nella progettazione del mondo reale di un sistema molto grande che lanciare più cache può RIDURRE LE PRESTAZIONI. All'aumentare della velocità di archiviazione (ovvero SSD), diminuisce la dimensione ottimale della cache necessaria. Non c'è modo di sapere quale sia quella dimensione senza sperimentazione sul tuo sistema particolare però. Se l'aumento non funziona, prova a ridurlo.
DocSalvager,

Risposte:


107

Migliorare le prestazioni della cache del disco in generale è molto più che aumentare le dimensioni della cache del file system a meno che l' intero sistema non si adatti alla RAM, nel qual caso è necessario utilizzare l'unità RAM ( tmpfsè utile perché consente di ricadere sul disco se in alcuni casi è necessaria la RAM) per l'archiviazione di runtime (e forse uno script initrd per copiare il sistema dall'archiviazione all'unità RAM all'avvio).

Non hai detto se il tuo dispositivo di archiviazione è SSD o HDD. Ecco cosa ho scoperto di funzionare per me (nel mio caso sdaè un HDD montato su /homee sdbSSD montato su /).

Innanzitutto ottimizza la parte load-stuff-from-storage-to-cache:

Ecco la mia configurazione per HDD (assicurati che AHCI + NCQ sia abilitato nel BIOS se hai toggles):

echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda

Vale la pena notare che il caso dell'HDD è elevato fifo_expire_async(di solito in scrittura) e lungo slice_syncper consentire a un singolo processo di ottenere un throughput elevato (impostato slice_syncsu un numero inferiore se si verificano situazioni in cui più processi sono in attesa di alcuni dati dal disco in parallelo). Il slice_idleè sempre un compromesso per HDD, ma l'impostazione da qualche parte nella gamma 3-20 dovrebbe essere a posto a seconda dell'uso del disco e il firmware del disco. Preferisco scegliere come target valori bassi, ma impostandolo su un valore troppo basso si distrugge il rendimento. L' quantumimpostazione sembra influenzare molto il throughput, ma cerca di mantenerlo il più basso possibile per mantenere la latenza a livello ragionevole. L'impostazione su un valore quantumtroppo basso distruggerà il throughput. I valori nell'intervallo 3-8 sembrano funzionare bene con gli HDD. La latenza nel caso peggiore per una lettura è ( quantum* slice_sync) + ( slice_async_rq*slice_async) ms se ho compreso correttamente il comportamento del kernel. L'asincrono viene utilizzato principalmente dalle scritture e poiché sei disposto a ritardare la scrittura su disco, imposta entrambi slice_async_rqe slice_asyncnumeri molto bassi. Tuttavia, l'impostazione di slice_async_rqun valore troppo basso può bloccare le letture perché non è più possibile ritardare le scritture dopo le letture. Il mio config tenterà di scrivere i dati su disco, al massimo dopo 10 secondi dopo che i dati è stata passata al kernel, ma dal momento che si può tollerare la perdita di dati sulla perdita di potenza anche fissati fifo_expire_asynca 3600000dire che 1 ora va bene per il ritardo su disco. Basta tenere slice_asyncbasso, però, perché altrimenti si può ottenere una latenza di lettura elevata.

Il hdparmcomando è necessario per impedire ad AAM di uccidere gran parte delle prestazioni consentite da AHCI + NCQ. Se il tuo disco fa troppo rumore, salta questo.

Ecco la mia configurazione per SSD (serie Intel 320):

echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync

Qui vale la pena notare i valori bassi per le diverse impostazioni della sezione. L'impostazione più importante per un SSD è slice_idleche deve essere impostata su 0-1. Impostandolo su zero, tutte le decisioni relative agli ordini vengono spostate su NCQ nativo mentre l'impostazione su 1 consente al kernel di ordinare le richieste (ma se l'NCQ è attivo, l'hardware potrebbe sovrascrivere parzialmente l'ordinamento del kernel). Prova entrambi i valori per vedere se riesci a vedere la differenza. Per Intel serie 320, sembra che l'impostazione slide_idlea 0dà il meglio di throughput, ma impostandolo 1dà migliore (più basso) la latenza complessiva.

Per ulteriori informazioni su questi parametri sintonizzabili, consultare http://www.linux-mag.com/id/7572/ .

Ora che abbiamo configurato il kernel per caricare roba da disco a cache con prestazioni sensate, è tempo di regolare il comportamento della cache:

Secondo i benchmark che ho fatto, non mi preoccuperei affatto di impostare la lettura in anticipo blockdev. Le impostazioni predefinite del kernel vanno bene.

Impostare il sistema in modo da preferire lo scambio di dati di file rispetto al codice dell'applicazione (questo non importa se si dispone di RAM sufficiente per mantenere l' intero filesystem e tutto il codice dell'applicazione e tutta la memoria virtuale allocata dalle applicazioni nella RAM). Ciò riduce la latenza per lo scambio tra diverse applicazioni rispetto alla latenza per l'accesso a file di grandi dimensioni da una singola applicazione:

echo 15 > /proc/sys/vm/swappiness

Se si preferisce mantenere le applicazioni quasi sempre nella RAM, è possibile impostarlo su 1. Se si imposta questo su zero, il kernel non cambierà affatto a meno che non sia assolutamente necessario per evitare OOM. Se la memoria era limitata e si lavora con file di grandi dimensioni (ad esempio, editing di video HD), potrebbe essere sensato impostare questo valore su 100.

Al giorno d'oggi (2017) preferisco non avere alcun cambio se hai abbastanza RAM. Non avendo alcuno swap di solito si perdono 200-1000 MB di RAM su macchine desktop di lunga durata. Sono disposto a sacrificare così tanto per evitare la latenza dello scenario peggiore (scambiando il codice dell'applicazione quando la RAM è piena). In pratica, ciò significa che preferisco OOM Killer allo scambio. Se si consente / è necessario scambiare, è possibile aumentare /proc/sys/vm/watermark_scale_factoranche per evitare un po 'di latenza. Vorrei suggerire valori compresi tra 100 e 500. È possibile considerare questa impostazione come scambio dell'utilizzo della CPU per una latenza di scambio inferiore. Il valore predefinito è 10 e il massimo possibile è 1000. Un valore più elevato dovrebbe (secondo la documentazione del kernel ) comportare un maggiore utilizzo della CPU per i kswapdprocessi e una minore latenza di scambio complessiva.

Quindi, dire al kernel di preferire mantenere la gerarchia di directory in memoria rispetto al contenuto del file nel caso in cui sia necessario liberare un po 'di RAM (di nuovo, se tutto si adatta alla RAM, questa impostazione non fa nulla):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Ambientazione vfs_cache_pressureil valore basso ha senso perché nella maggior parte dei casi, il kernel deve conoscere la struttura della directory prima di poter utilizzare il contenuto del file dalla cache e svuotare la cache della directory troppo presto renderà la cache del file quasi inutile. Considera di scendere fino a 1 con questa impostazione se hai molti file di piccole dimensioni (il mio sistema ha circa 150K di foto da 10 megapixel e conta come un sistema di "molti file di piccole dimensioni"). Non impostarlo mai su zero o la struttura della directory viene sempre mantenuta in memoria anche se il sistema sta esaurendo la memoria. L'impostazione di questo valore su grande valore è sensata solo se hai solo pochi file di grandi dimensioni che vengono costantemente riletti (di nuovo, un esempio di editing video HD senza RAM sufficiente). La documentazione ufficiale del kernel afferma che "

Eccezione: se hai una quantità davvero enorme di file e directory e raramente tocchi / leggi / elenchi tutti i file con impostazioni vfs_cache_pressuresuperiori a 100 potrebbero essere saggi. Questo vale solo se non si dispone di RAM sufficiente e non è possibile mantenere l'intera struttura di directory nella RAM e avere ancora RAM sufficiente per la normale cache e processi dei file (ad es. File server a livello aziendale con un sacco di contenuti di archivio). Se ritieni di dover aumentare vfs_cache_pressureoltre i 100 stai funzionando senza abbastanza RAM. L'aumento vfs_cache_pressurepuò aiutare, ma l'unica vera soluzione è ottenere più RAM. L' vfs_cache_pressureimpostazione su un numero elevato sacrifica le prestazioni medie per avere prestazioni complessivamente più stabili (vale a dire, è possibile evitare comportamenti peggiori nel caso peggiore, ma è necessario affrontare prestazioni complessive peggiori).

Infine, chiedi al kernel di usare fino al 99% della RAM come cache per le scritture e di indicare al kernel di usare fino al 50% di RAM prima di rallentare il processo che sta scrivendo (il valore predefinito dirty_background_ratioè 10). Avviso: personalmente non lo farei ma tu hai affermato di avere abbastanza RAM e sei disposto a perdere i dati.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

E dì che 1h di ritardo di scrittura è ok anche per iniziare a scrivere cose sul disco (di nuovo, non lo farei):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

Se metti tutti questi /etc/rc.locale includi il seguito alla fine, tutto sarà nella cache il più presto possibile dopo l'avvio (fallo solo se il tuo filesystem si adatta davvero alla RAM):

(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

O un'alternativa un po 'più semplice che potrebbe funzionare meglio (solo cache /homee /usr, fallo solo se il tuo /homee /usrsi adatta davvero alla RAM):

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

3
Una risposta ben informata e nel complesso molto migliore di quella accettata! Questo è sottovalutato ... Immagino che la maggior parte delle persone voglia solo semplici istruzioni senza preoccuparsi di capire cosa fanno davvero ...
Vladimir Panteleev,

2
@Phpdevpad: Inoltre, la domanda diceva "Non sono né preoccupato per l'utilizzo della RAM [...]" - Non credo che nessun dispositivo Maemo sia idoneo.
Mikko Rantalainen il

1
Noop o scadenza non è uno scheduler migliore per gli SSD?
rep_movsd,

1
@rep_movsd Sto usando solo unità SSD Intel, ma almeno queste unità sono ancora abbastanza lente da avere prestazioni complessive migliori con programmatori più intelligenti come CFQ. Immagino che se l'unità SSD è in grado di gestire più di 100.000 IOPS casuali, l'utilizzo di noop o scadenza avrebbe senso anche con CPU veloci. Con "CPU veloce" intendo qualcosa che ha almeno più core 3GHz disponibili solo per IO.
Mikko Rantalainen,

1
Puoi anche leggere questi sintonizzabili su VM dai documenti del kernel di VM .
joeytwiddle,

16

Innanzitutto, NON raccomando di continuare a utilizzare NTFS, poiché l'implementazione di ntfs in Linux sarebbe un problema di prestazioni e sicurezza in qualsiasi momento.

Ci sono diverse cose che puoi fare:

  • usa alcuni nuovi fs come ext4obtrfs
  • prova a cambiare il tuo scheduler io, per esempio bfq
  • disattiva lo scambio
  • usa un preloader automatico come preload
  • usa qualcosa come systemdprecaricare durante l'avvio
  • ... e qualcosa di più

Forse vuoi provarlo :-)


1
Mi sono già trasferito completamente da NTFS a ext4 una volta, lasciando l'unica partizione NTFS ad essere la partizione di sistema di Windows. Ma ha comportato molti inconvenienti per me e sono tornato a NTFS come partizione di dati principale (dove immagazzino tutti i miei documenti, download, progetti, codice sorgente ecc.). Non rinuncio a ripensare la struttura delle mie partizioni e il mio flusso di lavoro (per usare meno Windows) ma in questo momento rinunciare a NTFS non sembra un'opzione realistica.
Ivan

Se devi usare i tuoi dati anche all'interno di Windows, NTFS potrebbe essere l'unica opzione. (molte altre opzioni disponibili se è possibile utilizzare Windows come VM in Linux)
Felix Yan

1
Un riassunto di quali presunti problemi sono di NTFS sarebbe stato utile.
underscore_d

2
NTFS su Linux è praticamente accettabile ad eccezione delle prestazioni. Considerando che la domanda riguardava in particolare il miglioramento delle prestazioni del file system, NTFS dovrebbe essere la prima cosa da fare.
Mikko Rantalainen,

Anche se btrfsè stato recentemente progettato un file system, lo eviterei se sono necessarie prestazioni. Abbiamo eseguito sistemi altrimenti identici con btrfse ext4file system e ext4vince nel mondo reale con un grande margine ( btrfssembra richiedere circa 4x CPU tempo i ext4requisiti per lo stesso livello di prestazioni e provoca più operazioni del disco per un singolo comando logico). A seconda del carico di lavoro, vorrei suggerire ext4, jfso xfsper qualsiasi lavoro che richiedono prestazioni elevate.
Mikko Rantalainen,

8

Continua a leggere:

Su sistemi a 32 bit:

blockdev --setra 8388607 /dev/sda

Su sistemi a 64 bit:

blockdev --setra 4294967295 /dev/sda

Scrivi dietro la cache:

echo 100 > /proc/sys/vm/dirty_ratio

Questo utilizzerà fino al 100% della memoria libera come cache di scrittura.

Oppure puoi fare tutto e usare tmpfs. Questo è rilevante solo se si dispone di RAM sufficiente. Metti questo /etc/fstab. Sostituisci 100G con la quantità di RAM fisica.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Poi:

mkdir /mnt/tmpfs; mount -a

Quindi usa / mnt / tmpfs.


5
Readahead da 3 GB o 2 TB? veramente? Sai cosa fanno queste opzioni?
Cobra_Fast

1
@Cobra_Fast Sai cosa significa? Non ne ho davvero idea e ora sono interessato.
syss,

3
@syss le impostazioni di readahead vengono salvate come numero di "blocchi" di memoria, non byte o bit. La dimensione di un blocco è determinata al momento della compilazione del kernel (poiché i blocchi readahead sono blocchi di memoria) o in alcuni casi al momento della creazione del filesystem. Normalmente, 1 blocco contiene 512 o 4096 byte. Vedi linux.die.net/man/8/blockdev
Cobra_Fast il

6

È possibile impostare la dimensione read-ahead con blockdev --setra sectors /dev/sda1, dove i settori hanno la dimensione desiderata nei settori a 512 byte.


2

La mia impostazione killer è molto semplice e molto efficace:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

La spiegazione dalla documentazione del kernel :

vfs_cache_pressure

Controlla la tendenza del kernel a recuperare la memoria utilizzata per la memorizzazione nella cache degli oggetti directory e inode.

Al valore predefinito di vfs_cache_pressure = 100, il kernel tenterà di recuperare i dentisti e gli inode a un tasso "equo" rispetto a quelli di pagecache e swapcache. La riduzione di vfs_cache_pressure fa sì che il kernel preferisca conservare la cache dentaria e inode. Quando vfs_cache_pressure = 0, il kernel non reclamerà mai odontoiatria e inode a causa della pressione della memoria e questo può facilmente portare a condizioni di memoria insufficiente. L'aumento di vfs_cache_pressure oltre 100 fa sì che il kernel preferisca recuperare odontoiatria e inode.

vfs_cache_pressure a 2000 causa che la maggior parte dell'elaborazione avviene nella RAM e le scritture su disco molto tardi.


4
L'impostazione vfs_cache_pressuretroppo alta (che considererei 2000troppo alta) causerà un accesso al disco non necessario anche per cose semplici come elenchi di directory che dovrebbero essere facilmente inseriti nella cache. Quanta RAM hai e cosa stai facendo con il sistema? Come ho scritto nella mia risposta, l'uso di un valore elevato per questa impostazione ha senso, ad esempio, per l'editing di video HD con RAM limitata.
Mikko Rantalainen,

2
Si noti che la documentazione di riferimento continua: " L'aumento di vfs_cache_pressure in modo significativo oltre 100 potrebbe avere un impatto negativo sulle prestazioni. Il codice di recupero deve richiedere vari blocchi per trovare directory libere e oggetti inode. Con vfs_cache_pressure = 1000, cercherà dieci volte più oggetti disponibili siamo."
Mikko Rantalainen,

1

Non correlato alla scrittura nella cache, ma relativo alle scritture:

  • Per un sistema ext4, è possibile disabilitare il journaling interamente

    Ciò ridurrà il numero di scritture su disco per qualsiasi aggiornamento particolare, ma potrebbe lasciare il file system in uno stato incoerente dopo un arresto imprevisto, che richiede un fsck o peggio.

Per interrompere le letture del disco dall'attivazione delle scritture del disco:

  • Montare con la relatime o noatime opzione

    Quando si legge un file, i metadati dell'ultima ora di accesso per quel file vengono generalmente aggiornati. L' noatimeopzione disabiliterà quel comportamento. Questo riduce le scritture del disco non necessarie, ma non avrai più quei metadati. Alcune distribuzioni (ad esempio Manjaro) lo hanno adottato come predefinito su tutte le partizioni (probabilmente per aumentare la durata dei precedenti SSD del modello).

    relatimeaggiorna il tempo di accesso meno frequentemente, in base alle euristiche che aiutano a supportare le applicazioni che usano l'atime. Questo è il valore predefinito su Red Hat Enterprise Linux.

Altre opzioni:

  • Nei commenti sopra, Mikko ha condiviso la possibilità di montare con l' opzione più nobile . Ma Ivailo ha citato RedHat che lo mette in guardia. Quanto vuoi quel 3% in più?
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.