résoudre les nombreux crash de la table j25_session

**jisse03** · 15/09/2013, 06h24

Re : résoudre les nombreux crash de la table j25_session

Bonjour,

Avec Kide, la table sessions est effectivement énormément sollicitée. Et la table crashe en général soit par saturation, soit par saturation du nombre de requêtes simultanées.

Et le fait d'avoir réduit la surée de session à 5 minutes n'améliore pas les choses, passer la durée de session à 15 minutes au minimum, 30 minutes pour optimal.

Et choisir également un database storage plus robuste (avec phpMyAdmin, un

Code:

[COLOR=#000000][FONT=Arial]ALTER TABLE `jos_session` ENGINE = InnoDB[/FONT][/COLOR]

réduira fortement les possibilités de crash si la version du SQL privé supporte InnoDB.

Éviter par contre d'utiliser le storage engine Memory, ce dernier, bien que très rapide, nécessite un serveur MySQL particulièrement musclé pour être efficace et éviter les plantages par manque de mémoire.

Le cache n'a aucun effet pour un composant interactif du type chat, puisque justement, ce qui caractérise Kide est son interactivité.

Le passage en InnoDB devrait résoudre le problème définitivement.

Mais si le serveur MySQL est insuffisant et si l'hébergement le permet, passer le handler de sessions à XCache ou Memcached. Ou au pire, le plus lent, fichiers.

**julien** · 15/09/2013, 10h14

Re : résoudre les nombreux crash de la table j25_session

Merci Jisse

j'ai passé la session à 30 minutes et la table en InnoDB et on fera un essai cette après midi

je reviendrai pour donner des infos

**julien** · 15/09/2013, 19h58

Re : résoudre les nombreux crash de la table j25_session

Cette après midi c'était nettement mieux, mais cela à terminer par un plantage quand même où il faut reboot le serveur SQL.

mettre la seesion a plus de 30 minutes m^me si c est peut conseiller peut augmenter la stabilité ?

**jisse03** · 16/09/2013, 07h09

Re : résoudre les nombreux crash de la table j25_session

En augmentant la durée de session, tu ne fais que déplacer un problème.
La seule vraie solution serait d'analyser tes logs MySQL pour déterminer la raison du problème.
Cette analyse devrait montrer les slow queries, les burst queries, les memory mean et peak utilisées.

La plupart des services de type SQL privé ont une configuration SQL de type minimal, donc avec du memory limit assez faible, idem pour les memory temporary tables, etc.

Pour du chat à forte charge, une configuration medium ou large est recommandée, mais je doute fort que tu aies accès au fichier de configuration my.cnf sur ce type d'hébergement.

**julien** · 16/09/2013, 07h29

Re : résoudre les nombreux crash de la table j25_session

oui et le fichier log également ne m apprend pas grand chose a part le nom de la table qui crash un serveur dédié avec un sql musclé résoudrais le problème ?

**jisse03** · 16/09/2013, 07h33

Re : résoudre les nombreux crash de la table j25_session

Envoyé par julien Voir le message

oui et le fichier log également ne m apprend pas grand chose a part le nom de la table qui crash un serveur dédié avec un sql musclé résoudrais le problème ?

Sur du dédié, avec un MySQL parfaitement optimisé, en fonction de la vitesse des disques et de la RAM du serveur, on peut tenir sans aucun crash des sessions chat (soit genre Kide, soit plus lourd avec 123FlashChat ou VideoWhisper) avec plus de 5000 connectés.

**julien** · 16/09/2013, 07h46

Re : résoudre les nombreux crash de la table j25_session

Merci de tes réponse je vais essayer de voir si j ai pas un fichier log plus complet caché quelque part

EDIT:

Je viens de voir que j avais un accès ftp spécifique pour le sql privé de OVH

je suis donc en train de récupérer un gros fichier log ( 400Mo) qui nous permettra d'y vour plus clair et j'ai un raccourcis vers le fichier que tu cites plus haut " MY.cnf" qui contient cela j'imagine que c est seulement pour consulter mais que je ne peut pas le modifier

[mysqld]

tmp_table_size=5M
query_cache_size=10M
thread_cache_size=5
max_connections=200
open_files_limit=900

skip-locking
key_buffer_size = 10M
max_allowed_packet = 1M
table_cache = 300
sort_buffer_size = 1M
join_buffer_size = 1M
read_buffer_size = 512K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 128K

max_binlog_cache_size = 1M
max_join_size = 12M
max_seeks_for_key = 2M
max_write_lock_count = 512K
myisam_max_sort_file_size = 1M

########################
##Configuration Innodb##
##Uncomment the next line to disable Innodb

#skip-innodb

innodb_buffer_pool_size = 16M
innodb_additional_mem_pool_size = 2M

innodb_log_file_size = 10M
innodb_log_buffer_size = 4M

innodb_flush_log_at_trx_commit=1

skip-name-resolve

**julien** · 16/09/2013, 09h21

Re : résoudre les nombreux crash de la table j25_session

rapport du manager OVH SQL prvé sur l'optimisation de la configuration

Le serveur doit être démarré depuis au moins 48h afin de pouvoir appliquer les recommandations.

Recommendations:

MySQL est démarré depuis moins de 24 heures, les mesures peuvent ne pas être représentatives
Démarrez OPTIMIZE TABLE pour défragmenter les tables pour obtenir de meilleures performances
Vous devriez réduire votre consommation mémoire (réduisez votre sort_buffer et votre join_buffer si vous rencontrez des problèmes)
Activez les logs slow query pour mettre en évidence des éventuelles mauvaises requêtes
Réduisez ou éliminez les connexions persistantes
Optimisez vos jointures de requêtes pour toujours utiliser des index
Augmentez table_cache petit à petit pour empêcher les limites de file descriptor

my.cnf
max_connections = 240
wait_timeout = 60
interactive_timeout = 60
join_buffer_size = 2M
table_open_cache = 600
Masquer les détails

Statistiques Générales
Validation de la version de MySql
Votre version MySQL est à jour 5.1.31

Vérification des statistiques générales
En Ligne depuis : 7h 25m 26s (743K req [27.833 req/s], 81K conn, TX: 1BK, RX: 147MK)
Lectures / Ecritures: 68% / 32%
Statistiques du moteur de tables

Vérification du moteur de tables
InnoDB activé
MyISAM activé
Tout est bon

Vérification de la fragmentation des tables
Total des tables fragmentés: 30

Sécurité
Vérification de la sécurité des bases de donnés
Toutes les base de données ont un mot de passe assigné

Mesure de Performances
Vérification de l'utilisation mémoire
Total des Buffers mémoire: 47.0M fixe + 2.9M par connexion (200 connexions simultanées maximum)
Consommation maximum possible de mémoire: 622.0M (121% de la RAM de votre SqlPrivé)
Consommation Maximum constatée dans le passé : 550.1M (107% de la RAM de votre SqlPrivé)
Vous avez déja utilisé 107% de la capacity de la ram de votre Sqlprivé !

check slow queries
Nombres de requêtes lentes: 0% (1K/743K)
Vérification des connexions
Nombre maximum d'utilisateurs simultanés: 87% (175/200)
Vérification du buffer de clé (Gestion des index)
Taille du Key Buffer / total MyISAM indexes: 10.0M/10.1M
Taux de Réussite du Key Buffer: 99.8% (231K cached / 577 reads)
Tout est bon

Vérification des caches de requêtes
Efficacité du cache de requêtes: 73.9% (341K mis en cache / 462K selects)
Nombre de cache prunes par jour : 80386
Tout est bon

Vérification des tris des colonnes
Tris necessitant une table temporaire: 0% (0. tris temp / 11K tris)

Vérification des jointures
Jointures effectuée sans utiliser d'index: 2906

Vérification des tables temporaires
Tables temporaires crées sur le disque: 7% (571 sur disque / 7K au total)

Vérification de la mise en cache des threads
Taux de réussite des Thread cache: 95% (3K crées / 81K connections)

Vérification de la mise en cache des tables
Taux de succès de mise en cache de tables: 5% (300 open / 5K opened)

Vérification des pointeurs de fichier (Open Files)
Limite Open file déjà atteinte: 54% (549/1K)

Vérification du verouillage des tables
Verrouillage de table effectué immédiatement : 99%
(152K verrouillages immédiats / 153K verrouillages)

Vérification des performances
Tout est bon

**julien** · 16/09/2013, 11h25

Re : résoudre les nombreux crash de la table j25_session

Finalement j'ai accès à la configuration du My.cnf et j'éssai de suivre les recommandation de l'utilitaire d'optimisation d'ovh

qui me dit d'augmenter acahque fois join_buffer_size et de temps en temps query_cache_limit ..

**jisse03** · 16/09/2013, 13h09

Re : résoudre les nombreux crash de la table j25_session

La clé est là

Consommation maximum possible de mémoire: 622.0M (121% de la RAM de votre SqlPrivé)
Consommation Maximum constatée dans le passé : 550.1M (107% de la RAM de votre SqlPrivé)

C'est un dépassement de la RAM du serveur qui provoque les plantages.

Pour avoir une telle utilisation RAM, il y a nécessairement des requêtes non optimisées (des jointures entre tables sur des champs clés non indexés en particulier) qui imposent l'utilisation d'un temp buffer.

**julien** · 16/09/2013, 14h49

Re : résoudre les nombreux crash de la table j25_session

Oui je suis là dessus depuis cet aprem mais j avoue que je suis un peu largué

-Comment j'optimise les requêtes ou jointures faut que j'aille modifier des fichier dans joomla ?

-C'est des réglages plus pointu de My.cnf ?

**jisse03** · 16/09/2013, 15h09

Re : résoudre les nombreux crash de la table j25_session

Regardes déjà dans les logs les slow queries.

En général, on n'a pas de code à toucher dans Joomla!, juste des index à rajouter sur les tables cause des slow queries.

**julien** · 16/09/2013, 15h28

Re : résoudre les nombreux crash de la table j25_session

Ok j 'ai rajouter cela ce matin pour avoir ces fameux log :

slow_query_log=1
slow_query_log_file=/home/mysql/sqlprive.log

Dans ce log pour le moment il n y a rien à part cela:

/opt/mysql/mysql/bin/mysqld, Version: 5.1.31-log (MySQL Community Server (GPL)). started with:
Tcp port: 3306 Unix socket: /bdd/mysql.sock
Time Id Command Argument

Le chat n'est pas activé actuellement donc comment savoir sur quelles tables ajouter des index ? et surtout lol c est quoi rajouter un index à la table?

**jisse03** · 16/09/2013, 15h47

Re : résoudre les nombreux crash de la table j25_session

Commences par activer le chat, et là tu verras peut-être pas mal de choses y trainer.

Après avoir modifié le my.cnf, tu as bien redémarré le serveur MySQL ?

résoudre les nombreux crash de la table j25_session

[Problème] résoudre les nombreux crash de la table j25_session

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Annonce

Partenaire de l'association