Moyenne de charge acceptable

Nous avons déployé notre nouveau serveur de messagerie Linux / Exim / Spamassassin vendredi (toujours une bonne idée de déployer la veille d'un long week-end où aucun administrateur n'est là). La charge oscille autour de 1,3 en moyenne sur 15 minutes.

La machine est réactive et les courriers sont livrés dans un délai raisonnable. Pouvons-nous supposer que cela est acceptable?

Comment une certaine quantité de charge est-elle jugée acceptable ou non? Quelles métriques sont utilisées?

Règle de base: si le système est réactif, s'il fonctionne en temps opportun, alors tout va bien.

Les charges inférieures à deux ne sont pas très inquiétantes. J'ai eu des systèmes frappés quatre ou cinq et fonctionne toujours bien, bien que ce soit un indicateur qu'il y a beaucoup de problèmes de file d'attente avec le réseau ou les lecteurs (les problèmes d'E / S peuvent causer des charges élevées même si le système est très réactif).

Vérifiez régulièrement la longueur de votre file d'attente de messagerie et les journaux pour les problèmes non distribuables et les problèmes de cette nature. Si la file d'attente de livraison reste relativement faible, c'est bien.

Vous pouvez obtenir des moyennes de disque et des informations d'E / S réseau mais si vous ne voyez pas de problèmes de livraison (j'ai envoyé le message il y a quinze minutes et il n'est pas encore arrivé!) Et vous pouvez travailler sur le système via la console ( ou ssh) sans beaucoup de latence, ça devrait aller.

La moyenne de charge est une valeur qui donne une idée du nombre de processeurs nécessaires au noyau pour pouvoir exécuter toutes les tâches quand il le faut sans attendre.
Dans votre cas, si vous avez 2 CPU / Core ou plus. Il n'y a pas de problème. Si vous n'avez qu'un seul processeur avec 1 cœur, cela signifie qu'il y a «trop» de temps entre le moment où votre application veut s'exécuter et le moment où le noyau l'exécute. Une charge> "nombre de cpu / core" ne sera pas un problème pour un système de messagerie jusqu'à ce qu'elle atteigne une valeur trop élevée pendant trop longtemps.
Bien sûr, ce n'est pas une règle et une valeur à donner et bien que vous receviez votre courrier en peu de temps, ça va. Mais vous devez probablement commencer à regarder de près votre serveur lorsque la charge est supérieure à 2 * nombre de cpu / core trop souvent pendant une «longue» période (~ 1 heure).
Encore une fois pour un serveur de messagerie, ce ne sera pas un gros problème mais cela commencera à signifier que votre serveur est un peu surchargé.

Comme toujours pour les questions liées au réglage, il n'y a pas de réponse oui / non, tout dépend :-)

Cela dit, une charge de 1,3 ne semble pas élevée, surtout si vous avez une configuration de processeur multicœur. Si le numéro de chargement est le même que le nombre de cœurs, alors tous les cœurs ont toujours un processus prêt à être exécuté.

En fin de compte, si, comme vous le dites, les messages sont livrés en temps opportun, les performances sont bonnes :-)

top

vous donnera des mesures de base en temps quasi suffisant en temps réel.

Une charge moyenne inférieure au nombre de processeurs que vous avez signifie qu'il y a des processeurs assis sans rien à faire. Égaux signifie qu'ils travaillent tous en ce moment. Plus grand signifie qu'il existe des processus qui pourraient être en cours d'exécution, mais qui sont bloqués dans la file d'attente.

Pour les trucs super sensibles au temps comme un serveur VoIP ou memcache, vous voulez que votre charge moyenne soit bien inférieure au nombre de cœurs. Pour les choses asynchrones qui peuvent vivre avec la sauvegarde occasionnelle (comme le courrier électronique), vous pouvez facilement exécuter 4x le nombre de cœurs.

La plus grande mise en garde à retenir est que les processus qui attendent des E / S disque ou réseau mais qui sont autrement exécutables apparaissent toujours dans la moyenne de charge. Donc, si vous avez un serveur apache alimentant des jpg à 56k utilisateurs, vous pouvez exécuter une moyenne de charge beaucoup plus élevée que si vous la renvoyez des réponses php / quel que soit le script à un proxy / loadbalancer sur un LAN gigabit. Dans votre cas, une connexion smtp à un serveur de messagerie lent qui prend une éternité pour transférer une pièce jointe affichera un processus 1 dans la file d'attente d'exécution, mais pourrait être interrompue vingt fois pour envoyer un rapide e-mail à Gmail sans problème.

La poussée arrive, la moyenne de charge est comme la DOW. Il ne mesure en aucun cas "l'économie", les gens l'utilisent simplement comme une métrique très corrélée car il est facile d'en parler. Concentrez-vous sur la surveillance des mesures qui vous intéressent réellement, comme la profondeur de la file d'attente de remise et les messages par seconde.

Combien de cœurs avez-vous? cat / proc / cpuinfo | processeur grep | wc -l

(mise en garde: l'hyperthreading ressemble à plus de cœurs, mais ce n'est pas le cas)

Si votre niveau de charge est inférieur au nombre de processeurs, vous êtes généralement d'accord.

Jetez également un coup d'œil en haut et appuyez sur «1» et vous pouvez regarder la charge individuelle de chaque processeur.

Oui, c'est assez acceptable, et généralement quelque chose à prévoir avec un filtre de messagerie.

Notre configuration est un peu différente. Nous avons un serveur séparé pour SpamAssassin, tandis que notre serveur POP exécute ClamAV pour rechercher les virus. Le serveur POP fonctionne généralement sous une charge de serveur de 2, mais augmente parfois jusqu'à 10 ou plus. Notre serveur SpamAssassin, d'autre part, fonctionnait autour de 2 jusqu'à ce que nous installions également les filtres Openprotect.com, quand il a doublé l'utilisation du processeur et fonctionne maintenant sous environ 5 avec des pointes supérieures à 15. Ceci est toujours acceptable car nous ne le faisons pas avoir des retards dans le courrier qui se traduisent par une file d'attente de courrier croissante (nous utilisons qmail pour SMTP entrant), et il y a encore de la place pour économiser l'utilisation du processeur / mémoire.

Par coïncidence, je recommande fortement Munin pour surveiller vos serveurs. Il fait un excellent travail de démonstration visuelle des données historiques et de vous montrer quelles ressources vous avez à épargner. La surveillance en temps réel avec Top (1) ne vous aide pas beaucoup. :)

Oh, et en passant, le déploiement le vendredi avant le long week-end est un excellent moyen de travailler tout le week-end. Surtout pour les systèmes critiques comme un serveur de messagerie.

Comment est la consommation de mémoire? Est-il stable ou en croissance?

La charge ne semble pas hors norme. Si le serveur de messagerie est réactif et que le courrier est acheminé, je dirais que la seule mesure de l'échec au-delà de la consommation de mémoire serait si les mauvais e-mails passent (spam).

Attention, ce serait votre premier vrai test. Je le surveillerais probablement légèrement aujourd'hui. Si quelque chose va mal, le moment est venu.