1 votes

RoundCube : trop de connexions en sommeil dans mysql

Nous disposons d'un service de messagerie avec ces détails :

    1-Centos 6.4
    2:Postfix 2.6.6
    3:roundcube 0.8 
    4:dovecot 2.0.9.7
    5:mysql-server 5.1.71

Tout va bien mais lors des pics d'utilisation, le nombre de connexions dormantes de roundcube passe de 1, 2 ou 3 à 270 en moins de 10 minutes et le nombre de fichiers ouverts par apache (mesuré par lsof) passe de 4000 à 20000 lors de ces pics d'utilisation.

voici la conf d'apache : (apache fonctionne en mode prefork)

PidFile run/httpd.pid
Timeout 60
KeepAlive On
MaxKeepAliveRequests 100
<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>
TraceEnable off
LimitRequestLine 1024
LimitRequestFields 100
LimitRequestFieldsize 1024
LimitRequestBody 10241024

et voici la configuration mysql :

secure_auth=1
local_infile=0
max_connections        = 600
max_allowed_packet    = 16M
key_buffer        =256M
wait_timeout=240
interactive_timeout=180
connect_timeout=10
innodb_buffer_pool_size=2G

Lorsque le nombre de connexions dormantes de roundcube augmente jusqu'à >100, la plupart des services (web, mail, mysql) tombent en panne....

Merci pour toute suggestion.

0voto

Sir Adelaide Points 1026

La réponse est :

J'ai modifié l'option max_client d'apache pour réduire la valeur à 256 --> 50 Pourquoi ?

pour un problème (encore) inconnu, tous les processus apache préforkés utilisent le CPU à environ 100% (100% d'utilisation du coeur qui exécute le processus apache préforké pendant quelques instants).

Le système s'arrête donc, parce que le système a 64 cœurs de CPU alors que les 256 processus d'Apache utilisent 100% du CPU, le système et les services s'arrêtent.

le problème existe toujours mais les services n'ont pas de problème Je pense que le problème est lié à des attaques du réseau (nos outils de surveillance signalent de nombreuses attaques par jour), qui entraînent parfois des problèmes tels que le blocage des ressources ou autre chose.

Merci pour toutes les suggestions.

0voto

Sir Adelaide Points 1026

Maintenant

Après environ 5 ans

Le problème a été détecté et résolu en quelques jours.

C'était tellement compliqué pour un administrateur système junior comme moi ;)

Il y a eu un problème dans le système de fichiers GFS2 cluster que mon coéquipier a préparé sur iSCSI LUN et ce problème a conduit à divers problèmes dans Dovecot et roundcube (et ensuite apache).

Pour votre information, lorsque j'ai prêté attention au paramètre %wa de la commande top, (il était d'environ 90%), j'ai pensé (peut-être) qu'il y avait un problème au niveau du système de fichiers.

Ensuite, j'ai décidé de transférer toutes les données vers le nouveau système de fichiers du cluster (ocfs2) parce que GFS était obsolète !

Tout d'abord, toutes les données ont été déplacées vers le nouveau système de fichiers du cluster (sur ocf2), puis l'ensemble du système a été repensé sur la base de pacemake haproxy sur debian wheezy !

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X