LENTEUR PMB depuis réinstallation sur nouveau poste informatique
dans Administration
Bonjour,
Suite à un changement de poste informatique j'ai du réinstaller pmb sur un nouvel ordinateur en windows10.
La version installé est pmb 5.28 avec easyphp dev server 14.1.
PMB fonctionne mais je constate depuis l'installation beaucoup de lenteur. Chaque page met au moins 6 -7 secondes pour s'afficher.
Au départ je pensais que cela venait de la memoire vive, j'ai donc boosté l'ordinateur en passant de 4 à 16 GO mais aucun résultat. Cela ne vient pas non plus de l'antivirus .
J'ai réindexé les tables et fait du nettoyage sans plus de résultat.
Mon PMB s'ouvre bien avec 127.0.0.1 et non localhost.
lorque je vais dans maintenance mysql sur pmb j'ai le message d'erreur suivant: Table 'bibli.print_cart_tpl' doesn't exist
show index from print_cart_tpl
show index from print_cart_tpl
et sous php myadmin :
Impact de performance possible
Problème | Recommandation |
---|---|
Le système est en marche depuis moins d'un jour, les conseils de performance peuvent être inexacts. | Pour obtenir de meilleurs résultats, il est recommandé de laisser le serveur en marche plus d'un jour avant d'utiliser l'analyseur |
La cache des requêtes est désactivée. | La cache des requêtes améliore la performance lorsque correctement configurée. Activez-la en réglant query_cache_size à une valeur de plus de 9 Mio et query_cache_type à 'ON'. Note: Si vous utilisez memcached, ignorez cet avis. |
Un grand nombre de lignes sont en train d'être triées. | Bien qu'un grand nombre de tris ne soit pas mauvais en soi, vérifiez que les requêtes qui demandent un tri utilisent des colonnes indexées dans la clause ORDER BY, ce qui va grandement accélérer les tris |
Il y a trop de jointures sans index. | Ceci signifie que les jointures requièrent des lectures de tables au complet. L'ajout d'index sur les colonnes utilisées dans les critères de jointure va accélérer les jointures |
Le taux de lecture de la première entrée d'index est élevé. | Ceci indique habituellement des balayages complets des index. Cette opération est plus rapide qu'un balayage complet de table mais requiert beaucoup d'UCT pour des tables volumineuses. Si ces tables ont eu un grand nombre de UPDATE et DELETE, faire un 'OPTIMIZE TABLE' peut améliorer les choses. Sinon, il s'agit de récrire les requêtes. |
Le taux de lecture de données à partir d'une position fixe est élevé. | Ceci indique que plusieurs requêtes doivent effectuer un tri et/ou un balayage complet de table, incluant des jointures qui n'utilisent pas d'index. Ajouter des index si possible. |
Le taux de lecture de la prochaine ligne dans la table est élevé. | Ceci indique que plusieurs requêtes doivent effectuer un balayage complet de table. Ajouter des index si possible. |
Plusieurs tables temporaires sont écrites sur disque au lieu d'être conservées en mémoire. | Augmenter max_heap_table_size et tmp_table_size pourrait aider. Cependant il y a toujours quelques tables temporaires qui sont écrites sur disque, peu importe la valeur de ces variables. Pour éliminer ces tables temporaires, il faut modifier les requêtes pour éviter ces conditions (Présence d'une colonne BLOB ou TEXT ou d'une colonne de taille supérieure à 512 octets) tel que décrit dans cet arrticle par the Pythian Group |
Le % de la mémoire tampon utilisée pour les clés MyISAM est bas. | Diminuez la taille de key_buffer_size, examinez vos table pour voir si les index ont été enlevés, ou examinez les requêtes pour voir quels index sont utilisés. |
Le taux d'ouverture de tables est élevé. | Ouvrir des tables requiert des accès au disque, ce qui est coûteux. Augmenter table_open_cache pourrait remédier à la situation. |
Le taux d'ouverture de fichiers est élevé. | Veuillez augmenter open_files_limit, et vérifier le journal des erreurs après avoir redémarré. |
Mais je ne vois vraiment pas quelles actions réalisées pour modifier ces erreurs
je me tourne donc vers vous ...
cordialement
Connectez-vous ou Inscrivez-vous pour répondre.