Linux - réglage de contrôleurs RAID matériels réels (scsi et cciss)

J'ai constaté que lorsque j'ai dû faire des réglages pour réduire la latence par rapport au débit, j'ai diminué nr_requests par rapport à sa valeur par défaut (jusqu'à 32). L'idée étant que des lots plus petits égalent une latence plus faible.

De même, pour read_ahead_kb, j'ai constaté que pour les lectures/écritures séquentielles, l'augmentation de cette valeur offre un meilleur débit, mais j'ai constaté que cette option dépend vraiment de votre charge de travail et de votre modèle d'IO. Par exemple, sur un système de base de données que j'ai récemment optimisé, j'ai modifié cette valeur pour qu'elle corresponde à une taille de page de base de données unique, ce qui a permis de réduire la latence de lecture. Augmenter ou diminuer cette valeur au-delà s'est avéré néfaste pour les performances dans mon cas.

En ce qui concerne les autres options ou paramètres des files d'attente des dispositifs de blocage :

max_sectors_kb \= J'ai fixé cette valeur pour qu'elle corresponde à ce que le matériel autorise pour un seul transfert (vérifiez la valeur du fichier max_hw_sectors_kb (RO) dans sysfs pour voir ce qui est autorisé).

nomerges \= ceci vous permet de désactiver ou d'ajuster la logique de consultation pour la fusion des demandes io. (Désactiver cette option peut vous faire économiser quelques cycles cpu, mais je n'ai pas vu d'avantage à modifier cette option pour mes systèmes, donc je l'ai laissée par défaut).

rq_affinité \= Je n'ai pas encore essayé, mais voici l'explication tirée de la documentation du noyau

Si cette option est "1", la couche de blocs migre les requêtes vers la couche de blocs. groupe" de processeurs qui a soumis la requête à l'origine. Pour certaines charges de travail, cette option permet une réduction significative des cycles de l'unité centrale en raison des effets de cache.
Pour les configurations de stockage qui doivent maximiser la distribution de l'achèvement la définition de cette option sur '2' force l'exécution de l'achèvement sur le serveur l'unité centrale requérante (en contournant la logique d'agrégation du "groupe")"

planificateur \= vous avez dit que vous aviez essayé la date limite et que rien ne s'était passé. J'ai testé à la fois noop et deadline, mais j'ai trouvé que deadline l'emportait pour les tests que j'ai effectués récemment pour un serveur de base de données.

NOOP a donné de bons résultats, mais pour notre serveur de base de données, j'ai pu obtenir de meilleures performances en ajustant le planificateur de délais.

Options pour l'ordonnanceur de délai situé sous /sys/block/{sd,cciss,dm-}*/queue/iosched/ :

fifo_batch \= un peu comme nr_requests, mais spécifique à l'ordonnanceur. La règle d'or est de diminuer cette valeur pour réduire la latence ou de l'augmenter pour augmenter le débit. Contrôle la taille des lots de requêtes de lecture et d'écriture.

write_expire \= définit le délai d'expiration des lots d'écriture, la valeur par défaut étant de 5000 ms. Une fois de plus, diminuer cette valeur réduit la latence d'écriture, tandis que l'augmenter augmente le débit.

read_expire \= définit le délai d'expiration pour les lots de lecture ; la valeur par défaut est de 500 ms. Les mêmes règles s'appliquent ici.

front_merges \= J'ai tendance à désactiver cette fonction, qui est activée par défaut. Je ne vois pas l'intérêt pour l'ordonnanceur de gaspiller des cycles de calcul en essayant de fusionner les demandes d'entrées-sorties.

écrit_affamé \= puisque deadline est orienté vers la lecture, le défaut est de traiter 2 lots de lecture avant de traiter un lot d'écriture. J'ai trouvé que la valeur par défaut de 2 convenait à ma charge de travail.