Comprendre les profils optimisés recommandés par RedHat

Nous allons déployer tuned (et numad) sur ~ 1000 serveurs, la majorité d'entre eux étant des serveurs VMware sur NetApp ou 3Par.

Selon la documentation de RedHats, nous devons choisir le virtual-guestprofil. Ce qu'il fait peut être vu ici: tuned.conf

Nous changeons le planificateur d'E / S en NOOP car VMware et NetApp / 3Par devraient faire une planification suffisante pour nous.

Cependant, après avoir enquêté un peu, je ne sais pas pourquoi ils augmentent vm.dirty_ratioet kernel.sched_min_granularity_ns.

Pour autant que j'ai compris, une augmentation vm.dirty_ratiode 40% signifie que pour un serveur avec 20 Go de RAM, 8 Go peuvent être sales à tout moment, à moins d' vm.dirty_writeback_centisecsêtre touché en premier. Et pendant le rinçage de ces 8 Go, toutes les E / S de l'application seront bloquées jusqu'à ce que les pages sales soient libérées.

Augmenter le dirty_ratio signifierait probablement des performances d'écriture plus élevées aux pics, car nous avons maintenant un cache plus important, mais là encore, lorsque le cache se remplit, les E / S seront bloquées pendant un temps considérablement plus long (plusieurs secondes).

L'autre est la raison pour laquelle ils augmentent le sched_min_granularity_ns. Si je comprends bien, l'augmentation de cette valeur diminuera le nombre de tranches de temps par epoch ( sched_latency_ns), ce qui signifie que les tâches en cours d'exécution auront plus de temps pour terminer leur travail. Je peux comprendre que c'est une très bonne chose pour les applications avec très peu de threads, mais par exemple. apache ou d'autres processus avec beaucoup de threads ne seraient-ils pas contre-productifs?

La réponse courte est que tout réglage est une conjecture et n'a de valeur que s'il est sauvegardé avec des données empiriques: essayez-le. Mesure le. Si vous ne l'aimez pas, ajustez-le.

Une réponse plus longue:

Augmenter le dirty_ratio signifierait probablement des performances d'écriture plus élevées ... IO sera bloqué pendant une durée considérablement plus longue

Non. L'augmentation du taux de pollution signifie que votre système est moins susceptible d'entrer dans un état où il doit commencer à bloquer les écritures. L'inconvénient est qu'il y a plus de mémoire utilisée et plus de risques de perte de données en cas de panne.

ce qui signifie que l'exécution des tâches aura plus de temps pour terminer leur travail

Les processus céderont généralement avant l'expiration de leur tranche de temps. Le problème avec une machine virtuelle est que votre machine peut être en concurrence pour le CPU et le cache L1 / L2 avec d'autres machines virtuelles - des niveaux élevés de commutation de tâches (en raison de la préemption) ont un impact important sur le débit. Le type d'applications qui sont habituellement déployées dans des machines virtuelles sont celles qui sont liées au processeur (serveurs Web, serveurs d'applications).

Oui, l'augmentation du débit (qui s'applique à tous les types d'applications) se fera au prix d'une augmentation de la latence - mais celle-ci est de l'ordre des microsecondes lorsque la plupart des transactions prennent des millisecondes. Si vous avez besoin d'une capacité en temps réel / d'une latence très faible, vous ne devriez pas utiliser de machine virtuelle.

Voici le calendrier des configurations adm-tuned ...

Je pense qu'il est utile de les voir sous forme de tableau. La principale chose à noter est que les paramètres par défaut de RHEL6 sont nulles !! L'autre chose est que les profils de stockage d'entreprise et d'invités virtuels sont identiques, sauf pour une permutation réduite du côté invité virtuel (c'est logique, non?).

En ce qui concerne une recommandation sur l'élévateur d'E / S de stockage, vous avez quelques couches d'abstraction sur la couche de stockage. L'utilisation du planificateur noop aurait du sens si vous utilisiez des RDM ou présentiez du stockage directement à vos machines virtuelles. Mais comme ils vont vivre sur NFS ou VMFS, j'aime toujours les options de réglage supplémentaires offertes par le planificateur de délais.

Les profils optimisés peuvent être modifiés à la volée sur les systèmes en cours d'exécution, donc si vous avez des préoccupations, testez avec votre application et votre environnement spécifique et testez-les.

Regardez les vidéos de réglage des performances de Shak et Larry de Summit, ils parlent en profondeur des profils réglés.

• Partie 1 - http://www.youtube.com/watch?v=fATEiBJ3pKw
• Partie 2 - http://www.youtube.com/watch?v=km-vLELmWLs

L'un des plus grands points à retenir est que les profils ne sont qu'un point de départ recommandé, pas des nombres immuables qui sont magiquement parfaits pour chaque environnement.

Commencez avec un seul profil et jouez avec les paramètres. Générez une bonne charge de travail de test de type production et mesurez les mesures qui sont importantes pour votre entreprise.

Changez une chose à la fois et enregistrez chaque résultat à chaque itération. Lorsque vous avez terminé, examinez les résultats et choisissez les paramètres qui ont donné les meilleurs résultats. C'est votre profil optimisé.