Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

6.4.3. Noop

L'ordonnanceur d'E/S « Noop » implémente un simple algorithme de programmation FIFO (« Premier arrivé, premier sorti », de l'anglais « First-in first-out »). La fusion des requêtes se produit sur la couche bloc générique, mais il s'agit simplement du dernier cache traité. Si un système est limité au processeur et que le stockage est rapide, cet ordonnanceur d'E/S pourrait être le meilleur à utiliser.
Ci-dessous figurent les réglages disponibles à la couche de bloc.

réglages /sys/block/sdX/queue

add_random
Dans certains cas, l'en-tête des événements d'E/S contribuant au pool d'entropie de /dev/random est mesurable. Dans certains cas, il peut être désirable de définir cette valeur sur 0.
max_sectors_kb
Par défaut, la taille de requête maximale envoyée sur disque est de 512 Ko. Ce réglage peut être utilisé pour élever ou abaisser cette valeur. La valeur minimale est limitée par la taille du bloc logique ; la valeur maximale est limitée par max_hw_sectors_kb. Il existe des disques SSD qui fonctionnent moins bien lorsque la taille des E/S dépasse la taille des blocs de suppression internes. Dans ces cas, il est recommandé de régler max_hw_sectors_kb vers le bas afin de correspondre avec la taille du bloc de suppression. Vous pouvez effectuer des tests à l'aide d'un générateur d'E/S tel que iozone ou aio-stress ; par exemple, en variant la taille d'enregistrement de 512 octets à 1 Mo.
nomerges
Ce réglage est principalement une aide au débogage. La plupart des charges de travail bénéficient des fusions de requêtes (même sur des stockages plus rapides, comme les SSD). Cependant, dans certains cas, il est préférable de désactiver la fusion, comme lorsque vous souhaitez voir combien d'IOPS (E/S par seconde) un backend de stockage peut traiter sans désactiver la lecture à l'avance ou sans effectuer d'E/S aléatoires.
nr_requests
Chaque file d'attente de requêtes possède une limite du nombre total de descripteurs de requêtes pouvant être alloués à chaque E/S de lecture et d'écriture. Par défaut, ce nombre est 128, ce qui signifie que 128 lectures et 128 écritures peuvent être mises en file d'attente à la fois avant de mettre un processus en veille. Le processus mis en veille sera le suivant à essayer d'allouer une requête et pas nécessairement le processus ayant alloué toutes les requêtes disponibles.
Si vous possédez une application sensible à la latence, alors vous devriez considérer les possibilités d'abaisser la valeur de nr_requests dans la file d'attente de votre requête et de limiter la profondeur de la file d'attente de commandes sur le stockage à un chiffre bas (aussi bas que 1 si vous le souhaitez), de manière à ce que les E/S de ré-écriture ne puissent pas allouer tous les descripteurs de requêtes disponibles et remplir la file d'attente du périphérique avec des E/S d'écriture. Une fois que les nr_requests ont été alloués, tous les autres processus tentant d'effectuer des E/S seront mis en veille en attendant que des requêtes deviennent disponibles. Cela rend le procédé plus équitable puisque les requêtes sont ensuite distribuées en tourniquet « round-robin » (plutôt que de laisser un seul processus toutes les consommer en de rapides successions). Remarquez qu'il s'agit uniquement d'un problème lors de l'utilisation des ordonnanceurs « Deadline » ou « Noop » car la configuration par défaut de CFQ sert de protection contre cette situation.
optimal_io_size
Sous certaines circonstances, le stockage sous-jacent rapportera une taille d'E/S optimale. Ceci est très commun dans les RAID logiciels et matériels, où la taille d'E/S optimale est la taille de bande. Si cette valeur est rapportée, les applications devraient délivrer des E/S correspondantes à la taille des E/S optimales et si possible en multiples de celles-ci.
read_ahead_kb
Le système d'exploitation peut détecter lorsqu'une application lit des données de manière séquentielle depuis un fichier ou un disque. Dans de tels cas, il procède à un algorithme de lecture à l'avance intelligent, dans lequel plus de données du disque que celles requises par l'utilisateur sont lues. Ainsi, lorsque l'utilisateur tentera à nouveau de lire un bloc de données, elles se trouveront déjà dans le cache de la page du système d'exploitation. L'inconvénient potentiel de ce procédé est que le système d'exploitation pourrait lire plus de données que nécessaire, ce qui occupe de l'espace dans le cache de la page jusqu'au vidage résultant de la forte pression de mémoire. Sous ces circonstances, avoir de multiples processus effectuant de fausses lectures à l'avance augmenterait la pression sur la mémoire.
Pour les périphériques mappeurs de périphériques, il est de bonne augure d'augmenter la valeur de read_ahead_kb à un nombre élevé, comme 8192 par exemple. La raison derrière ceci est qu'un périphérique mappant des péripphériques est souvent composé de multiples périphériques sous-jacents. Définir cette valeur sur son défaut (128 Ko), multiplié par le nombre de périphériques que vous mappez est un bon début pour effectuer une optimisation.
rotational
Les disques durs traditionnels sont rotationnels (composés de plateaux effectuant des rotations). Les disques SSD ne le sont pas. La plupart des disques SSD publiciseront cela correctement. Cependant, si vous rencontriez un jour un périphérique n'expliquant pas clairement ce procédé, il pourrait se révéler nécessaire de définir « Rotational » sur 0 ; lorsque « Rotational » est désactivé, l'élévateur des E/S n'utilise pas de logique servant à réduire les recherches puisqu'il n'existe que de petites pénalités pour les opérations de recherche sur des média non-rotationnels.
rq_affinity
Les complétions des E/S peuvent être traitées sur différents CPU à partir de celui qui a délivré l'E/S. Définir rq_affinity sur 1 cause au noyau de délivrer des achèvements au CPU sur lequel l'E/S a été effectuée. Ceci peut améliorer l'efficacité de la mise en cache de données du CPU.