Aller au contenu


Pics CPU et lenteurs d'accès


  • Veuillez vous connecter pour répondre
5 réponses à ce sujet

#1 Mickelebof

Mickelebof

    Membre avancé

  • Membres
  • 39 messages

Posté 07 septembre 2018 - 21:00

Bonjour,

Voilà, je rencontre un soucis sur lequel je suis depuis un moment, sans pouvoir vraiment trouver la cause.
Les roles ont été éclatés sur plusieurs serveurs (ldap, proxy http, proxy imap, proxy pop, mta, store-ui et store-mbox).
Actuellement il y a très peu de BAL sur l'infra qui est énorme (27 serveurs).
Le symptôme est un pic CPU aléatoire sur certains serveur mbox, entraînant un gros ralentissement visible à l'utilisation du webmail (jusqu'à plusieurs dizaines de secondes pour afficher la page.).

Voici le graph d'aujourd'hui sur un de ces mbox :

Image IPB



Dans les logs, je ne vois rien de plus qu'en temps normal (à priori).

J'ai des slow queries mysql (exemple sur le derniers pics CPU de 19h45 à 19h55) :
# Time: 180907 19:43:08
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110275 Schema: zimbra QC_hit: No
# Query_time: 0.000279 Lock_time: 0.000035 Rows_sent: 1 Rows_examined: 351
# Rows_affected: 0
SET timestamp=1536342188;
SELECT MAX(sequence) FROM mboxgroup29.tombstone WHERE mailbox_id = 29 AND date <= 1528306988;
# Time: 180907 19:44:08
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110280 Schema: zimbra QC_hit: No
# Query_time: 0.000222 Lock_time: 0.000070 Rows_sent: 0 Rows_examined: 12
# Rows_affected: 0
SET timestamp=1536342248;
SELECT id FROM mailbox WHERE last_purge_at < 1533750248;
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110280 Schema: zimbra QC_hit: No
# Query_time: 0.000293 Lock_time: 0.000074 Rows_sent: 1 Rows_examined: 3
# Rows_affected: 0
SET timestamp=1536342248;
SELECT MAX(sequence) FROM mboxgroup30.tombstone WHERE mailbox_id = 30 AND date <= 1528307048;
# Time: 180907 19:48:08
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110275 Schema: zimbra QC_hit: No
# Query_time: 0.000283 Lock_time: 0.000084 Rows_sent: 1 Rows_examined: 37
# Rows_affected: 0
SET timestamp=1536342488;
SELECT MAX(sequence) FROM mboxgroup34.tombstone WHERE mailbox_id = 34 AND date <= 1528307288;
# Time: 180907 19:48:35
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110275 Schema: zimbra QC_hit: No
# Query_time: 0.000125 Lock_time: 0.000040 Rows_sent: 0 Rows_examined: 0
# Rows_affected: 0
SET timestamp=1536342515;
SELECT mailbox_id, item_id FROM pending_acl_push WHERE date < 1536342515379;
# Time: 180907 19:51:08
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110280 Schema: zimbra QC_hit: No
# Query_time: 0.000925 Lock_time: 0.000110 Rows_sent: 0 Rows_examined: 2
# Rows_affected: 0
SET timestamp=1536342668;
UPDATE mboxgroup25.mail_item, (SELECT parent_id pid, COUNT(*) count FROM mboxgroup25.mail_item WHERE mailbox_id = 25 AND (id = 582499 OR id = 582500) AND parent_id IS NOT NULL GROUP BY parent_id) AS x SET size = size - count, metadata = N
ULL, mod_metadata = 1233712, change_date = 1536342668 WHERE mailbox_id = 25 AND id = pid AND type = 4;
# Time: 180907 19:52:08
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110275 Schema: zimbra QC_hit: No
# Query_time: 0.000327 Lock_time: 0.000041 Rows_sent: 1 Rows_examined: 395
# Rows_affected: 0
SET timestamp=1536342728;
SELECT MAX(sequence) FROM mboxgroup26.tombstone WHERE mailbox_id = 26 AND date <= 1528307528;
# Time: 180907 19:53:09
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110275 Schema: zimbra QC_hit: No
# Query_time: 0.000468 Lock_time: 0.000057 Rows_sent: 0 Rows_examined: 0
# Rows_affected: 0
SET timestamp=1536342789;
REPLACE INTO mboxgroup27.revision_dumpster SELECT * FROM mboxgroup27.revision WHERE mailbox_id = 27 AND item_id IN (SELECT id FROM mboxgroup27.mail_item WHERE mailbox_id = 27 AND id IN (1232085, 1232099, 1232111, 1232127, 1232133, 1232148
, 1232183, 1232186, 1232189, 1232191) AND type IN (5,6,8,18,11,15,16,17) AND folder_id != 6);
# User@Host: zimbra[zimbra] @ localhost [127.0.0.1]
# Thread_id: 110275 Schema: zimbra QC_hit: No
# Query_time: 0.004146 Lock_time: 0.000028 Rows_sent: 1 Rows_examined: 7855
# Rows_affected: 0
SET timestamp=1536342789;
SELECT MAX(sequence) FROM mboxgroup27.tombstone WHERE mailbox_id = 27 AND date <= 1528307588;

Mais je ne sais pas si la cause est là, sachant qu'en général, c'est bien le mysqld qui consomme pas mal de CPU.
(à noter que j'ai des slow queries régulièrement et sans avoir de charge CPU...)

Tous les serveurs sont strictement dans les même version/update OS et Zimbra, à savoir : Release 8.8.9.GA.3019.UBUNTU16.64 UBUNTU16_64 NETWORK edition, Patch 8.8.9_P4

Si vous avez quelques idées/pistes... Merci :)

Mick
Zimbra ZNE 8.8.9 sur Ubuntu 16.04

#2 vdagost

vdagost

    Zimbra Jedi

  • Membres
  • PipPipPipPip
  • 522 messages
  • LocalisationLyon

Posté 10 septembre 2018 - 14:01

Salut,

En fait ce n'est pas des slow query, mais des query non indexées que tu vois dans le fichier /opt/zimbra/log/myslow.log.
Certaines tables n'ont pas d'index donc c'est normal.
Vu les temps de réponse (< 0.0001 sec) tu n'as pas de pb avec ta base de données mariadb.

Avec la commande top quels sont les processus qui utilisent tout ton CPU ? Avec la commande free vois-tu du swap ?

Si c'est les processus java alors que vois-tu dans le fichier /opt/zimbra/log/mailbox.log durant les pics de charge ?
Les mots clés elapsed et finished te donneront les temps de traitement.

Est-ce que la forte utilisation CPU que tu observes ne serait pas plutôt des I/O Wait ?

Victor
Zimbra 8.7.3 OSS + Zextras
11000 utilisateurs (10 stores)
RHEL 6

#3 Mickelebof

Mickelebof

    Membre avancé

  • Membres
  • 39 messages

Posté 10 septembre 2018 - 14:32

Bonjour,

Merci pour la réponse.
Ok donc je peux écarter le mariadb, merci :)

Les 2 process qui prennent le plus de CPU sont le mysqld et java (ils se relaient entre la première et deuxième place ;) )

Il n'y a aucun swap sur les serveurs (tout est monitoré, pas un seul Mo en swap).

En ce qui concerne l'I/O wait, il n'y en a pas (pareil, c'est monitoré) sauf pour l'exemple que j'ai pris sur le pic de 19h45 vendredi dernier (comme par hasard)
Mais d'après mes graph, sur tous les autres pics CPU, je n'ai pas d'I/O wait.

Les temps indiqués en "elapsed" et "finished" sont exprimés en millisecondes ?
Voici ceux que je trouve :
2018-09-07 19:42:41,877 INFO  [qtp66233253-16610:https:https://mon-server-mbox.domain.tld:7073/service/admin/soap/] [ip=10.10.10.05;port=35240;soapId=222a3d;] soap - AuthRequest elapsed=2
28;soapId=222a3c;] soap - DestroyWaitSetRequest elapsed=2495
2018-09-07 19:52:46,226 INFO  [qtp66233253-17124:https:https://mail.domain.tld/service/soap/SyncRequest] [name=ma-boite-mail@domain.tld;mid=23;ip=10.10.10.05;port=37618;ua=Zimbra-ZCO/8.8.9.1775 (10.0.17134  fr-FR) P4cc T34dc R4534;soapId=
222a77;] soap - SyncRequest elapsed=14682
2018-09-07 19:52:46,232 INFO  [qtp66233253-17123:https:https://mail.domain.tld/service/soap/MsgActionRequest] [name=ma-boite-mail@domain.tld;mid=23;ip=10.10.10.05;port=37620;ua=ZimbraWebClient - GC68 (Win)/8.8.9_GA_3019;soapId=222a78;] ma
ilop - moving Message (id=624521) to Folder Trash (id=3)
2018-09-07 19:52:46,252 INFO  [qtp66233253-17123:https:https://mail.domain.tld/service/soap/MsgActionRequest] [name=ma-boite-mail@domain.tld;mid=23;ip=10.10.10.05;port=37620;ua=ZimbraWebClient - GC68 (Win)/8.8.9_GA_3019;soapId=222a78;] so
ap - MsgActionRequest elapsed=12031

Mick
Zimbra ZNE 8.8.9 sur Ubuntu 16.04

#4 vdagost

vdagost

    Zimbra Jedi

  • Membres
  • PipPipPipPip
  • 522 messages
  • LocalisationLyon

Posté 13 septembre 2018 - 14:04

Les elapsed sont effectivement en ms.

Une requête SOAP du webmail qui prendre 12 secondes pour déplacer un message dans /Trash il y a clairement un soucis.

Si ce n'est pas un problème de performance alors il y a un problème de configuration du logiciel.
Tu as éclaté ton architecture en plusieurs rôles donc il y a peut-être un soucis de communication entre ces rôles.

As-tu bien suivi les prérequis indiqués ici : https://wiki.zimbra....rge_Deployments
?
Zimbra 8.7.3 OSS + Zextras
11000 utilisateurs (10 stores)
RHEL 6

#5 wolfy

wolfy

    Zimbra Jedi

  • Modérateurs
  • 540 messages
  • LocalisationRouen, France

Posté 14 septembre 2018 - 08:37

Cela depend aussi des disques en dessous.
C'est quel type de baie ? Quel Raid ?
___
Senior Solution Advisor EMEA chez Vade Secure

#6 Mickelebof

Mickelebof

    Membre avancé

  • Membres
  • 39 messages

Posté 14 septembre 2018 - 08:48

Bonjour,

Oui nous avons fait les optimisations décrites dans le wiki.
Je veux bien que ça soit un problème de configuration, mais sur les 5 mbox, un seul pose vraiment problème, deux autres un peu moins, et il y en a 2 qui n'ont quasi aucun problème :(

Pour les disques, nous utilisons des baies SAN avec des disques SAS 10k en raid10.
Mais comme je le disais plus haut, d'après les graph, je n'ai pas d'IO wait ou de problème de performance disques.
Il y a vraiment peu de boites pour le moment sur ces serveurs, j'ai même assez peu d'IO ;)

Ce qui m'étonne, c'est que ces pics sont très soudains et que je ne vois pas de timeout ou autre truc bloquant dans les logs, à part juste un temps de réponse plus long.
Rien ne me dit pourquoi c'est long :(
Zimbra ZNE 8.8.9 sur Ubuntu 16.04




0 utilisateur(s) li(sen)t ce sujet

0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)