Charge élevée due à l'attente des E / S dans Ubuntu 12.04 sur l'instance EC2


9

J'utilise le serveur Ubuntu 12.04, j'ai du mal à trouver la cause de la charge, j'ai vu le temps de réponse du serveur changer depuis la semaine dernière

après avoir lu le dépannage de Linux, partie I: charge élevée

Il semble qu'il n'y ait pas de problème avec le CPU et la RAM, et cette charge peut être liée à la charge liée aux E / S en utilisant la topcommande que j'ai obtenue après la sortie

Charge et utilisation de la mémoire

Voilà 97.6%wa, la RAM est gratuite et aucun échange n'est utilisé.

Voici la sortie de la commande iostatqui sème qu'il y a89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

J'ai également utilisé iotopce qui, après l'intervalle de correction, montre 99% d'E / S, le disque écrit que j'observateur1266 KB/s

entrez la description de l'image ici

et

entrez la description de l'image ici

Est-ce mauvais? lorsque le temps de réponse diminue. qu'est-ce qui cause cela?

MODIFICATIONS demandées par d'autres

iftop O / P

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

sortie de iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@shodanshok point 2

entrez la description de l'image ici

iotop -a

entrez la description de l'image ici


1
99% IOwait avec 0 disque en lecture et en écriture ne semble pas bon. Ici, serverfault.com/questions/426181/…, il est mentionné que les E / S pourraient être liées non seulement à l'activité du disque, mais également au réseau. Pourriez-vous le vérifier avec, par exemple, iftop (et d'autres outils également)?
Andrey Sapegin

@AndreySapegin a ajouté iftop
Straw Hat

Je pense que problème était avec disque sur lequel AWS instance a été déployée .. J'ai créé AMI d'instance en cours et lancé une nouvelle instance à l' aide que .. Maintenant , il n'y a pas de charge supplémentaire sur E / S
Chapeau de paille

@StrawHat cela signifie-t-il que vous pensez qu'il y a eu un problème avec le disque de votre première instance?
sbrattla

@sbrattla Non je pense. après quelques jours, le même problème est apparu
Chapeau de paille

Réponses:


2

Réglez votre service mysql pour éviter de toucher au disque et faites attention à votre file d'attente postfix, vous pouvez avoir beaucoup d'e-mails dans une file d'attente sensible aux E / S (c'est-à-dire différés, petits itens avec un comportement de lecture aléatoire).

Votre système de messagerie électronique a été utilisé comme relais pour les spammeurs.

Jetez un œil à la documentation de postfix et limitez l'accès relais à votre MTA.


déplacer mysql vers une instance RDS fonctionnera?
Chapeau de paille

1
En quelque sorte, le problème principal est dû au nombre élevé d'itens dans une file d'attente postfix mangeant vos iops, vous pouvez le voir avec la qshape deferredcommande.
fgbreel

postconf: warning: /etc/postfix/main.cf: unused parameter: virtual_mailbox_limit_maps=proxy:mysql:/etc/zpanel/configs/postfix/mysql-virtual_mailbox_limit_maps.cf
Chapeau de paille

postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1a obtenu ces erreursqshape deferred
Chapeau de paille

1
Je pense que votre suffixe peut être mal configuré, mais pour votre problème actuel, jetez un œil au nombre d'e-mails que vous avez /var/lib/postfix/deferred. Déplacez-les dans la holdfile d' attente pour une enquête plus approfondie ou un nettoyage.
fgbreel

1

Modifié après des informations supplémentaires recueillies à l'aide d'iostat et d'iotop.Votre
disque est chargé à 100% car il manque des IOPS disponibles: selon l'iostat, vous avez une constante 50+ IOPS (85 w / s - 35 fusionnés w / s). Les instances EC2, en particulier celles à bas prix, ont un plafond élevé sur les IOPS soutenus (dans la plage de 30 à 50 IOPS).

Selon la nouvelle sortie iotop, mysql et bounce consomment une quantité importante d'IOPS. Cependant, la sortie d'iotop ne semble pas complète, ou du moins mal triée. Pouvez-vous réexécuter le tri «iotop -a» une fois par IOPS et une autre fois par écriture sur disque?

Réponse originale
Mon pari: le processus de "rebond" émet de nombreuses écritures synchronisées qui étouffent le périphérique de disque virtuel proposé par Amazon (à propos, quel profil utilisez-vous? Les disques EC2 ont des règles assez strictes pour les E / S continues vs rafales).

Quoi qu'il en soit, identifier ce qui brûle la bande passante d'E / S peut parfois être quelque peu difficile. Bien que iotop soit un très bon outil, il ne vous fournit parfois pas les informations requises. Nous devons aller plus loin. Alors, suivez ces conseils:

  1. Tout d'abord, nous devons identifier le type d'E / S en cours de traitement et le périphérique de bloc affecté.
    S'il vous plaît exécutez la commande suivante: iostat -x -k 5 2. Veuillez rapporter les deux ensembles de résultats.
  2. Ensuite, il faut identifier les processus en attente d'E / S .
    Quand peut utiliser "top" pour cela: lancez-le, appuyez sur shift + f (F), puis w, puis enter, puis shift + r (R). Les premiers processus seront ceux en état D ou D + (ie: en attente de disque / réseau). Veuillez rapporter la liste.
  3. Utilisez iotop pour afficher les valeurs d'E / S accumulées pour les processus .
    Exécutez iotop -apendant environ une minute et collez ici la sortie.

iostat -x -k 5 2 et également ajouté en question
Chapeau de paille

1

Un peu tard, mais j'ai eu le même problème sur une machine similaire et j'ai découvert que le problème était un tas de tables MySQL corrompues. Étant donné que certaines de ces tables contenaient beaucoup de données, elles produisaient beaucoup de temps d'attente d'E / S.

Regardez /var/log/mysql/error.logou utilisez mysqlcheckpour trouver et réparer des données corrompues.


0

Comme indiqué ci-dessus, il est fort probable que votre instance EC2 soit livrée avec un plafond d'E / S ou peut-être qu'elle soit sauvegardée sur un volume Amazon EBS Standard qui ne fournit tout simplement pas beaucoup d'E / S. Jetez un œil à cette page - elle décrit les différents types de volumes proposés par Amazon.

Même si vous avez un volume lent, vous devriez toujours pouvoir y écrire assez rapidement, mais si votre chargement est aléatoire par nature, comme il semble qu'il puisse l'être (substance SQL), vous voudrez peut-être mettre à niveau l'IOPS capacité, car cela met généralement la limite supérieure sur les performances SQL.

Donc - d'après vos chiffres, il semblerait que vous pourriez manquer d'IOPS en utilisant le stockage standard. Acheter un stockage plus rapide n'est pas si cher. Jetez un oeil à cela .


-3

Le disque peut être en mode non DMA. Veuillez vérifier l'état DMA du lecteur. (commande hdparm)

Si ce n'est pas le cas, quelque chose d'autre peut générer beaucoup d'interruptions. Quelqu'un se souvient-il de ceux de la bonne vieille ère DOS?


EC2 est une plateforme de virtualisation et utilise des disques virtuels. DMA n'est pas le coupable ici. Quoi qu'il en soit, une tempête IRQ impose un péage sur le processeur, pas sur le disque.
shodanshok

Oui et IRQ signifie des interruptions.
Overmind

EC2 est aussi éloigné que possible de ce genre de problème, je dirais. Les E / S sont limitées par le type d'instance - et, en fin de compte, par une solution SAN vraiment coûteuse qui a beaucoup de capacité.
MrMajestyk
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.