Ricerca

6.4.3. Noop

download PDF
Lo scheduler Noop I/O implementa un semplice algoritmo di programmazione first-in first-out (FIFO). Il merge delle richieste si verifica su un livello del blocco generico, ma risulta essere un last-hit cache. Se un sistema è stato associato ad una CPU e lo storage risulta essere veloce, questo tipo di scheduler I/O potrebbe essere quello migliore da usare.
Di seguito vengono riportati i parametri disponibili per il livello del blocco.

/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 da max_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 diminuire max_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 da 512 byte a 1 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 di nr_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 a 1), 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 un nr_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 esempio 8192. 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 su 1 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.
Red Hat logoGithubRedditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita ilBlog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

© 2024 Red Hat, Inc.