Question Charge moyenne élevée en raison de la charge de processeur élevée du système (% sys)


Nous avons un serveur avec un site web à fort trafic. Récemment nous sommes passés de

2 x 4 serveurs principaux (8 cœurs dans / proc / cpuinfo), 32 Go de RAM, exécutant CentOS 5.x, à

2 x 4 serveurs principaux (16 cœurs dans / proc / cpuinfo), 32 Go de RAM, exécutant CentOS 6.3

Serveur exécutant nginx en tant que proxy, serveur mysql et sphinx-search.

Le trafic est important, mais les bases de données mysql et sphinx-search sont relativement petites et, généralement, tout fonctionne à toute vitesse.

Aujourd'hui, le serveur a connu une charge moyenne de 100 ++. En regardant top et sar, nous avons remarqué que (% sys) est très élevé - 50 à 70%. L'utilisation du disque était inférieure à 1%. Nous avons essayé de redémarrer, mais le problème existait après le redémarrage. À tout moment, le serveur disposait d'au moins 3 à 4 Go de RAM libre.

Le seul message affiché par dmesg était "Possibilité d'inondation SYN sur le port 80. Envoi de cookies.".

Voici un extrait de sar

11:00:01        CPU     %user     %nice   %system   %iowait    %steal     %idle
11:10:01        all     21.60      0.00     66.38      0.03      0.00     11.99

Nous savons qu'il s'agit d'un problème de trafic, mais nous ne savons pas comment procéder pour l'avenir ni où chercher une solution.

Existe-t-il un moyen de trouver où exactement ces "66,38%" sont utilisés?

Toute suggestion serait appréciée.


mettre à jour: Aujourd'hui, la charge moyenne est "normale" et "sys%" est correct ~ 4%. Cependant, le trafic actuel est environ 20-30% inférieur à celui d'hier. Cela me fait penser que le problème d’hier est dû à certains paramètres du noyau pour TCP.


5
2017-11-10 21:11


origine


Quel type d'interface réseau utilisez-vous? Que dit "ethtool -k <iface>"? - wazoox
ethtool -k em1 Paramètres de déchargement pour em1: rx-checksumming: on tx-checksumming: on scatter-rassembl: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload : on-large-receive-offload: off - Nick
L’hyperthreading est apparemment activé sur votre système actuel, contrairement à l’ancien. C'est peut-être le coupable. Les performances HT peuvent parfois être délicates. Je voudrais essayer de désactiver HT (dans le BIOS) et voir si cela fait une différence significative. - wazoox
Parce que nous n'avons pas d'accès physique, nous parlerons avec le fournisseur d'accès et essaierons demain matin. - Nick
à partir de 2 jours, nous sommes en train de tester avec hyper-threading off. jusqu'à présent, tout fonctionne très bien. nous saurons avec certitude samedi que des embouteillages importants se produiront. Si vous souhaitez formuler votre commentaire comme réponse normale, je pourrai donc l'accepter demain soir. Merci beaucoup. - Nick


Réponses:


Je voudrais installer au sommet du référentiel EPEL. Atop devrait vous aider à montrer comment diagnostiquer l’activité de% sys.

Atop dispose également d'une fonctionnalité atop -r qui vous permettra de parcourir les journaux en arrière et en arrière dans le temps à l'aide des touches t / T.

Jetez également un coup d'oeil à / proc / interrupts et à travers votre / var / log / httpd / logs et triez-les par ip pour voir s'il existe une adresse IP suspecte causant des quantités anormales de trafic httpd.

Je cron un chat / proc / interrups dans un fichier journal. Recherchez des deltas élevés dans les interruptions.


1
2017-12-05 00:56