Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
Performance Tuning Guide
Ottimizzazione produttività del sottosistema con Red Hat Enterprise Linux 6
Edizione 4.0
Red Hat Esperto del settore
A cura di
Don Domingo
A cura di
Laura Bailey
Sommario
Capitolo 1. Panoramica
- Funzioni
- Ogni capitolo descrive funzioni uniche relative alle prestazioni (o implementate diversamente) di Red Hat Enterprise Linux 6. Questi capitoli affrontano altresì gli aggiornamenti di Red Hat Enterprise Linux 6 in grado di migliorare sensibilmente le prestazioni di sottosistemi specifici di Red Hat Enterprise Linux 5.
- Analisi
- Questa guida elenca anche gli indicatori di prestazione per ogni sottosistema specifico. Valori tipici per questi indicatori sono descritti nel contesto di servizi specifici, aiutando così l'utente a capire il significato reale dei sistemi di produzione.La Performance Tuning Guide mostra altresì metodi diversi per il ripristino dei dati sulle prestazioni (ad esempio il profiling) per un sottosistema. Da notare che alcuni degli strumenti usati per il profiling sono documentati in modo più dettagliato in altre sezioni.
- Configurazione
- Le informazioni più importanti presenti in questo libro sono quelle relative alla regolazione delle prestazioni di un sottosistema specifico in Red Hat Enterprise Linux 6. La Performance Tuning Guide spiega come ottimizzare un sottosistema di Red Hat Enterprise Linux 6 per servizi specifici.
1.1. A chi è rivolto
- Esperti Business/Sistema
- Questa guida descrive in modo molto dettagliato le funzioni delle prestazioni di Red Hat Enterprise Linux 6, e fornisce informazioni sufficienti per sottosistemi in presenza di carichi di lavoro specifici (sia per impostazioni predefinite che per quelle ottimizzate). Il livello di descrizione usato per le funzioni delle prestazioni con Red Hat Enterprise Linux 6, aiuta gli utenti e gli esperti informatici alla comprensione sull'idoneità di questa piattaforma a fornire servizi che utilizzano un numero elevato di risorse ad un livello accettabile.Quando possibile la Performance Tuning Guide fornisce i collegamenti per una documentazione più dettagliata su ogni funzione. Queste informazioni aiutano i lettori a capire le funzioni in modo da poter sviluppare una strategia idonea ad una implementazione e ottimizzazione di Red Hat Enterprise Linux 6. Ciò permetterà agli utenti di sviluppare ed esaminare eventuali infrastrutture.Questo livello di informazioni è rivolto a utenti con una conoscenza dettagliata dei sottosistemi Linux e delle reti di livello enterprise.
- Amministratori di sistema
- Le procedure presenti in questo libro sono idonee per amministratori di sistema con un livello tecnico RHCE [1] (o equivalente, e cioè, con 3-5 anni di esperienza nell'implementazione e gestione dei sistemi Linux). La Performance Tuning Guide cerca di riportare un numero consistente di informazioni sugli effetti riscontrabili con ogni tipo di configurazione; ciò significa descrivere ogni tipo possibile di compromesso.La chiave sulla comprensione corretta di un processo di ottimizzazione delle prestazioni non è su come analizzare e regolare un sottisistema, ma conoscere come bilanciare e ottimizzare un sistema Red Hat Enterprise Linux 6 per uno scopo ben preciso. Ciò significa anche essere a conoscenza su quali compromessi e restrizioni siano accettabili, quando si implementa un tipo di configurazione da implementare per aumentare le prestazioni di un sistema specifico.
1.2. Scalabilità orizzontale
1.2.1. Elaborazione parallela
1.3. Sistemi distribuiti
- Comunicazione
- La scalabilità orizzontale richiede l'esecuzione simultanea di numerosi compiti (in parallelo). Per questo motivo i suddetti compiti devono essere in comunicazione tra loro per coordinare il lavoro. A tale scopo una piattaforma con scalabilità orizzontale dovrebbe essere in grado di condividere i compiti su sistemi multipli.
- Storage
- Per soddisfare i requisiti di scalabilità orizzontale non è sufficiente implementare uno storage tramite i dischi locali. È necesario usare uno storage condiviso o distribuito, uno con un livello di astrazione che permetta alla capacità di un volume di storage singolo, di aumentare con l'aggiunta di nuovo hardware di storage.
- Gestione
- Il copito più importante di una elaborazione distribuita è il livello di gestione. Questo livello coordina tutti i componenti hardware e software, gestisce in modo efficiente le comunicazioni, lo storage e l'uso di risorse condivise.
1.3.1. Comunicazione
- Hardware
- Software
Il modo più comune per una comunicazione tra computer è attraverso Ethernet. Al giorno d'oggi Gigabit Ethernet (GbE) è presente sui sistemi per impostazione predefinita, e numerosi server includono 2-4 porte di Gigabit Ethernet. GbE fornisce una buona larghezza di banda e latenza, le quali risultano essere la base di numerosi sistemi distribuiti in uso. Anche in presenza di sistemi con hardware di rete più veloce, è ancora comune l'uso di GbE come interfaccia di gestione.
Ten Gigabit Ethernet (10GbE) è attualmente in rapida crescita ed è sempre più accettato in server mid-range e high end. 10GbE fornisce una larghezza di banda dieci volte maggiore rispetto a GbE. Se siete in possesso di un processore multi-core moderno sarà possibile usufruire della possibilità di ripristinare l'equilibrio tra comunicazione e processazione. È possibile confrontare un sistema a core singolo usando GbE ad un sistema con otto core usando 10GbE. Usato in questo modo 10GbE è molto utile per il mantenimento delle prestazioni generali del sistema, riducendo eventuali limitazioni durante le comunicazioni.
Infiniband offre prestazioni ancora più elevate di 10GbE. In aggiunta a collegamenti di rete UDP e TCP/IP usati con Ethernet, Infiniband supporta anche una comunicazione della memoria condivisa. Ciò permette a Infiniband di operare tra sistemi tramite un remote direct memory access (RDMA).
RDMA over Ethernet (RoCCE) implementa comunicazioni simili a Infiniband (incluso RDMA) attraverso una infrastruttura 10GbE. A causa della riduzione dei costi associati con un aumento dei prodotti 10GbE, è possibile prevedere un uso più esteso di RDMA e RoCCE su un certo numero di sistemi e applicazioni.
1.3.2. Storage
- Sistemi multipli che archiviano dati in una singola posizione
- Una unità di storage (es. un volume) composto da elementi di storage multipli
Network File System (NFS) permette a utenti o server di montare e usare la stessa istanza di storage remoto tramite TCP o UDP. NFS viene usato per contenere i dati condivisi da applicazioni multiple. Esso è conveniente per l'archiviazione di un numero molto grande di dati.
Storage Area Networks (SAN) utilizza un protocollo iSCSI o un Fibre Channel per fornire un accesso remoto allo storage. L'infrastruttura del Fibre Channel (come ad esempio gli adattatori host bus Fibre Channel, interruttori e storage array) uniscono una elevata prestazione, larghezza di banda e uno storage molto grande. Le SAN separano lo storage della processazione e forniscono una elevata flessibilità durante la creazione del sistema.
- Controllo accesso allo storage
- Gestione di quantità molto grandi di dati
- Provisioning dei sistemi
- Backup e riproduzione dei dati
- Esecuzione di istantanee
- Supporto del failover dei sistemi
- Assicurazione integrità dei dati
- Migrazione dei dati
Il file system Global File System 2 (GFS2) di Red Hat fornisce diverse capacità specifiche. La funzione di base di GFS2 è quella di fornire un file system singolo, incluso un accesso lettura/scrittura simultaneo condiviso su membri multipli di un cluster. Ciò significa che ogni membro del cluster visualizza esattamente gli stessi dati "sul disco" nel file system GFS2.
1.3.3. Reti convergenti
Con FCoE i comandi del fibre channel standard e i pacchetti dati vengono trasportati attraverso una infrastruttura fisica di 10GbE tramite un converged network card (CNA) singolo. Il traffico ethernet TCP/IP standard e le operazioni di storage del fibre channel possono essere trasportati usando lo stesso link. FCoE utilizza una scheda dell'interfaccia di rete fisica (ed un cavo) per connessioni storage/rete logiche multiple
- Numero ridotto di connessioni
- FCoE riduce della metà i numeri delle connessioni di rete ad un server. Per ragioni di disponibilità e prestazioni è ancora possibile selezionare connessioni multiple; tuttavia una singola connessione è in grado di fornire sia una connettività di rete che una di storage. Questa impostazione è specialmente utile per server pizza box e blade poichè entrambi presentano uno spazio limitato per i componenti.
- Costo più basso
- Una riduzione immediata delle connessioni significa ridurre anche il numero di cavi, interruttori e altri strumenti di rete. Ethernel dispone anche di una vasta gamma di dispositivi; il costo delle reti diminuisce drammaticamente a causa di un aumento del numero da milioni a miliardi di dispositivi, una conferma di quanto detto la si ha nella riduzione del costo dei dispositivi Ethernet 100Mb e gigabit.In modo simile 10GbE saranno meno costosi in futuro a causa di un loro maggior uso. Con implementazioni sempre più numerose di hardware CNA con singoli chip, sarà possibile aumentarne il loro volume nel mercato, riducendone così i costi.
Internet SCSI (iSCSI) è un altro tipo di protocollo di rete convergente; Esso rappresenta una alternativa a FCoE. Come il fibre channel, iSCSI fornisce uno storage di livello del blocco attraverso una rete. Tuttavia iSCSI non fornisce un ambiente di gestione completo. Il vantaggio principale di iSCSI rispetto a FCoE è quello di fornire gran parte delle capacità e flessibilità di fibre channel, ma a costi più bassi.
Capitolo 2. Funzioni per le prestazioni di Red Hat Enterprise Linux 6
2.1. Supporto 64-bit.
- Huge pages e transparent huge pages
- Miglioramenti Non-Uniform Memory Access (NUMA)
L'implementazione delle huge pages con Red Hat Enterprise Linux 6 permette al sistema di gestire l'uso della memoria in modo efficiente in presenza di diversi carichi di lavoro. Le Huge pages utilizzano dinamicamente pagine di 2 MB rispetto allo standard di 4 KB, permettendo alle applicazioni di scalare correttamente durante la processazione dei gigabyte e terabyte di memoria.
Numerosi sistemi moderni supportano ora il Non-Uniform Memory Access (NUMA). NUMA semplifica il design e la creazione di hardware di sistemi molto grandi; tuttavia esso aggiunge un livello di complessità allo sviluppo delle applicazioni. Per esempio, NUMA implementa sia la memoria locale che quella remota, quest'ultima impiega un periodo più lungo per l'accesso rispetto alla memoria locale. Questa funzione (insieme ad altre) presenta alcune problematiche relative alle prestazioni dei sistemi operativi, applicazioni e delle configurazioni del sistema.
2.2. Ticket Spinlocks
2.3. Struttura elenco dinamico
2.4. Tickless Kernel
2.5. Gruppi di controllo
- Un elenco di compiti assegnati al cgroup
- Risorse assegnate ai suddetti compiti
- CPUsets
- Memoria
- I/O
- Rete (larghezza di banda)
2.6. Miglioramenti del file system e storage
Ext4 è il file system predefinito di Red Hat Enterprise Linux 6 e risulta essere la quarta generazione della famiglia di file system EXT. Grazie alla sua introduzione è ora possibile avere una dimensione teorica massima del file system pari a 1 exabyte (non supportata da Red Hat), e una dimensione massima per un file singolo di 16TB. Red Hat Enterprise Linux 6 supporta una dimensione massima del file system pari a 16TB ed una dimensione massima per file singolo di 16TB. Insieme ad una capacità di storage molto più grande, ext4 include anche diverse nuove funzioni come ad esempio:
- Metadati basati sulle estensioni
- Assegnazione ritardata
- Journal check-summing
XFS è un file system con journal maturo e robusto in grado di supportare file system e file molto grandi su un singolo host. Questo file system è stato originariamente creato da SGI ed è stato usato in modo esteso su server molto grandi e storage array. Le funzioni di XFS includono:
- Assegnazione ritardata
- Inode assegnati dinamicamente
- indicizzazione B-tree per una scalabilità della gestione di spazio disponibile
- Aumento del file system e deframmentazione online
- Algoritmi read-ahead per metadati sofisticati
Un BIOS tradizionale supporta una dimensione massima del disco pari a 2.2TB. I sistemi Red Hat Enterprise Linux 6 che utilizzano un BIOS sono in grado di supportare dischi più grandi di 2.2TB, attraverso l'utilizzo di una nuova struttura chiamata Global Partition Table (GPT). GPT può essere usato solo per dischi dati e non può essere usato per unità d'avvio con BIOS; per questo motivo le suddette unità possono avere una dimensione massima di 2.2TB. Il BIOS è stato creato originariamente da IBM PC; mentre il BIOS si è evoluto in modo da essere adattato all'hardware moderno, Unified Extensible Firmware Interface (UEFI) è stato creato per supportare hardware emergente.
Importante
Importante
Capitolo 3. Monitoraggio ed Analisi delle prestazioni del sistema
3.1. File system proc
proc
è una directory che contiene una gerarchia di file che rappresentano lo stato corrente del kernel di Linux. Esso permette alle applicazioni e agli utenti di visualizzare una panoramica del sistema del kernel.
proc
contiene anche le informazioni relative all'hardware del sistema e di qualsiasi processo attualmente in esecuzione. La maggior parte di questi file sono di sola-lettura, ma alcuni file (principalmente quelli in /proc/sys
) possono essere manipolati da utenti e da applicazioni, per la comunicazione al kernel delle modifiche sulla configurazione.
proc
consultare la Deployment Guide disponibile su http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
3.2. GNOME e KDE System Monitors
Il GNOME System Monitor mostra informazioni di base e permette di monitorare l'uso dei processi, risorse e file system del sistema. Apritelo usando il comando gnome-system-monitor
nel Terminal, o selezionare nel menu Applicazioni e Strumenti del sistema > Monitor del sistema.
- Sistema
- Mostra le informazioni di base sul software e hardware del computer.
- Processi
- Mostra i processi attivi e il rapporto tra i suddetti processi insieme alle informazioni dettagliate di ogni processo. Permette altresì di filtrare i processi ed eseguire determinate azioni (avvio,arresto, kill, modifica della priorità ecc.).
- Risorse
- Mostra l'uso del tempo della CPU corrente, l'uso della memoria e dello spazio di swap e della rete.
- File System
- Elenca tutti i file system montati insieme alle informazioni di base su ognuno di essi, come ad esempio il tipo di file system, il mount point e l'uso della memoria.
KDE System Guard permette di controllare i processi in esecuzione ed il carico del sistema corrente. Permette altresì di eseguire azioni nei confronti dei processi. A tale scopo usate il comando ksysguard
nel Terminal, o selezionate Lancia applicazioni e successivamente Applicazioni > Sistema > Controlla sistema.
- Tabella processo
- Per impostazione predefinita mostra un elenco di tutti i processi in esecuzione in ordine alfabetico. È possibile ordinare i processi prendendo in considerazione un certo numero di fattori, incluso l'uso della CPU totale, utilizzo della memoria condivisa o fisica, proprietario, e priorità. È possibile altresì filtrare i risultati visibili, eseguire una ricerca per processi specifici o eseguire determinate azioni su un processo.
- Carico del sistema
- Mostra una cronologia grafica sull'utilizzo della CPU, sull'uso dello spazio di swap, della memoria e della rete. Posizionate il mouse sopra i grafici per una analisi dettagliata.
3.3. Strumenti di monitoraggio della linea di comando interni
top
top fornisce una panoramica dinamica in tempo reale dei processi in esecuzione sul sistema. Esso è in grado di mostrare una varietà di informazioni incluso il sommario del sistema, i compiti gestiti dal kernel di Linux e presenta una limitata abilità di manipolare i processi. Sia le informazioni che le operazioni riportate sono altamente configurabili, e qualsiasi informazione sulla configurazione può essere resa persistente durante i riavvii.
man top
.
ps
ps esegue una istantanea di un gruppo selezionato di processi attivi. Per impostazione predefinita questo gruppo è limitato ai processi posseduti dall'utente corrente ed associato con lo stesso terminale.
man ps
.
vmstat
vmstat (Virtual Memory Statistics) esegue l'output di notifiche istantanee sulla memoria, paging, I/O del blocco, interrupt, attività della CPU e processi del sistema.
man vmstat
.
sar
sar (System Activity Reporter) raccoglie e riporta le informazioni sull'attività del sistema giornaliera. L'output predefinito riporta l'uso giornaliero della CPU ad un intervallo di dieci minuti dall'inizio del giorno:
12:00:01 AM CPU %user %nice %system %iowait %steal %idle 12:10:01 AM all 0.10 0.00 0.15 2.96 0.00 96.79 12:20:01 AM all 0.09 0.00 0.13 3.16 0.00 96.61 12:30:01 AM all 0.09 0.00 0.14 2.11 0.00 97.66 ...
man sar
.
3.4. Tuned e ktune
default
- Il profilo di risparmio energetico predefinito. Questo è il profilo di base e abilita solo i plug-in CPU e del disco. Da notare che questo non è simile alla disabilitazione di tuned-adm dove sia tuned che ktune sono disabilitati.
latency-performance
- Un profilo server per l'ottimizzazione delle prestazioni della latenza. Disabilita i maccanismi di risparmio energetico tuned e ktune. La modalità
cpuspeed
varia inperformance
. Per ogni dispositivo l'I/O elevator viene modificato indeadline
. Per la qualità del servizio di gestione dell'alimentazione, viene registrato il valore0
dicpu_dma_latency
. throughput-performance
- Un profilo server per l'ottimizzazione tipica delle prestazioni di output netto. Questo profilo è consigliato se il sistema non presenta alcuno storage di classe enterprise. Simile a
latency-performance
ad eccezione:kernel.sched_min_granularity_ns
(scheduler minimal preemption granularity) è impostato su10
millisecondi,kernel.sched_wakeup_granularity_ns
(scheduler wake-up granularity) impostato su15
millisecondi,vm.dirty_ratio
(virtual machine dirty ratio) impostato su 40%, e- le transparent huge pages sono abilitate.
enterprise-storage
- Questo profilo è consigliato per configurazioni del server con dimensioni enterprise con uno storage di classe enterprise, inclusa una protezione della cache del controller con un backup tramite batteria ed una gestione della cache su-disco. Simile al profilo
throughput-performance
, con una eccezione: i file system sono rimontati conbarrier=0
. virtual-guest
- Questo profilo è consigliato per configurazioni del server di dimensioni enterprise con uno storage di classe enterprise, inclusa una protezione della cache del controller con un backup tramite batteria ed una gestione della cache su-disco. Simile al profilo
throughput-performance
, ad eccezione:readahead
valore impostato su4x
, e- file system non root/boot rimontati con
barrier=0
.
virtual-host
- In base al profilo
enterprise-storage
,virtual-host
diminuisce anche la tendenza allo swap della memoria virtuale e abilita un writeback più aggressivo di pagine non ancora salvate. Questo profilo è disponibile in Red Hat Enterprise Linux 6.3 e versioni più recenti, ed è il profilo consigliato per gli host di virtualizzazione, incluso gli host di KVM e Red Hat Enterprise Virtualization.
3.5. Profiler dell'applicazione
3.5.1. SystemTap
3.5.2. OProfile
- Gli esempi di monitoraggio delle prestazioni potrebbero non essere precisi - poichè il processore può eseguire le istruzioni in ordine sparso, un esempio potrebbe essere registrato da una qualsiasi altra istruzione vicina, e non utilizzare l'istruzione che ha innescato l'interrupt.
- Poichè OProfile può essere usato dall'intero sistema e al tempo stesso prevede avvii e arresti multipli dei processi, sarà possibile archiviare un certo numero di esecuzioni. A tale scopo sarà necessario rimuovere i dati d'esempio relativi alle esecuzioni precedenti.
- Utilizzato principalmente per identificare i problemi con i processi CPU-limitati, e per questo motivo non è in grado di identificare i processi sospesi "sleeping" in attesa di blocchi per altri eventi.
/usr/share/doc/oprofile-<version>
.
3.5.3. Valgrind
man valgrind
se avete installato il pacchetto valgrind. Ulteriore documentazione è disponibile anche in:
/usr/share/doc/valgrind-<version>/valgrind_manual.pdf
/usr/share/doc/valgrind-<version>/html/index.html
3.5.4. Perf
perf stat
- Fornisce statistiche generali per eventi normali delle prestazioni, incluso le istruzioni eseguite ed i cicli di orologio consumati. È possibile usare altresì i flag dell'opzione per ottenere i dati sugli eventi diversi da quelli di misurazione predefiniti. Con Red Hat Enterprise Linux 6.4 è possibile utilizzare
perf stat
per filtrare il monitoraggio in base a uno o più control groups (cgroups). Per maggiori informazioni consultare la pagina man:man perf-stat
. perf record
- Registra i dati sulle prestazioni in un file analizzabile tramite
perf report
. Per maggiori informazioni consultare la pagina man:man perf-record
. perf report
- Consulta i dati delle prestazioni da un file e analizza i dati registrati. Per maggiori informazioni consultare la pagina man:
man perf-report
. perf list
- Elenca gli eventi disponibili su una macchina specifica. Questi eventi varieranno in base alla configurazione software e all'hardware di monitoraggio delle prestazioni del sistema. Per maggiori informazioni consultare la pagina man:
man perf-list
. perf top
- Questo comando esegue una funzione simile a top. Esso è in grado di generare e visualizzare un profilo del contatore delle prestazioni in tempo reale. Per maggiori informazioni consultare la pagina man:
man perf-top
.
3.6. Red Hat Enterprise MRG
- Parametri BIOS relativi alla gestione energetica, rilevamento dell'errore e interruzioni per la gestione del sistema;
- Impostazioni della rete, come la funzione di ricezione dell'interruzione e l'uso di TCP;
- Attività del journaling nei file system
- Registrazione del sistema;
- Gestione delle interruzioni e dei processi dell'utente da parte di CPU specifiche o gruppo di CPU;
- Utilizzo dello spazio di swap, e
- Come comportarsi in presenza di eccezioni di uno stato out-of-memory.
Capitolo 4. CPU
Tipoligia
Thread
interrupt
4.1. Tipologia della CPU
4.1.1. Tipologia NUMA e CPU
- Bus seriali
- Tipologie NUMA
- Cos'è la tipologia del sistema?
- Dov'è l'applicazione attualmente eseguita?
- Dov'è l'insieme di memoria più vicino?
4.1.2. Ottimizzazione delle prestazioni della CPU
- Una CPU (qualsiasi tra 0-3) presenta un indirizzo per il controller della memoria locale.
- Il controller della memoria imposta un accesso per l'indirizzo.
- La CPU esegue operazioni di lettura o scrittura sull'indirizzo della memoria.
Figura 4.1. Accesso alla memoria locale e remota con NUMA
- Una CPU (qualsiasi tra 0-3) presenta un indirizzo della memoria remota per il controller della memoria locale.
- La richiesta di una CPU per l'indirizzo della memoria locale viene passato ad un controller della memoria remota, locale al nodo che contiene quell'indirizzo.
- Il controller della memoria remota imposta un accesso per l'indirizzo della memoria remota.
- La CPU esegue operazioni di lettura o scrittura sull'indirizzo della memoria remota.
- la tipologia del sistema (collegamento dei componenti)
- il core sul quale viene eseguita l'applicazione, e
- la posizione dell'insieme di memoria più vicino.
4.1.2.1. Impostazione affinità della CPU con taskset
0x00000001
rappresenta il processore 0 e 0x00000003
rappresenta i processori 0 e 1.
# taskset -p mask pid
# taskset mask -- program
-c
per fornire un elenco delimitato da virgole di processori separati, o di una gamma di processori:
# taskset -c 0,5,7-9 -- myprogram
man taskset
.
4.1.2.2. Controllo politica di NUMA con numactl
numactl
esegue i processi con una programmazione specifica o utilizzando una politica di posizionamento della memoria. La politica selezionata viene impostata per quel processo e per tutti i suoi processi figlio. numactl
è in grado altresì di impostare una politica persistente per segmenti di memoria condivisi o file, e l'affinità della CPU e della memoria di un processo. Per determinare la tipologia del sistema esso utilizza il file system /sys
.
/sys
contiene informazioni utili sul collegamento delle CPU, memoria e dispositivi periferici con le interconnessioni NUMA. In modo specifico la directory /sys/devices/system/cpu
contiene le informazioni sul collegamento delle CPU di un sistema. La directory /sys/devices/system/node
contiene le informazioni sui nodi NUMA presenti nel sistema e sulle distanze che intercorrono tra i nodi.
--show
- Mostra le impostazioni della politica NUMA del processo corrente. Questo parametro non ha bisogno di parametri aggiuntivi e può essere usato nel modo seguente:
numactl --show
. --hardware
- Mostra un inventario dei nodi disponibili sul sistema.
--membind
- Assegna solo la memoria dai nodi specificati. Se in uso, il processo di assegnazione fallirà se la memoria sui nodi in questione non è sufficiente. Il formato per questo parametro è
numactl --membind=nodes program
, dove nodes è l'elenco dei nodi usati per assegnare la memoria e program è il programma usato per i requisiti di memoria che i nodi dovranno assegnare. È possibile indicare i numeri dei nodi con un elenco separato da virgole, una gamma o una combinazione dei due. Maggiori informazioni sono disponibili sulle pagine man di numactl:man numactl
. --cpunodebind
- Esegue solo un comando (e i processi figli relativi) sulle CPU che appartengono ai nodi specificati. Il formato di questo parametro è il seguente
numactl --cpunodebind=nodes program
, dove nodes è l'elenco dei nodi specificati usati per indicare le CPU per l'assegnazione dei programmi desiderati (program). È possibile indicare i numeri dei nodi con un elenco separato da virgole, una gamma o una combinazione dei due. Maggiori informazioni sono disponibili sulle pagine man di numactl:man numactl
. --physcpubind
- Esegue solo un comando (e i processi figli relativi) sulle CPU specificate. Il formato di questo parametro è il seguente
numactl --physcpubind=cpu program
, dove cpu è l'elenco delimitato da virgole dei numeri delle CPU fisiche, come riportato nei campi dei processori di/proc/cpuinfo
, e program è il programma da eseguire solo sulle CPU in questione. È possibile specificare le CPU in relazione alcpuset
corrente. Consultare le pagine man di numactl per maggiori informazioni:man numactl
. --localalloc
- Specifica che la memoria deve sempre essere assegnata sul nodo corrente.
--preferred
- Quando possibile assegna la memoria sul nodo specificato, In caso contrario usare altri nodi. Questa opzione accetta solo il numero di un singolo nodo, come ad esempio:
numactl --preferred=node
. Consultare la pagina man di numactl per maggiori informazioni:man numactl
.
man numa(3)
.
4.1.3. numastat
Importante
numastat
senza alcuna opzione o parametri) mantiene una compatibilità con la versione precedente, l'uso di opzioni o parametri con questo comando modificherà sensibilmente il formato e il contenuto dell'output.
numastat
mostra il numero di pagine di memoria occupate dalle seguenti categorie di eventi per ogni nodo.
numa_miss
e numa_foreign
bassi.
Categorie di verifica predefinite
- numa_hit
- Numero di tentativi di assegnazione riusciti per il nodo.
- numa_miss
- Numero di tentativi di assegnazione ad un altro nodo allocati a questo nodo a causa di una quantità di memoria limitata sul nodo desiderato. Ogni evento
numa_miss
ha un eventonuma_foreign
corrispondente su un altro nodo. - numa_foreign
- Numero di assegnazioni intese inizialmente per questo nodo allocate invece ad un altro nodo. Ogni evento
numa_foreign
ha un eventonuma_miss
su un altro nodo. - interleave_hit
- Numero di tentativi di assegnazione della politica interleave per questo nodo che hanno avuto successo.
- local_node
- Numero di volte che un processo sul nodo ha assegnato con successo la memoria a questo nodo.
- other_node
- Numero di volte che un processo su un altro nodo ha assegnato la memoria a questo nodo.
-c
- Riduce orizzontalmente la tabella delle informazioni. Utile su sistemi con un numero molto grande di nodi NUMA, ma lo spazio tra colonne e la loro larghezza può essere imprevedibile. Usando questa opzione la quantità di memoria viene approssimata al megabyte per vicino.
-m
- Mostra le informazioni sull'uso della memoria dell'intero sistema in base al nodo. Simile alle informazioni disponibili in
/proc/meminfo
. -n
- Mostra le stesse informazioni del comando originale
numastat
(numa_hit, numa_miss, numa_foreign, interleave_hit, local_node, and other_node), con un formato aggiornato, usando i megabyte come unità di misura. -p pattern
- Mostra le informazioni della memoria per-node per il pattern specificato. Se il valore di pattern è composto da cifre, numastat assume che si tratti di un identificatore di un processo numerico. In caso contrario numastat ricerca le righe del comando del processo per il pattern specificato.Gli argomenti della linea di comando inseriti dopo il valore dell'opzione
-p
vengono considerati pattern aggiuntivi da filtrare. Pattern aggiuntivi aumentano e non diminuiscono i criteri di filtraggio. -s
- Riporta i dati visualizzati in ordine decrescente in modo da riportare prima le utenze più grandi della memoria (in base alla colonna
total
).Facoltativamente specificare node, così facendo la tabella verrà ordinata in base ai valori della colonna node. Con questa opzione il valore di node deve seguire immediatamente l'opzione-s
come mostrato qui di seguito:numastat -s2
Non includere alcuno spazio tra questa opzione ed il proprio valore. -v
- Mostra informazioni più verbose. Le informazioni per processi multipli mostreranno informazioni dettagliate per ogni processo.
-V
- Mostra le informazioni sulla versione di numastat.
-z
- Omette dalle informazioni visualizzate le colonne e le righe della tabella con un valore zero. Da notare che valori vicini allo zero approssimati a zero per facilitare la visualizzazione, non saranno omessi dall'output.
4.1.4. NUMA Affinity Management Daemon (numad)
/proc
, per controllare la disponibilità delle risorse in base al nodo. Successivamente il demone cercherà di posizionare un numero consistente di processi sui nodi NUMA con una memoria sufficientemente allineata e in possesso di risorse della CPU, in modo da avere una prestazione ottimale. Attualmente i limiti per la gestione dei processi sono di un minimo del 50% di una CPU e di almeno 300 MB di memoria. numad cerca di mantenere un livello di utilizzo delle risorse, bilanciando le assegnazioni spostando i processi tra i nodi NUMA.
-w
per una assistenza pre-assegnazione: man numad
.
4.1.4.1. Benefici di numad
4.1.4.2. Modalità di operazione
Nota
- come un servizio
- come un eseguibile
4.1.4.2.1. Usare numad come servizio
# service numad start
# chkconfig numad on
4.1.4.2.2. Usare numad come eseguibile
# numad
/var/log/numad.log
.
# numad -S 0 -p pid
-p pid
- Aggiunge il pid specifico ad un elenco di inclusione esplicito. Il processo specificato non verrà gestito fino a quando non soddisfa il limite significativo del processo numad.
-S mode
- Il parametro
-S
specifica il tipo di scansione. Impostando0
, la gestione di numad verrà limitata a processi esplicitamente inclusi.
# numad -i 0
man numad
.
4.2. Programmazione della CPU
- Politiche realtime
- SCHED_FIFO
- SCHED_RR
- Politiche normali
- SCHED_OTHER
- SCHED_BATCH
- SCHED_IDLE
4.2.1. Politiche per una programmazione di tipo realtime
SCHED_FIFO
- Questa politica viene anche chiamata static priority scheduling poichè essa definisce una priorità fissa (tra 1 e 99) per ogni thread. Lo scheduler esegue la scansione di un elenco di thread SCHED_FIFO seguendo un ordine di priorità, e programma il thread con la priorità più alta pronto ad essere eseguito. Il thread verrà eseguito, arrestato, abbandonato o preceduto da un altro thread con priorità più alta.Anche un thread realtime con priorità più bassa verrà programmato prima di qualsiasi altro thread con una politica diversa da realtime; se esiste solo un thread realtime, il valore della priorità
SCHED_FIFO
non avrà alcuna importanza. SCHED_RR
- Variante round-robin della politica
SCHED_FIFO
. I thread diSCHED_FIFO
avranno una priorità fissa tra 1 e 99. Tuttavia i thread con la stessa priorità verranno programmati usando un criterio round-robin all'interno di un determinato quantum o periodo di tempo. La chiamata del sistemasched_rr_get_interval(2)
ritorna un valore relativo al periodo di tempo, ma la durata di questo periodo non potrà essere impostata dall'utente. Questa politica è utile se desiderate eseguire thread multipli con la stessa priorità.
SCHED_FIFO
possono essere eseguiti fino a quando gli stessi non verranno bloccati, abbandonati o preceduti da altri thread con priorità più alte. Per questo motivo non è consigliato impostare la priorità su 99, poichè tale priorità posizionerà il processo allo stesso livello dei thread di migrazione e watchdog. Se i thread vengono bloccati poichè essi entrano in un loop, gli stessi non potranno essere eseguiti. Sistemi con un solo processore avranno una elevata possibilità di incontrare questo scenario.
SCHED_FIFO
include un meccanismo di limitazione della larghezza di banda. Tale meccanismo protegge i programmatori in modo da evitare un monopolio della CPU da parte di eventi realtime. Questo meccanismo può essere modificato attraverso i seguenti parametri del file system /proc
:
/proc/sys/kernel/sched_rt_period_us
- Definisce il periodo di tempo da considerare cento per cento larghezza di banda della CPU, in millisecondi ('us' l'equivalente più vicino a 'µs' in testo semplice). Il valore predefinito è 1000000µs, o 1 secondo.
/proc/sys/kernel/sched_rt_runtime_us
- Definisce il periodo di tempo da conferire per l'esecuzione dei thread realtime in millisecondi ('us' l'equivalente più vicino a 'µs' in testo semplice). Il valore predefinito è 950000µs, o 0,95 secondi.
4.2.2. Politiche di programmazione normale
SCHED_OTHER
, SCHED_BATCH
e SCHED_IDLE
. Tuttavia le politiche SCHED_BATCH
e SCHED_IDLE
sono relative a compiti con una priorità bassa e per questo motivo hanno poca rilevanza nella guida di ottimizzazione delle prestazioni.
SCHED_OTHER
, oSCHED_NORMAL
- La politica di programmazione predefinita. Questa politica usa un Completely Fair Scheduler (CFS) per fornire periodi di accesso imparziali per tutti i thread che utilizzano questa politica. CFS stabilisce un elenco di priorità dinamica in parte basato sul valore
niceness
di ogni thread del processo. (Consultare la Deployment Guide per maggiori informazioni su questo parametro e sul file system/proc
.) Ciò conferisce agli utenti un livello indiretto di controllo sulla priorità dei processi, ma l'elenco di priorità dinamico può essere modificato direttamente solo dal CFS.
4.2.3. Selezione politica
SCHED_OTHER
e lasciare al sistema la gestione dell'uso della CPU.
SCHED_FIFO
. Se siete in possesso di un numero limitato di thread, isolate un socket della CPU e spostate i thread sui core del socket. Così facendo nessun thread entrerà in competizione sui core.
4.3. Interrupt e Ottimizzazione IRQ
/proc/interrupts
elenca il numero di interrupt per CPU per dispositivo I/O. Mostra il numero di IRQ, il numero dell'interrupt gestito da ogni CPU core, il tipo di interrupt ed un elenco delimitato da virgole di driver registrati per ricevere il segnale. (Consultare la pagina man proc(5) per maggiori informazioni: man 5 proc
)
smp_affinity
, la quale definisce i CPU core in grado di eseguire ISR per l'IRQ in questione. Usare questa proprietà per migliorare le prestazioni dell'applicazione assegnando sia l'affinità dell'interruzione che quella del thread dell'applicazione ad uno più CPU core. Ciò permette di avere una linea di condivisione della cache tra l'interrupt specificato ed i thread dell'applicazione.
/proc/irq/IRQ_NUMBER/smp_affinity
associato, disponibile e modificabile dall'utente root. Il valore archiviato in questo file è una maschera di bit esadecimale che rappresenta tutti i CPU core presenti nel sistema.
# grep eth0 /proc/interrupts 32: 0 140 45 850264 PCI-MSI-edge eth0
smp_affinity
appropriato:
# cat /proc/irq/32/smp_affinity f
f
, ciò significa che IRQ può essere servito su qualsiasi CPU del sistema. L'impostazione di questo valore su 1
indicherà che solo la CPU 0 può servire questo interrupt:
# echo 1 >/proc/irq/32/smp_affinity # cat /proc/irq/32/smp_affinity 1
smp_affinity
per gruppi a 32-bit discreti. Questa impostazione è necessaria per sistemi con un numero di core maggiore di 32. Di seguito viene riportato un esempio nel quale IRQ 40 viene servito su tutti i core di un sistema a 64-core:
# cat /proc/irq/40/smp_affinity ffffffff,ffffffff
# echo 0xffffffff,00000000 > /proc/irq/40/smp_affinity # cat /proc/irq/40/smp_affinity ffffffff,00000000
Nota
smp_affinity
di un IRQ, la decisione di servire un interrupt con una CPU particolare viene presa a livello hardware senza alcun intervento da parte del kernel.
4.4. Miglioramenti NUMA in Red Hat Enterprise Linux 6
4.4.1. Ottimizzazione bare-metal e scalabilità
4.4.1.1. Miglioramenti sul riconoscimento della tipologia
- rilevamento della tipologia migliorato
- Ciò permette ad un sistema operativo di rilevare informazioni dettagliate sull'hardware (come ad esempio CPU logiche, hyper thread, core, socket, nodi NUMA e tempi di accesso tra i nodi) al momento dell'avvio e di ottimizzare la processazione sul sistema.
- completely fair scheduler
- Questa nuova modalità d'accesso assicura una condivisione uniforme del tempo di esecuzione tra i processi interessati. Unendo questa impostazione con il rilevamento della tipologia sarà possibile programmare i processi su CPU all'interno dello stesso socket, evitando così la necessità di avere un accesso della memoria remota, e assicurando che il contenuto presente in cache possa essere conservato quando possibile.
malloc
malloc
è stato ora ottimizzato ed è in grado di assicurare che le regioni della memoria assegnate ad un processo, siano il più vicine possibili al core sul quale il processo risulta essere in esecuzione. Questa impostazione migliora la velocità di accesso della memoria.- Assegnazione buffer I/O skbuff
- In modo simile a
malloc
, è stata eseguita una sua ottimizzazione per utilizzare la memoria fisicamente vicina alle operazioni I/O di gestione della CPU, come ad esempio gli interrupt del dispositivo. - affinità interrupt del dispositivo
- È possibile utilizzare le informazioni registrate dai driver dei dispositivi relative alla gestione degli interrupt da parte delle CPU. Queste informazioni possono essere usate per limitare la gestione degli interrupt alle CPU presenti sullo stesso socket fisico, conservando così l'affinità della cache e limitando il volume delle comunicazioni tra i socket.
4.4.1.2. Miglioramento nella sincronizzazione tra processori multipli
- Blocchi Read-Copy-Update (RCU)
- Generalmente il 90% di blocchi vengono usati per processi di sola lettura. l'RCU locking rimuove la necessità di ottenere un blocco per un accesso esclusivo quando i dati usati non sono stati modificati. Questa modalità viene ora implementata nell'assegnazione della memoria cache della pagina: il blocco viene usato ora solo per operazione di allocazione/deallocazione.
- algoritmi per-CPU e per-socket
- Numerosi algoritmi sono stati aggiornati per poter eseguire un blocco coordinato tra CPU in coperazione tra loro presenti sullo stesso socket. Questa operazione permette di avere un blocco più dettagliato. Numerosi spinlock sono stati rimossi e sostituiti da metodi di blocco per-socket. L'aggiornamento delle zone dell'allocatore di memoria e degli elenchi delle pagine relativi, permette di usare una logica di assegnazione con un sottoinsieme più efficiente di strutture per la mappatura dei dati della memoria durante operazioni di allocazione/deallocazione.
4.4.2. Miglioramenti virtualizzazione
- CPU pinning
- È possibile associare l'esecuzione dei guest virtuali ad un socket specifico per ottimizzare la cache locale in uso, rimuovendo così la necessità di utilizzare comunicazioni inter-socket costose e l'accesso alla memoria remoto.
- transparent hugepages (THP)
- Con THP abilitato, il sistema esegue automaticamente richieste di allocazione della memoria NUMA-riconosciuta per quantità di memoria adiacente molto grande, riducendo così la contesa del blocco e le operazioni di gestione della memoria translation lookaside buffer (TLB) necessarie, aumentando le prestazioni fino al 20% nei guest virtuali.
- Implementazione I/O basata sul kernel
- Il sottosistema I/O del guest virtuale è ora implementato nel kernel, ed è in grado di ridurre l'accesso alla memoria e la comunicazione inter-node, impedendo l'esecuzione di una quantità molto grande di scambio del contesto, ed un sovraccarico delle comunicazioni e sincronizzazione.
Capitolo 5. Memoria
5.1. Huge Translation Lookaside Buffer (HugeTLB)
/usr/share/doc/kernel-doc-version/Documentation/vm/hugetlbpage.txt
5.2. Huge pages e transparent huge pages
- Aumento del numero di voci della tabella della pagina nell'unità di gestione della memoria hardware
- Aumento della dimensione della pagina
5.3. Come usare Valgrind per una analisi sull'uso della memoria
valgrind --tool=toolname program
memcheck
, massif
, o cachegrind
), e program con il programma desiderato da usare con Valgrind. Attenzione, l'uso di Valgrind causerà una esecuzione più lenta del programma rispetto alle condizioni normali.
man valgrind
; questo comando è disponibile se avete installato il pacchetto valgrind o presente nelle seguenti posizioni:
/usr/share/doc/valgrind-version/valgrind_manual.pdf
, and/usr/share/doc/valgrind-version/html/index.html
.
5.3.1. Come usare Memcheck per una analisi sull'uso della memoria
valgrind program
, senza specificare --tool=memcheck
. Esso rileva e riporta un certo numero di errori della memoria difficili da rilevare e diagnosticare, come ad esempio un accesso della memoria non previsto, l'uso di valori non inizializzati o non definiti, memoria heap resa disponibile non correttamente, puntatori sovrapposti e perdite di memoria. Se utilizzate Memcheck i programmi verranno eseguiti da dieci a trenta volte più lentamente rispetto ad una loro esecuzione normale.
/usr/share/doc/valgrind-version/valgrind_manual.pdf
.
--leak-check
- Se abilitato Memcheck va alla ricerca di perdite di memoria quando il programma client termina la sua esecuzione. Il valore predefinito è
summary
, e il suo output riporta il numero di perdite trovate. Altri valori possibili sonoyes
efull
, entrambi riportano le informazioni su ogni perdita individuale eno
disabilita questo tipo di controllo. --undef-value-errors
- Se abilitato (impostato su
yes
), Memcheck riporta gli errori se vengono usati valori non identificati. Se disabilitato (impostato suno
), questi errori non vengono riportati. Questa opzione è abilitata per impostazione predefinita. La sua disabilitazione aumenta leggermente la velocità di esecuzione di Memcheck. --ignore-ranges
- Permette all'utente di specificare una o più gamme da ignorare durante il controllo sull'usabilità di parte della memoria per altri scopi. Gamme multiple sono delimitate da virgole, per esempio
--ignore-ranges=0xPP-0xQQ,0xRR-0xSS
.
/usr/share/doc/valgrind-version/valgrind_manual.pdf
.
5.3.2. Come usare Cachegrind per una analisi sull'uso della memoria
# valgrind --tool=cachegrind program
- Richieste di lettura non eseguite (read misses) e lettura (o istruzioni eseguite) delle istruzioni per cache del primo livello, e richieste di lettura non eseguite per l'istruzione della cache dell'ultimo livello;
- Lettura dati della cache (o lettura della memoria), richieste di lettura non eseguite e richieste di lettura non eseguite dei dati della cache dell'ultimo livello;
- Scrittura dati della cache (o scrittura della memoria), richieste di scrittura non eseguite e richieste di scrittura non eseguite dei dati della cache dell'ultimo livello;
- branch condizionali eseguiti e previsti incorrettamente; e
- branch indiritti eseguiti e previsti incorrettamente.
cachegrind.out.pid
, dove pid è l'ID del processo del programma sul quale è stato eseguito Cachegrind). È possibile processare maggiormente questo file usando cg_annotate nel modo seguente:
# cg_annotate cachegrind.out.pid
Nota
# cg_diff first second
--I1
- Specifica la dimensione, l'associazione e la dimensione della riga per la cache dell'istruzione di primo-livello, separati da virgole:
--I1=size,associativity,line size
. --D1
- Specifica la dimensione, l'associazione e la dimensione della riga per la cache dei dati di primo-livello, separati da virgole:
--D1=size,associativity,line size
. --LL
- Specifica la dimensione, l'associazione e la dimensione della riga della cache dell'ultimo-livello, separati da virgole:
--LL=size,associativity,line size
. --cache-sim
- Abilita o disabilita la raccolta dei conteggi relativi al mancato accesso e dell'accesso della cache. Il valore predefinito è
yes
(abilitato).Da notare che disabilitando entrambe le opzioni sopra indicate e--branch-sim
, non permetterete a Cachegrind di ottenere alcuna informazione. --branch-sim
- Abilita o disabilita la raccolta delle informazioni relative ai conteggi previsti incorrettamente e sulle istruzioni del branch. Per impostazione predefinita questa opzione è impostata su
no
(disabilitato), poichè rallenterà Cachegrind di circa il 25 per-cento.Da notare che disabilitando entrambe le opzioni sopra indicate e--cache-sim
, non permetterete a Cachegrind di ottenere alcuna informazione.
/usr/share/doc/valgrind-version/valgrind_manual.pdf
.
5.3.3. Profiling dello spazio di stack e heap con Massif
massif
come strumento di Valgrind da usare:
# valgrind --tool=massif program
massif.out.pid
, dove pid è l'ID del processo del programma specificato.
ms_print
:
# ms_print massif.out.pid
--heap
- Specifica se eseguire il profiling di heap. Il valore predefinito è
yes
. Il profiling di heap può essere disabilitato impostando questa opzione suno
. --heap-admin
- Specifica il numero di byte per blocco da usare per la gestione quando il profiling di heap è abilitato. Il valore predefinito è
8
byte per blocco. --stacks
- Specifica se eseguire il profiling dello stack. Il valore predefinito è
no
(disabilitato). Per abilitare il profiling dello stack impostare questa opzione suyes
, ma attenzione poichè così facendo verrà sensibilmente rallentata l'esecuzione di Massif. Da notare altresì che Massif assume che la dimensione dello stack sia zero all'avvio, in modo da indicare meglio la dimensione della porzione di stack rispetto al quale il programma sul quale viene eseguito il profiling ha un controllo. --time-unit
- Specifica l'unità di tempo usata per il profiling. Sono disponibili tre valori validi per questa opzione: istruzioni eseguite (
i
), il valore predefinito, che risulta utile in numerosi casi; real time (ms
, in millisecondi), utile in determinate istanze; e byte allocati/deallocati sull'heap/o stack (B
), utile per programmi eseguiti brevemente e per l'esecuzione di test, poichè questo processo risulta essere quello più facilmente riproducibile su diverse macchine. Questa opzione è utile per un grafico dell'output di Massif conms_print
.
/usr/share/doc/valgrind-version/valgrind_manual.pdf
.
5.4. Ottimizzazione capacità
overcommit_memory
momentaneamente su 1
, eseguire:
# echo 1 > /proc/sys/vm/overcommit_memory
sysctl
. Per maggiori informazioni consultare la Deployment Guide disponibile su http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
Valori ottimizzabili della memoria relativi alla capacità
/proc/sys/vm/
nel file system proc.
overcommit_memory
- Definisce le condizioni che determinano se una richiesta di memoria molto grande può essere accettata o negata. Per questo parametro sono disponibili tre valori:
0
— L'impostazione predefinita. Il kernel esegue una gestione euristica del sovraccarico della memoria disponibile, negando le richieste chiaramente invalide. Sfortunatamente poichè la memoria viene assegnata usando un algoritmo euristico e non preciso, questa impostazione può talvolta sovraccaricare la memoria disponibile del sistema.1
— Il kernel non esegue alcuna gestione del sovraccarico della memoria. Con questo tipo di impostazione si aumentano le possibilità di un sovraccarico della memoria, ma anche delle prestazioni per compiti "memory-intensive".2
— Il kernel nega le richieste per una memoria uguale o maggiore alla somma totale tra lo swap disponibile e la percentuale di RAM fisica specificata inovercommit_ratio
. Questa impostazione è ideale se si desidera avere un minor rischio di un utilizzo eccessivo della memoria.Nota
Questa impostazione è consigliata solo per sistemi con un'area di swap più grande della memoria fisica.
overcommit_ratio
- Specifica la percentuale di RAM fisica considerata quando
overcommit_memory
viene impostato su2
. Il valore predefinito è50
. max_map_count
- Definisce il numero massimo di aree per la mappatura della memoria che un processo è in grado di usare. In numerosi casi il valore predefinito di
65530
è quello più appropriato. Aumentate questo valore se l'applicazione deve mappare un numer maggiore di file. nr_hugepages
- Definisce il numero di hugepages configurate nel kernel. Il valore predefinito è 0. È possibile solo allocare (o deallocare) hugepages se è presente un numero sufficiente di pagine fisiche disponibili adiacenti. Pagine riservate da questo parametro non possono essere usate per altri scopi. Maggiori informazioni sono disponibili nella documentazione installata:
/usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt
Parametri regolabili del kernel relativi alla capacità
/proc/sys/kernel/
nel file system proc.
msgmax
- Definisce la dimensione massima permessa in byte di qualsiasi mesaggio in una coda. Questo valore non deve superare la dimensione della coda (
msgmnb
). Il valore predefinito è65536
. msgmnb
- Definisce la dimensione massima in byte di una coda singola del messaggio. Il valore predefinito è
65536
byte. msgmni
- Definisce il numero massimo di identificatori della coda del messaggio (e quindi il numero massimo di code). Il valore predefinito su macchine con una architettura a 64-bit è
1985
; per architetture a 32-bit il valore predefinito è1736
. shmall
- Definisce il numero totale di memoria condivisa in byte utilizzabile sul sistema in un dato momento. Il valore predefinito su macchine con una architettura a 64-bit è
4294967296
; per architetture a 32-bit il valore predefinito è268435456
. shmmax
- Definisce il segmento massimo della memoria condivisa permesso dal kernel, in byte. Il valore predefinito sulle macchine con una architettura a 64-bit è
68719476736
; per architetture a 32-bit il valore predefinito è4294967295
. Da notare tuttavia che il kernel supporta valori molto più grandi. shmmni
- Definisce il numero massimo per l'intero sistema di segmenti della memoria condivisa. Il valore predefinito è
4096
sia per l'architettura a 64-bit che per quella a 32-bit. threads-max
- Definisce il numero massimo di thread (compiti) per l'intero sistema utilizzabili dal kernel in un dato momento. Il valore predefinito è uguale al valore di
max_threads
del kernel. La formula usata è:max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE )
Il valore minimo dithreads-max
è20
.
Parametri regolabili del file system relativi alla capacità
/proc/sys/fs/
nel file system proc.
aio-max-nr
- Definisce il numero massimo di eventi permessi in tutti i contesti I/O asincroni attivi. Il valore predefinito è
65536
. Da notare che la modifica di questo valore non cambia la dimensione ne preassegna le strutture dei dati del kernel. file-max
- Elenca il numero massimo di operazioni di gestione dei file assegnati dal kernel. Il valore predefinito corrisponde al valore di
files_stat.max_files
nel kernel, ed è impostato prendendo in considerazione il valore più grande tra(mempages * (PAGE_SIZE / 1024)) / 10
oNR_FILE
(8192 in Red Hat Enterprise Linux). Aumentando questo valore potreste risolvere gli errori causati da un numero insufficiente di gestioni disponibili del file.
Parametri regolabili di Out-of-Memory Kill
/proc/sys/vm/panic_on_oom
su 0
indica al kernel di invocare la funzione oom_killer
in presenza di OOM. Generalmente oom_killer
è in grado di arrestare "kill" processi fittizi, e permette al sistema di continuare con le sue funzioni.
oom_killer
. Esso è posizionato in /proc/pid/
nel file system proc, dove pid è il numero dell'ID del processo.
oom_adj
- Definisce un valore da
-16
a15
in grado di determinare l'oom_score
di un processo. Più alto è il valore dioom_score
e maggiore è la possibilità che un processo venga arrestato "killed" daoom_killer
. L'impostazione dioom_adj
su-17
disabilitaoom_killer
per quel processo.Importante
Ogni processo generato da un processo modificato erediterà l'oom_score
di quel processo. Per esempio, se un processosshd
è protetto dalla funzioneoom_killer
, tutti i processi iniziati da quella sessione SSH verranno protetti. Ciò può interessare l'abilità della funzioneoom_killer
di salvare il sistema in presenza di un OOM.
5.5. Ottimizzazione della memoria virtuale
swappiness
- Un valore da 0 a 100 controlla il grado con il quale viene eseguito lo swap del sistema. Un valore elevato da una priorità alle prestazioni, ed esegue uno swap aggressivo dei processi dalla memoria fisica quando gli stessi non risultano attivi. Un valore basso conferisce una priorità ai processi di interazione ed evita lo swap dei processi dalla memoria fisica il più a lungo possibile. Il valore predefinito è
60
. min_free_kbytes
- Il numero minimo di kilobyte da mantenere libero su tutto il sistema. Questo valore viene usato per calcolare un valore limite per ogni zona con una memoria bassa, alla quale viene assegnata un numero di pagine libere riservate proporzionale alla dimensione.
Avvertimento
Fate attenzione quando impostate questo parametro poichè valori troppo bassi o valori troppo alti possono essere controproducenti.Una impostazione troppo bassa dimin_free_kbytes
impedisce al sistema di riappropriarsi della memoria. Tale impostazione può risultare in una sospensione del sistema e in un arresto da parte di OOM di processi multipli.Tuttavia l'impostazione di questo parametro ad un valore troppo alto (5-10% del totale della memoria del sistema) causerà l'uso immediato di tutta la memoria. Linux è stato creato per utilizzare tutta la RAM disponibile per memorizzare in cache i dati del file system. Impostando un valoremin_free_kbytes
elevato causerà l'impiego di un periodo più lungo da parte del sistema per riappropriarsi della memoria. dirty_ratio
- Definisce un valore percentuale. La rimozione dei dati corrotti (tramite pdflush) inizia quando i dati raggiungono questa percentuale del totale della memoria del sistema. Il valore predefinito è
20
. dirty_background_ratio
- Definisce un valore percentuale. La rimozione dei dati corrotti (tramite pdflush) inizia nello sfondo quando i dati raggiungono questa percentuale del totale della memoria del sistema. Il valore predefinito è
10
. drop_caches
- L'impostazione di questo valore su
1
,2
, o3
causa l'abbandono di varie combinazioni da parte del kernel di cache slab e pagine.- 1
- Il sistema non convalida e libera tutta la memoria in cache della pagina.
- 2
- Il sistema libera tutta la memoria in cache della slab non utilizzata.
- 3
- Il sistema libera tutta la cache della pagina e la memoria in cache della slab.
Questa è una operazione non-distruttiva. Poichè non è possibile rendere disponibili oggetti corrotti, è consigliata l'esecuzione disync
prima di impostare il valore di questo parametro.Importante
Non è consigliato l'uso didrop_caches
per liberare la memoria in un ambiente di produzione.
swappiness
momentaneamente su 50
, eseguire:
# echo 50 > /proc/sys/vm/swappiness
sysctl
. Per maggiori informazioni consultare la Deployment Guide disponibile su http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
Capitolo 6. Input/Output
6.1. Funzioni
- I Solid state disk (SSD) sono ora riconosciuti automaticamente e le prestazioni dello scheduler I/O sono ottimizzate per trarre vantaggio dal valore I/Os per second (IOPS) elevato di questi dispositivi.
- È stato aggiunto al kernel il supporto per il Discard per notificare allo storage sottostante la gamma di blocchi non usati. Ciò assiste il SSD durante l'uso degli algoritmi wear-leveling e assiste lo storage che supporta il provisioning del blocco logico (una forma di spazio dell'indirizzo virtuale per lo storage) controllando in modo più dettagliato la quantità di storage in uso.
- Con l'introduzione di Red Hat Enterprise Linux 6.1 l'implementazione dei barrier per il file system è stata rivista in modo da avere migliori prestazioni.
pdflush
è stato sostituito dai per-backing-device flusher thread, i quali migliorano sensibilmente la scalabilità del sistema in configurazioni con conteggi LUN molto grandi.
6.2. Analisi
Figura 6.1. output aio-stress per 1 thread, 1 file
- aio-stress
- iozone
- fio
6.3. Strumenti
si
(swap in), so
(swap out), bi
(block in), bo
(block out), e wa
(I/O wait time). si
e so
sono utili quando lo spazio di swap è sullo stesso dispositivo della partizione dati, e risulta indicativo della pressione generale della memoria. si
e bi
sono operazioni di lettura mentre so
e bo
sono operazioni di scrittura. Queste categorie sono riportate in kilobyte. wa
è il tempo di inattività; Esso indica quale sezione della coda di esecuzione è stata bloccata in attesa del completamento dell'I/O.
free
, buff
, e cache
. L'aumento del valore cache
insieme a bo
seguito da una riduzione di cache
ed un aumento di free
, indica che il sistema esegue una operazione di write-back e di annullamento della cache della pagina.
avgqu-sz
), sarà possibile stimare le prestazioni dello storage usando i grafici generati durante l'analisi delle prestazioni. Sono applicate alcune generalizzazioni, se la dimensione media delle richieste è 4KB e quella della coda risulta essere 1, l'output netto non dovrebbe risultare performante.
8,64 3 1 0.000000000 4162 Q RM 73992 + 8 [fs_mark] 8,64 3 0 0.000012707 0 m N cfq4162S / alloced 8,64 3 2 0.000013433 4162 G RM 73992 + 8 [fs_mark] 8,64 3 3 0.000015813 4162 P N [fs_mark] 8,64 3 4 0.000017347 4162 I R 73992 + 8 [fs_mark] 8,64 3 0 0.000018632 0 m N cfq4162S / insert_request 8,64 3 0 0.000019655 0 m N cfq4162S / add_to_rr 8,64 3 0 0.000021945 0 m N cfq4162S / idle=0 8,64 3 5 0.000023460 4162 U N [fs_mark] 1 8,64 3 0 0.000025761 0 m N cfq workload slice:300 8,64 3 0 0.000027137 0 m N cfq4162S / set_active wl_prio:0 wl_type:2 8,64 3 0 0.000028588 0 m N cfq4162S / fifo=(null) 8,64 3 0 0.000029468 0 m N cfq4162S / dispatch_insert 8,64 3 0 0.000031359 0 m N cfq4162S / dispatched a request 8,64 3 0 0.000032306 0 m N cfq4162S / activate rq, drv=1 8,64 3 6 0.000032735 4162 D R 73992 + 8 [fs_mark] 8,64 1 1 0.004276637 0 C R 73992 + 8 [0]
Total (sde): Reads Queued: 19, 76KiB Writes Queued: 142,183, 568,732KiB Read Dispatches: 19, 76KiB Write Dispatches: 25,440, 568,732KiB Reads Requeued: 0 Writes Requeued: 125 Reads Completed: 19, 76KiB Writes Completed: 25,315, 568,732KiB Read Merges: 0, 0KiB Write Merges: 116,868, 467,472KiB IO unplugs: 20,087 Timer unplugs: 0
- Q — Un blocco I/O messo in coda
- G — Ottieni una richiestaUn blocco I/O appena messo in coda non è il condidato per una opearazione di Merge con una richiesta esistente, per questo motivo è stato assegnata una nuova richiesta del livello del blocco.
- M — Un blocco I/O è stato unito con una richiesta esistente.
- I — Inserita una richiesta nella coda del dispositivo.
- D — Emessa una richiesta al dispositivo.
- C — Richiesta completata dall'unità.
- P — La coda del dispositivo è bloccata "Plugged" e permette la raccolta di richieste.
- U — La coda del dispositivo è sbloccata "Unplugged", e permette l'emissione delle richieste per il dispositivo.
- Q2Q — tempo trascorso tra richieste inviate al livello blocco
- Q2G — il tempo trascorso quando un blocco I/O viene messo in coda ed il tempo nel quale riceve una richiesta
- Q2I — il tempo trascorso da quando una richiesta è stata assegnata a quando la stessa viene inserita nella coda del dispositivo
- Q2M — il tempo trascorso quando un blocco I/O viene messo in coda ed il tempo entro il quale viene unito con una richiesta esistente
- Q2I — tempo trascorso quando una richiesta viene inserita nella coda del dispositivo ed il tempo entro il quale la richiesta viene inviata al dispositivo
- Q2D — il tempo trascorso entro il quale un blocco I/O viene unito con una richiesta esistente fino a quando la richiesta viene emessa al dispositivo
- D2C — tempo di servizio della richiesta per il dispositivo
- Q2C — tempo totale trascorso nel blocco per un richiesta
Figura 6.2. Esempio di output di seekwatcher
6.4. Configurazione
6.4.1. Completely Fair Queuing (CFQ)
ionice
o attraverso la chiamata del sistema ioprio_set
. Per impostazione predefinita i processi vengono posizionati nella classe best-effort (BE). Le classi real-time (RT) e best-effort vengono suddivise in otto priorità I/O all'interno di ogni classe, con una priorità 0 corrispondente al valore più alto e 7 a quello più basso. I processi nella classe real-time vengono programmati in modo più aggressivo rispetto a quelli presenti in best-effort o idle, per questo motivo ogni I/O real-time programmato viene sempre eseguito prima della classe best-effort o idle. Ciò significa che la priorità real-time può annullare sia la classe best-effort che idle. La classe di programmazione Best effort è quella predefinita e 4 è la priorità di default. I processi nella classe idle vengono serviti solo quando non vi è alcun I/O in attesa nel sistema. Per questo è importante impostare solo la classe di programmazione di un processo su idle se l'I/O non è necessario per procedere con il normale funzionamento.
/sys/block/device/queue/iosched/
:
slice_idle = 0 quantum = 64 group_idle = 1
group_idle
viene impostato su 1, sarà ancora possibile il verificarsi di uno stallo degli I/O (per cui lo storage backend non risulta occupato a causa di uno stato inattivo). Tuttavia esso avrà una frequenza ridotta rispetto agli stati di inattività presenti su ogni coda del sistema.
Parametri ottimizzabili
back_seek_max
- Le Backward seek sono processi dannosi per le prestazioni in quanto essi possono avere ritardi maggiori nel riposizionamento delle testine rispetto alle forward seek. Tuttavia CFQ è in grado di eseguirle se risultano essere piccole operazioni di ricerca. Questo parametro controlla la distanza massima abilitato dallo scheduler I/O per questo tipo di ricerche. Il valore predefinito è
16
KB. back_seek_penalty
- A causa della scarsa efficienza delle backward seek verrà loro associata una penalità. La penalità risulta essere un moltiplicatore; per esempio, considerate la posizione di una testina del disco su 1024KB. Supponiamo la presenza in coda di due richieste, una in 1008KB e l'altra in 1040KB. Le due richieste sono equidistanti dalla posizione corrente della testina. Tuttavia dopo aver applicato la penalità dovuta alla backward seek (default:2), la richiesta nella seconda posizione si trova ora due volte più vicina rispetto alla prima richiesta. Per questo motivo la testina si muoverà in avanti.
fifo_expire_async
- Questo parametro controlla il periodo entro il quale una richiesta (scrittura in buffer) asincrona può non essere servita. Dopo questo periodo (in millisecondi) una richiesta asincrona non servita verrà spostata nell'elenco Invio. L'impostazione predefinita è
250
ms. fifo_expire_sync
- Simile al parametro ifo_expire_async, per richieste sincrone (lettura e scrittura O_DIRECT). Il valore predefinito è
125
ms. group_idle
- Quando impostato, CFQ sarà inattivo sull'ultimo processo che emette un I/O in un cgroup. Impostare questo valore su
1
quando utilizzate i proportional weight I/O cgroup ed impostareslice_idle
su0
(generalmente impostato su storage veloci). group_isolation
- Se group isolation è stato abilitato (su
1
), esso fornisce un isolamento più forte tra gruppi a scapito dell'output netto. In generale se group isolation è stato disabilitato, l'imparzialità viene fornita solo per carichi di lavoro sequenziali. Abilitando questo parametro avrete una imparzialità sia per carichi di lavoro randomici che per quelli sequenziali. Il valore predefinito è0
(disabilitato). Per maggiori informazioni consultateDocumentation/cgroups/blkio-controller.txt
. low_latency
- Se il parametro low_latency è stato abilitato (impostato su
1
), CFQ cerca di fornire un tempo di attesa massimo di 300 ms per ogni processo che emette un I/O su un dispositivo. Questa impostazione assicura una certa imparzialità sull'output netto. Disabilitando questo parametro (impostandolo su0
) verrà ignorata la latenza target, permettendo così ad ogni processo presente nel sistema di ricevere una quota di tempo completa. Per impostazione predefinita Low latency risulta essere abilitato. quantum
- Il quantum controlla il numero di I/O che il CFQ invierà allo storage in un determinato periodo, limitando così la profondità della coda del dispositivo. Per impostazione predefinita questo valore è impostato su
8
. Lo storage è in grado di supportare una coda più grande, ma se aumentate il valore del parametroquantum
, potrete impattare negativamente sulla latenza in particolare in presenza di una quantità molto elevata di processi di scrittura sequenziali. slice_async
- Questo valore controlla la quantità di tempo assegnata ad ogni processo che emette I/O asincroni (scrittura con buffer). Per impostazione predefinita questo valore è impostato su
40
ms. slice_idle
- Questo valore specifica la quantità di tempo che CFQ deve essere inattivo in attesa di altre richieste. Il valore predefinito in Red Hat Enterprise Linux 6.1, e versioni precedenti, è di
8
ms. Con Red Hat Enterprise Linux 6.2 e versioni più recenti questo valore è di0
. Il valore zero migliora l'output netto di uno storage RAID esterno, rimuovendo tutti gli stati inattivi a livello albero del servizio e coda. Tuttavia questo valore può impattare negativamente sulle prestazioni di storage non-RAID interni poichè esso aumenta il numero generale di ricerche. Per storage non-RAID è consigliato un valoreslice_idle
maggiore di 0. slice_sync
- Questo valore controlla la quantità di tempo assegnata ad un processo che emette I/O sincroni (scrittura diretta o lettura). Per impostazione predefinita questo valore è impostato su
100
ms.
6.4.2. Deadline I/O Scheduler
Parametri ottimizzabili
fifo_batch
- Questo valore determina il numero di processi di lettura o scrittura da emettere in un blocco singolo. Il valore predefinito è
16
. L'impostazione di un valore più alto può generare un miglior output netto, aumentando però al tempo stesso anche il valore di latenza. front_merges
- Impostare questo parametro su
0
se il carico di lavoro non eseguirà mai operazioni di front merge. Se non conoscete il sovraccarico presente con questa operazione, è consigliato lasciare il valore predefinito (1
). read_expire
- Questo valore permette all'utente di impostare il numero di millisecondi nel quale una richiesta di lettura deve essere servita. Per impostazione predefinita questo valore è impostato su
500
ms (mezzo secondo). write_expire
- Questo valore permette all'utente di impostare il numero di millisecondi nel quale una richiesta di scrittura deve essere servita. Per impostazione predefinita questo valore è impostato su
5000
ms (cinque secondi). writes_starved
- Questo valore determina il numero di blocchi di lettura da processare prima di processare un blocco singolo di processi di scrittura. Più questo valore risulta essere alto e maggiore è la preferenza data ai processi di lettura.
6.4.3. Noop
/sys/block/sdX/queue tunables
- add_random
- Spesso il sovraccarico degli eventi I/O che contribuiscono al bacino di entropia per
/dev/random
è misurabile. In tal caso è consigliato impostare questo valore su 0. max_sectors_kb
- Per impostazione predefinita la dimensione massima della richiesta inviata al disco è
512
KB. Questo parametro può essere usato per aumentare o diminuire quel valore. Il valore minimo è limitato dalla dimensione del blocco logico; il valore massimo è limitato damax_hw_sectors_kb
. Sono presenti alcuni SSD con prestazioni peggiori in presenza di dimensioni I/O maggiori rispetto alla dimensione dell'erase block size interno. In questi casi è consigliato diminuiremax_hw_sectors_kb
alla dimensione dell'erase block size. Per eseguire una prova utilizzate un generatore di I/O come ad esempio iozone o aio-stress, variando la dimensione, per esempio da512
byte a1
MB. nomerges
- Questo parametro è principalmente usato come ausilio al debugging. Numerosi carichi di lavoro traggono beneficio dal processo di unione delle richieste (anche su storage più veloci come SSD). In alcuni casi è tuttavia consigliato disabilitare il processo di unione "merging', per esempio se desiderate sapere quanti IOPS uno storage backend è in grado di processare senza disabilitare read-ahead o eseguire un I/O randomico.
nr_requests
- Ogni coda ha un limite sul numero totale di descrittori di richieste assegnabili per ogni I/O di scrittura e lettura. Per impostazione predefinita questo valore è
128
, ciò significa che 128 letture e 128 scritture possono essere messi in coda contemporaneamente prima di sospendere "sleep" un processo. Il processo sospeso risulta essere quello che succesivamente cercherà di assegnare una richiesta, e potrà non essere il processo che ha assegnato tutte le richieste disponibili.Se siete in possesso di una applicazione particolarmente sensibile alla latenza allora è consigliato ridurre il valore dinr_requests
nella coda delle richieste, limitando al tempo stesso la profondità della coda del comando sullo storage ad un numero più basso (anche usando un valore pari a1
), in questo modo il writeback I/O non sarà in grado di assegnare tutti i descrittori di richiesta disponibili e consumare la coda del dispositivo con I/O di scrittura. Una volta assegnato unnr_requests
, tutti gli altri processi che cercano di eseguire un I/O verranno sospesi e messi in attesa di richieste disponibili. Questa impostazione è più imparziale poichè le richieste sono distribuite con una modalità round-robin (impedendo così ad un processo di consumare tutto in rapida successione). Da notare che questo è problematico solo in presenza di scheduler deadline o noop, poichè la configurazione predefinita di CFQ impedisce questo tipo di situazione. optimal_io_size
- In alcune circostanze lo storage sottostante riporterà una dimensione dell'I/O ottimale. Ciò è comune in presenza di hardware e software RAID, dove la dimensione I/O ottimale è quella del segmento. In presenza di questo valore, quando possibile, le applicazioni dovranno emettere un I/O allineato, e multiplo, della dimensione I/O ottimale.
read_ahead_kb
- Il sistema operativo è in grado di rilevare quando l'applicazione esegue un processo di lettura sequenziale dei dati da un file o da un disco. Esso sarà in grado in questi casi di eseguire un algoritmo read-ahead intelligente, e leggere dal disco un numero maggiore di dati rispetto a quelli richiesti dall'utente. Quindi, alla lettura successiva di un blocco dati da parte dell'utente, essi saranno già presenti nella cache del sistema operativo. Un possibile effetto negativo di questa operazione è la lettura di un numero maggiore di dati da parte del sistema operativo rispetto a quelli necessari. Questa operazione occuperà spazio in cache fino a quando i dati verranno rimossi a causa di un uso troppo elevato della memoria. In circostanze simili, ed in presenza di processi multipli che eseguono operazioni read-ahead false, verrà aumentata la pressione dovuta ad un elevato uso della memoria.Per dispositivi device mapper è consigliato aumentare il valore di
read_ahead_kb
, ad esempio8192
. Questa operazione è dovuta a causa del numero di dispositivi multipli sottostanti che compongono un device mapper. Per una corretta ottimizzazione impostate il valore predefinito (128
KB) e moltiplicatelo per il numero dei dispositivi da mappare. rotational
- Tradizionalmente i dischi fissi sono di tipo "rotational" (costituiti da dischi rotanti). Tuttavia SSD non riflette questa tendenza e riporta questo tipo di impostazione in modo corretto. Se siete in presenza di un dispositivo il quale non indica con correttezza questo flag, impostate manualmente il parametro rotational su
0
; se il suddetto parametro è disabilitato, l'elevatore I/O non utilizza una logica per la riduzione di operazioni di ricerca, poichè per queste operazioni è presente una penalità ridotta su dispositivi "non-rotational". rq_affinity
- Il completamento degli I/O può essere effettuato su CPU diverse da quella che ha emesso l'I/O. Impostando
rq_affinity
su1
il kernel invierà queste operazioni alla CPU che ha originato l'I/O. Questa operazione migliorerà l'efficacia di una archiviazione in cache dei dati della CPU.
Capitolo 7. File System
7.1. Considerazioni sul processo di ottimizzazione per i file system
7.1.1. Opzioni di formattazione
La dimensione dei blocchi può essere selezionata al momento del mkfs
. La gamma delle dimensioni disponibili dipende dal sistema: il limite più alto è la dimensione massima della pagina del sistema host, mentre il limite più basso dipende dal file system usato. La dimensione del blocco predefinita è appropriata per la maggior parte dei casi.
Se il sistema utilizza uno storage segmentato, ad esempio RAID5, sarà possibile migliorare le prestazioni allineando i dati e i metadati con la geometria dello storage sottostante al momento del mkfs
. Per RAID software ((LVM o MD) ed alcuni storage hardware di livello enterprise, queste informazioni vengono richieste ed impostate automaticamente, ma in numerosi casi l'amministratore dovrà specificare la geometria manualmente con mkfs
sulla linea di comando.
Con carichi di lavoro dei metadati-intensivi la sezione dei log di un file system con journal (come ad esempio ext4 e XFS) viene aggiornata molto spesso. Per minimizzare il tempo di ricerca "seek time" dal file system al journal, posizionare il journal su uno storage apposito. Da notare tuttavia che il posizionamento del journal su uno storage esterno più lento del file system primario, potrebbe annullare qualsiasi vantaggio associato con l'uso di uno storage di questo tipo.
Avvertimento
mkfs
, specificando i dispositivi journal al momento del montaggio. Consultate le pagine man di mke2fs(8)
, mkfs.xfs(8)
e mount(8)
per maggiori informazioni.
7.1.2. Opzioni di montaggio
Un write barrier è un meccanismo del kernel usato per assicurare la scrittura corretta e ordinata sullo storage persistente dei metadati del file system, anche quando dispositivi di storage con cache di scrittura volatile perdono alimentazione. I file system con write barrier abilitato assicurano che qualsiasi dato trasmesso tramite fsync()
, non venga perso in presenza di un perdita di alimentazione. Red Hat Enterprise Linux abilita per impostazione predefinita un barrier su tutti gli hardware che supportano questa operazione.
fsync()
, o creano e rimuovono numerosi file di piccole dimensioni. Per storage con nessun cache di scrittura volatile, o in casi rari dove è accettabile avere inconsistenze del file system e perdite di dati dopo una perdita di alimentazione, è possibile disabilitare i barrier usando l'opzione di montaggio nobarrier
. Per maggiori informazioni consultare la Storage Administration Guide.
Storicamente quando un file viene letto il tempo di accesso (atime
) per quel file deve essere aggiornato nei metadati dell'inode, tale processo richiede una scrittura I/O aggiuntiva. Se non sono necessari metadati atime
accurati, montate il file system con l'opzione noatime
per eliminare gli aggiornamenti dei metadati. Tuttavia nella maggior parte dei casi, atime
non risulta essere un problema molto grande a causa del comportamento del relative atime predefinito (o relatime
) nel kernel di Red Hat Enterprise Linux 6. relatime
aggiorna solo atime
se l'atime
precedente è più vecchio rispetto al tempo di modifica o "modification time" (mtime
) o allo stato di change time (ctime
).
Nota
noatime
abiliterete anche nodiratime
; non vi è alcun bisogno di abilitare sia noatime
che nodiratime
.
Read-ahead velocizza l'accesso dei file tramite il ripristino dei dati ed il loro caricamento sulla cache della pagina, così facendo essi saranno disponibili nella memoria e non sul disco. Alcuni carichi di lavoro, come ad esempio quelli con uno streaming I/O sequenziale, traggono beneficio dai valori elevati di read-ahead.
blockdev
per visualizzare e modificare il valore di read-ahead. Per visualizzare il valore corrente di read-ahead per un dispositivo a blocchi particolare eseguire:
# blockdev -getra device
# blockdev -setra N device
blockdev
non sarà persistente dopo il riavvio. È consigliato creare uno script init.d
del run level per impostare questo valore durante l'avvio.
7.1.3. Gestione del file system
Le operazioni di Batch discard e Online discard sono funzioni dei file system montati, attraverso le quali è possibile rimuovere i blocchi non usati dal file system. Queste operazioni sono utili sia per unità solid-state che per storage thinly-provisioned.
fstrim
. Questo comando rimuove i blocchi non utilizzati che soddisfano i criteri di ricerca impostati dall'utente. Entrambe le operazioni sono supportate e possono essere utilizzate con file system XFS e ext4 in Red Hat Enterprise Linux 6.2 e versioni più recenti, solo se il dispositivo a blocchi sottostante al file system supporta operazioni di rimozione fisiche. Queste operazioni sono supportate se il valore di /sys/block/device/queue/discard_max_bytes
non è zero.
-o discard
(in /etc/fstab
o come parte del comando mount
), ed eseguite in tempo reale senza alcun intervento dell'utente. Queste operazioni rimuovono solo blocchi in transizione con uno stato di usato ad uno disponibile. Tali operazioni sono supportate sui file system ext4 in Red Hat Enterprise Linux 6.2 e versioni più recenti e su file system XFS in Red Hat Enterprise Linux 6.4 e versioni più recenti.
7.1.4. Considerazioni sull'applicazione
I file system ext4, XFS e GFS2 supportano una pre-assegnazione efficiente dello spazio tramite l'invocazione glibc fallocate(2)
. In casi in cui i file possono essere segmentati incorrettamente a causa dei percorsi di scrittura, causando il deterioramento dei processi di lettura, questa tecnica può essere molto utile. Il processo di Pre-assegnazione contrassegna lo spazio del disco come se fosse stato assegnato ad un file, senza scrivere però alcun dato nello spazio in questione. Fino a quando non verranno scritti dati veri e propri all'interno del blocco pre-assegnato, le operazioni di lettura ritorneranno valori pari a zero.
7.2. Profili prestazioni del file system
latency-performance
- Un profilo server per l'ottimizzazione delle prestazioni della latenza. Disabilita i maccanismi di risparmio energetico tuned e ktune. La modalità
cpuspeed
varia inperformance
. Per ogni dispositivo l'I/O elevator viene modificato indeadline
. Il parametrocpu_dma_latency
viene registrato con un valore0
(latenza più bassa) per la qualità di gestione dell'alimentazione, limitando la latenza quando possibile. throughput-performance
- Un profilo server per l'ottimizzazione tipica delle prestazioni di output netto. Questo profilo è consigliato se il sistema non presenta alcuno storage di classe enterprise. Simile a
latency-performance
ad eccezione:kernel.sched_min_granularity_ns
(scheduler minimal preemption granularity) è impostato su10
millisecondi,kernel.sched_wakeup_granularity_ns
(scheduler wake-up granularity) impostato su15
millisecondi,vm.dirty_ratio
(virtual machine dirty ratio) impostato su 40%, e- le transparent huge pages sono abilitate.
enterprise-storage
- Questo profilo è consigliato per configurazioni del server con dimensioni enterprise con uno storage di classe enterprise, inclusa una protezione della cache del controller con un backup tramite batteria ed una gestione della cache su-disco. Simile al profilo
throughput-performance
, ad eccezione:- Il valore di
readahead
viene impostato su4x
, e - file system non root/boot rimontati con
barrier=0
.
man tuned-adm
), o nella Power Management Guide disponibile su http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
7.3. File System
7.3.1. File system Ext4
Nota
Per file system molto grandi il processo mkfs.ext4
può richiedere un periodo di tempo molto lungo durante l'inizializzazione di tutte le tabelle inode nel file system. Questo processo può essere rinviato con l'opzione -E lazy_itable_init=1
. Se utilizzate questa impostazione i processi del kernel continueranno ad inizializzare il file system dopo il suo processo di montaggio. La velocità con la quale viene eseguito questo processo può essere controllata con l'opzione -o init_itable=n
del comando mount
, dove la quantità di tempo per eseguire il processo è di circa 1/n. Il valore predefinito per n
è 10
.
Poichè alcune applicazioni non eseguono un fsync()
corretto dopo la modifica del nome di un file esistente, o dopo un processo di riscrittura o troncamento, ext4 esegue il default su sincronizzazione automatica dei file dopo operazioni replace-via-rename e replace-via-truncate. Questo comportamento è consistente con i comportamenti del file system ext3 più vecchi. Tuttavia le operazioni fsync()
possono richiedere molto tempo, per questo motivo se il suddetto processo automatico non è necessario usare l'opzione -o noauto_da_alloc
con il comando mount
per disabilitarlo. Ciò significa che l'applicazione deve esplicitamente usare fsync()
per rendere i dati persistenti.
Per impostazione predefinita viene conferita al journal commit I/O una priorità leggermente più elevata rispetto all'I/O normale. Tale priorità può essere controllata con l'opzione journal_ioprio=n
del comando mount
. Il valore predefinito è 3
. La gamma di valori validi va da 0 a 7, il valore 0 rappresenta la priorità più alta di I/O.
mkfs
e di ottimizzazione consultare le pagine man di mkfs.ext4(8)
e mount(8)
ed il file Documentation/filesystems/ext4.txt
nel pacchetto kernel-doc.
7.3.2. Il file system XFS
mkfs
, variano l'ampiezza di b-trees, modificando così le caratteristiche di scalabilità dei diversi sottosistemi.
7.3.2.1. Ottimizzazione di base di XFS
mkfs.xfs
esegue automaticamente una configurazione con l'ampiezza e l'unità del segmento corretto per uniformarsi all'hardware. Sarà necessario eseguire una configurazione manuale se si utilizza un hardware RAID.
inode64
è fortemente consigliata per file system multi-terabyte; tale opzione non è consigliata se il file system viene esportato tramite NFS ed i client NFS a 32-bit precedenti hanno bisogno di un accesso al file system.
logbsize
con file system frequentemente modificati o in bursts. Il valore predefinito è MAX
(unità segmento di registrazione a 32 KB), con dimensione massima di 256 KB. Un valore di 256 KB è consigliato per file system che hanno subito numerose modifiche.
7.3.2.2. Ottimizzazione avanzata per XFS
XFS impone un limite arbitrario sul numero di file archiviabili su un file system. In generale questo limite è sufficientemente elevato da non essere mai superato. Se credete che il limite predefinito non sia sufficiente, aumentate la percentuale di spazio del file system per gli inode tramite il comando mkfs.xfs
. Se raggiungete il limite del file dopo la creazione del file system (generalmente indicato da errori ENOSPC durante il tentativo di creare un file o directory anche se lo spazio è disponibile), è possibile modificare il limite con il comando xfs_growfs
.
Per l'intero ciclo di vita di un file system la dimensione di un blocco della directory è fissa e può essere modificata solo durante la formattazione iniziale con il comando mkfs
. La dimensione minima del blocco della directory corrisponde a quella del blocco del file system, che per impostazione predefinita è su MAX
(4 KB). In generale non vi è alcun motivo per ridurre la dimensione del blocco della directory.
Diversamente da altri file system, XFS è in grado di assegnare e deallocare simultaneamente se tali operazioni si verificano su oggetti non condivisi. È possibile eseguire simultaneamente le suddette operazioni nei confronti delle estensioni se i gruppi risultano essere diversi. In modo simile i processi di assegnazione/deallocazione di inode si possono verificare se tali operazioni interessano gruppi diversi.
Se lo spazio è disponibile sull'inode, XFS è in grado di archiviare attributi direttamente al suo interno. Se l'attributo è idoneo per l'inode, esso potrà essere ripristinato e modificato senza alcun I/O aggiuntivo per il recupero di blocchi separati dell'attributo. Le prestazioni per attributi out-of-line (attributi non presenti all'interno dell'inode in questione) saranno più basse rispetto a quelle degli attributi in-line (presenti all'interno dell'inode in questione).
La dimensione del log è il fattore principale per determinare il livello di modifica sostenuto dai metadati. Il dispositivo di log è circolare, quindi prima di poter sovrascrivere la coda tutte le modifiche presenti nel log devono essere salvate nelle posizioni reali sul disco. Tale operazione può richiedere tentativi ripetuti di riscrittura di metadati corrotti. La configurazione predefinita modifica la dimensione del log in base alla dimensione generale del file system, quindi in molti casi la dimensione non avrà bisogno di alcuna ottimizzazione.
mkfs
esegue questa operazione per impostazione predefinita, ma per hardware RAID sarà necessario specificarla. Una impostazione corretta impedirà ad un log I/O di generare un I/O non allineato, quindi operazioni read-modify-write al momento della scrittura delle modifiche sul disco.
logbsize
), aumenterete la velocità con la quale le modifiche verranno scritte sul log. La dimensione del buffer log predefinita è MAX
(32 KB, unità segmento di log), con dimensione massima di 256 KB. In generale, un valore più grande corrisponderà a prestazioni più veloci. Tuttavia con carichi di lavoro fsync molto grandi, buffer log piccoli possono essere più veloci rispetto a buffer più grandi con un allineamento maggiore dell'unità del segmento.
delaylog
migliora le prestazioni per le modifiche sostenute dei metadati tramite la riduzione del numero di modifiche per il log. Per fare questo le modifiche vengono raggruppate nella memoria prima di essere salvate sul log: i metadati modificati con molta frequenza vengono scritti periodicamente sul log e non ad ogni verifica. Questa opzione migliora l'uso della memoria durante il monitoraggio dei metadati corrotti, ed aumenta il numero di possibili operazioni perse in presenza di un crash, ma al tempo stesso migliora la velocità di modifica dei metadati e la scalabilità. L'uso di questa opzione non riduce l'integrità dei dati o metadati quando si utilizzano fsync
, fdatasync
o sync
per la loro scrittura sul disco.
7.4. Clustering
7.4.1. Global File System 2
- Preassegnare file e directory con
fallocate
quando possibile, per ottimizzare il processo di assegnazione ed evitare la necessità di bloccare le pagine d'origine. - MInimizzare le aree del file system condivise tra nodi multipli per ridurre i rischi di invalidazione cross-node cache migliorando le prestazioni. Per esempio, se numerosi nodi montano lo stesso file system ma accedono a directory secondarie diverse, probabilmente avrete migliori prestazioni spostando una sottodirectory su un file system separato.
- Selezionare un numero ed una dimensione ottimali del gruppo di risorse. Ciò dipende dalle dimensioni del file tipiche e dallo spazio disponibile sul sistema e può interessare la possibilità che nodi multipli cercheranno di usare simultaneamente un gruppo di risorse. Troppi gruppi possono rallentare l'assegnazione durante la ricerca dello spazio, mentre un numero troppo ristretto di gruppi possono causare una contesa del blocco durante l'annullamento dell'assegnazione. È consigliato provare configurazioni multiple per determinare il processo ottimale per il carico di lavoro desiderato.
- Selezionare l'hardware di storage in base ai percorsi I/O previsti dei nodi del cluster e ai requisiti delle prestazioni del file system.
- Usare uno storage "solid-state" quando possibile per ridurre il tempo di ricerca "seek time".
- Creare un file system con dimensioni appropriate per il carico di lavoro desiderato ed assicurarsi che esso non raggiunga mai una capacità di 80%. File system più piccoli avranno tempi di backup proporzionalmente più piccoli, e avranno bisogno di un periodo e di una memoria minori per l'esecuzione dei controlli del file system. Essi soggetti ad una elevata frammentazione se troppo piccoli per il carico di lavoro desiderato.
- Impostare dimensioni più grandi per il journal con carichi di lavoro intensi per i metadati o durante l'utilizzo dei dati presenti nel journal. Tale processo richiede una quantità di memoria maggiore, ma garantisce elevate prestazioni poichè dispone di spazio libero nel journal per l'archiviazione dei dati prima di dover eseguire un processo di scrittura.
- Assicuratevi che gli orologi presenti nei nodi del GFS2 siano sincronizzati per evitare possibili problematiche con applicazioni di rete. È consigliato usare un NTP (Network Time Protocol).
- Se i tempi di accesso alle directory o ai file non sono critici per il normale svolgimento delle operazioni dell'applicazione, montare il file system con le opzioni di montaggio
noatime
enodiratime
.Nota
Red Hat consiglia l'uso dell'opzionenoatime
con GFS2. - Se desiderate usare un quota, provate a ridurre la frequenza del numero di operazioni di sincronizzazione, oppure usate una sincronizzazione fuzzy quota per impedire eventuali problemi di prestazioni causati dai continui aggiornamenti del file quota.
Nota
Il fuzzy quota accounting permette a utenti o gruppi di superare di poco i limiti impostati. Per minimizzare questa tendenza, GFS2 riduce dinamicamente il periodo di sincronizzazione quando si è prossimi ad un limite quota "hard".
Capitolo 8. Networking
8.1. Miglioramenti delle prestazioni di rete
Receive Packet Steering (RPS)
rx
del NIC singola in modo da avere il proprio carico di lavoro softirq
distribuito tra diverse CPU. Questa impostazione aiuta a prevenire la congestione del traffico di rete sulla coda dell'hardware NIC singola.
/sys/class/net/ethX/queues/rx-N/rps_cpus
, sostituendo ethX
con il nome del dispositivo corrispondente al NIC (per esempio eth1
, eth2
) e rx-N
con la coda di ricezione del NIC specificato. Ciò permetterà alle CPU specificate nel file di processare i dati dalla coda rx-N
su ethX
. Quando specificate le CPU prendete in considerazione il cache affinity della coda [4].
Receive Flow Steering
/proc/sys/net/core/rps_sock_flow_entries
- Usato per controllare il numero massimo di socket/flussi che il kernel è in grado di dirigere verso la CPU specificata. Questo rappresenta un limite condiviso da tutto il sistema.
/sys/class/net/ethX/queues/rx-N/rps_flow_cnt
- Usato per controllare il numero massimo di socket/flussi che il kernel è in grado di dirigere verso la coda di ricezione specificata (
rx-N
) su di un NIC (ethX
). Da notare che la somma di tutti i valori per-coda per questo parametro su tutti i NIC, deve essere uguale o minore a quello di/proc/sys/net/core/rps_sock_flow_entries
.
Supporto getsockopt per TCP thin-stream
getsockopt
che ora supporta due opzioni aggiuntive:
- TCP_THIN_DUPACK
- Per thin stream, questo valore booleano abilita l'attivazione dinamica delle ritrasmissioni dopo un dupACK.
- TCP_THIN_LINEAR_TIMEOUTS
- Per thin stream, questo valore booleano abilita l'attivazione dinamica dei timeout lineari.
file:///usr/share/doc/kernel-doc-version/Documentation/networking/ip-sysctl.txt
. Per maggiori informazioni sui thin-stream consultare file:///usr/share/doc/kernel-doc-version/Documentation/networking/tcp-thin.txt
.
Supporto Transparent Proxy (TProxy)
file:///usr/share/doc/kernel-doc-version/Documentation/networking/tproxy.txt
.
8.2. Impostazioni di rete ottimizzate
- netstat
- Una utilità a linea di comando che stampa le connessioni di rete, tabelle di instradamento, statistiche dell'interfaccia, connessioni di mascheramento e appartenenze multicast. Essa è in grado di ripristinare le informazioni del sottosistema di rete dal file system
/proc/net/
. I file includono:/proc/net/dev
(informazioni del dispositivo)/proc/net/tcp
(Informazioni del socket TCP)/proc/net/unix
(Informazioni socket del dominio di Unix)
Per maggiori informazioni sunetstat
e sui file di riferimento di/proc/net/
consultare la pagina man dinetstat
:man netstat
. - dropwatch
- Una utilità di monitoraggio che controlla la perdita dei pacchetti da parte del kernel. Per maggiori informazioni consultare la pagina man di
dropwatch
:man dropwatch
. - ip
- Una utilità per la gestione ed il controllo degli instradamenti, dispositivi, politica di instradamento e tunnel. Per maggiori informazioni consultare la pagina man di
ip
:man ip
. - ethtool
- Utilità per la visualizzazione e la modifica delle impostazioni del NIC. Per maggiori informazioni consultare la pagina man di
ethtool
:man ethtool
. - /proc/net/snmp
- Un file per la visualizzazione dei dati ASCII necessari per le informazioni sulla gestione dell'IP, ICMP, TCP e UDP per un
snmp
agent. Usato anche per la visualizzazione di statistiche UDP-lite in tempo reale.
/proc/net/snmp
indica che una o più code di ricezione del socket risultano essere sature quando lo stack di rete tenta di mettere in coda nuovi frame in un socket dell'applicazione.
Dimensione del buffer di ricezione del socket
sk_stream_wait_memory.stp
, indicano che la velocità per la gestione di una coda del socket è troppo bassa, aumentate la profondità della coda del socket dell'applicazione. Per fare questo aumentate la dimensione dei buffer di ricezione usati dal socket, configurando uno dei seguenti valori:
- rmem_default
- Un parametro del kernel che controlla la dimensione predefinita dei buffer di ricezione usati dai socket. Per la configurazione eseguire il seguente comando:
sysctl -w net.core.rmem_default=N
SostituireN
con la dimensione del buffer desiderata, in byte. Per determinare il valore di questo parametro del kernel consultare/proc/sys/net/core/rmem_default
. Ricordate che il valore dirmem_default
non dovrebbe essere maggiore dirmem_max
(/proc/sys/net/core/rmem_max
); se necessario aumentare il valore dirmem_max
. - SO_RCVBUF
- Una opzione del socket in grado di controllare la dimensione massima di un buffer di ricezione del socket, in byte. Per maggiori informazioni su
SO_RCVBUF
consultare la pagina man:man 7 socket
.Per configurareSO_RCVBUF
usare l'utilitàsetsockopt
. È possibile ottenere il valore corrente diSO_RCVBUF
usando il comandogetsockopt
. Per maggiori informazioni sull'utilizzo delle utilità consultare la pagina man disetsockopt
:man setsockopt
.
8.3. Panoramica sulla ricezione dei pacchetti
Figura 8.1. Diagramma del percorso di ricezione della rete
- Ricezione Hardware: il network interface card (NIC) riceve il frame sul cavo. In base alla configurazione del driver il NIC trasferisce il frame ad una memoria del buffer hardware interna o ad un buffer circolare specificato.
- Hard IRQ: il NIC indica la presenza di un frame della rete interrompendo la CPU. Questo processo causa la ricezione da parte dell'unità NIC di questa interruzione e programma a sua volta una operazione soft IRQ.
- Soft IRQ: questa fase implementa il processo vero e proprio di ricezione del frame, eseguendolo in un contesto
softirq
. Ciò sognifica che questa fase anticipa tutte le applicazioni in esecuzione sulla CPU specificata, permettendo di avere processi hard IRQIn questo contesto (esecuzione sulla stessa CPU come hard IRQ, minimizzando un sovraccarico di blocco), il kernel rimuove il frame dai NIC Hardware Buffer e lo processa attraverso lo stack di rete. Da qui il frame viene inoltrato, scartato o passato ad un socket in ascolto di destinazione.Se passato ad un socket, il frame viene associato ad una applicazione che detiene il socket stesso. Questo processo viene eseguito in modo interattivo fino a quando il NIC Hardware Buffer non possiede alcun frame, o fino al raggiungimento del device weight (dev_weight
). Per maggiori informazioni sul device weight consultare Sezione 8.4.1, «NIC Hardware Buffer» - Ricezione applicazione: l'applicazione riceve il frame e lo rimuove dalla coda di qualsiasi socket posseduto tramite le chiamate POSIX standard (
read
,recv
,recvfrom
). A questo punto i dati ricevuti tramite la rete non saranno più presenti nello stack.
Affinità CPU/cache
8.4. Risoluzione problematiche comuni di perdita dei frame/messa in coda
8.4.1. NIC Hardware Buffer
softirq
il quale viene invocato dal NIC tramite una interruzione. Per interrogare lo stato della coda usare il seguente comando:
ethtool -S ethX
ethX
con il nome del dispositivo corrispondente del NIC. Ciò mostrerà il numero di frame persi all'interno di ethX
. Spesso le perdite si verificano a causa di una carenza di spazio del buffer usato per archiviare i frame.
- Traffico
- Per impedire la saturazione della coda rallentare il traffico inserito. Per fare questo filtrare il numero di gruppi multicast, riducendo il traffico di trasmissione e operazioni simili.
- Lunghezza della coda
- Alternativamente aumentate la lunghezza della coda. Per fare questo è necessario aumentare il numero di buffer in una coda specifica fino a raggiungere il livello massimo permesso dal driver. Per fare questo modificate i parametri
rx
/tx
diethX
usando:ethtool --set-ring ethX
Inserire i valorirx
otx
al comando sopra indicato. Per maggiori informazioni consultareman ethtool
. - Peso del dispositivo
- È possibile aumentare la velocità con la quale viene "svuotata" una coda. Per fare questo modificare il peso del dispositivo del NIC in modo appropriato. Questo attributo si riferisce al numero massimo di frame che il NIC è in grado di ricevere prima che il contesto
softirq
rilasci la CPU modificando la sua programmazione. L'attributo è controllato da/proc/sys/net/core/dev_weight
.
8.4.2. Coda del socket
softirq
. Successivamente le applicazioni possono svuotare la coda dai socket corrispondenti tramite read
, recvfrom
o entità simili.
netstat
; la colonna Recv-Q
mostra la dimensione della coda. In generale se si verifica una saturazione essa verrà gestita in modo simile a quelle del NIC hardware buffer (es. Sezione 8.4.1, «NIC Hardware Buffer»):
- Traffico
- Usate la prima opzione per rallentare il traffico degli input configurando la velocità con la quale viene riempita la coda. Per fare questo filtrare o rimuovere i frame. È possibile altresì rallentare il traffico riducendo il peso del dispositivo del NIC[6].
- Profondità coda
- È possibile impedire la saturazione della coda aumentandone la profondità. Per fare questo aumentare il valore del parametro del kernel
rmem_default
o dell'opzioneSO_RCVBUF
. Per maggiori informazioni consultare Sezione 8.2, «Impostazioni di rete ottimizzate». - Frequenza chiamata dell'applicazione
- Quando possibile ottimizzare l'applicazione in modo da aumentare la frequenza delle chiamate. Per fare questo modificare o riconfigurare l'applicazione della rete per eseguire un numero maggiore di chiamate POSIX (come ad esempio
recv
,read
). Così facendo è possibile "svuotare" la coda più velocemente.
8.5. Considerazioni multicast
softirq
.
softirq
. L'aggiunta di un listener ad un gruppo implica la creazione da parte del kernel di una copia aggiuntiva per ogni frame ricevuto per quel gruppo.
softirq
può risultare in una perdita di frame sia nella coda del socket che sulla scheda di rete. Tempi di esecuzione softirq
maggiori riducono l'opportunità di esecuzione delle applicazioni in sistemi molto carichi, e la velocità con la quale saranno persi i frame multicast aumenterà a causa di un incremento del numero di applicazioni in ascolto ad un gruppo multicast con traffico elevato.
/proc/sys/net/core/dev_weight
. Per maggiori informazioni sul peso e sulle implicazioni dovute alla sua modifica consultate Sezione 8.4.1, «NIC Hardware Buffer».
Appendice A. Diario delle Revisioni
Diario delle Revisioni | |||||
---|---|---|---|---|---|
Revisione 4.0-22.1.400 | 2013-10-31 | Rüdiger Landmann | |||
| |||||
Revisione 4.0-22.1 | Thu Apr 18 2013 | Chester Cheng | |||
| |||||
Revisione 4.0-22 | Fri Feb 15 2013 | Laura Bailey | |||
| |||||
Revisione 4.0-19 | Wed Jan 16 2013 | Laura Bailey | |||
| |||||
Revisione 4.0-18 | Tue Nov 27 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-17 | Mon Nov 19 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-16 | Thu Nov 08 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-15 | Wed Oct 17 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-13 | Wed Oct 17 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-12 | Tue Oct 16 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-9 | Tue Oct 9 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-6 | Thu Oct 4 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-3 | Tue Sep 18 2012 | Laura Bailey | |||
| |||||
Revisione 4.0-2 | Mon Sep 10 2012 | Laura Bailey | |||
| |||||
Revisione 3.0-15 | Thursday March 22 2012 | Laura Bailey | |||
| |||||
Revisione 3.0-10 | Friday March 02 2012 | Laura Bailey | |||
| |||||
Revisione 3.0-8 | Thursday February 02 2012 | Laura Bailey | |||
| |||||
Revisione 3.0-5 | Tuesday January 17 2012 | Laura Bailey | |||
| |||||
Revisione 3.0-3 | Wednesday January 11 2012 | Laura Bailey | |||
| |||||
Revisione 1.0-0 | Friday December 02 2011 | Laura Bailey | |||
|