Re: [sympa-fr] Lenteur index sympa

[Thibaut Jacob <adresse@cachée>]

Bonjour,

Cela me rassure de voir que pour vous également, l'index des listes est d'au moins 20 secondes, ce qui est le cas sur mon serveur actuel. La configuration me semble similaire entre nos serveurs MYSQL.
Cependant, cela reste énorme comparé à une version 6.1.X, qui pour l'action "liste des listes" était presque instantané.

Je suppose que les deux actions diffèrent totalement entre les versions.


Pour le module FCGID, j'ai installé ( pour apache 2.2.15) la version 2.3.9 en suivant les recommandations de sympa, ce qui donne en pratique :

vi /etc/http/conf.d/apache_sympa.conf

<IfModule mod_fcgid.c>
    IPCCommTimeout 120
    MaxProcessCount 8
  </IfModule>

<Location /sympa>
  SetHandler fcgid-script
</Location>

<Directory /appli/sympa/sympaV6.2.12/sympa/static_content>
  Order deny,allow
  Allow from all
</Directory>

#SYMPA
ScriptAlias /sympa /appli/sympa/sympaV6.2.12/sympa/bin/wwsympa-wrapper.fcgi
Alias /static-sympa /appli/sympa/sympaV6.2.12/sympa/static_content

Cordialement,

Le 16/02/2016 16:27, Patrice Garnier (via sympa-fr Mailing List) a écrit :

RE,

Moi effectivement je suis dans un cadre un peu différent car mon serveur mysql est mutualisé avec une dizaine d’autres petites bases, cependant seule une autre appli que sympa utilise notoirement une base sur ce seveur .

AMHA les 2 lignes en rouges sont liées au fait que le serveur a été redémarré récement  pour appliquer les modifs et donc a flushé les caches , ce qui diminue les hit rate

il faudrai attendre demain ou un peu plus pour voir si ça revient dans le vert.

Voici ma conf compactée (sans grantie qu’elle soit optimisée)

# grep -v "^#\|^$" /etc/mysql/my.cnf 

[client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /usr/local/mysqldata tmpdir = /usr/local/mysqldata/mysqltmp skip-external-locking key_buffer = 64M max_allowed_packet = 16M thread_stack = 192K thread_cache_size       = 8 key_buffer_size = 128M sort_buffer_size = 4M read_rnd_buffer_size = 4M myisam-recover         = BACKUP max_connections        = 500 table_cache            = 1024  tmp_table_size = 128M  max_heap_table_size = 128M query_cache_limit = 4M query_cache_size        = 128M log_error                = /var/log/mysql/error.log log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 2 expire_logs_days = 10 max_binlog_size         = 100M open_files_limit = 4326  innodb_buffer_pool_size=512M [mysqldump] quick quote-names max_allowed_packet = 32M [mysql] [isamchk] key_buffer = 16M

Pour ce qui est de la taille du serveur sympa : 

mysql> SELECT count( * ) FROM `list_table`;

+------------+

| count( * ) |

+------------+

|       1322 |

+------------+

1 row in set (0.00 sec)

mysql> SELECT count( * ) FROM `subscriber_table`;

+------------+

| count( * ) |

+------------+

|     367482 |

+------------+

1 row in set (0.20 sec)

et chez moi la page Index des listes se chage en un peu plus de 20 s ce qui est énorme … Ces temps c’est avec le vieux module fast-cgi (qui ne me génère pas d’erreur 500 plus que ça)  cependant je suis intéressé pour un échange sur la conf apache avec fcgi car ne n’arrive pas à le faire marcher chez moi…
amicalement,

—

Patrice Garnier  -  (+33) 247 367 312  Messagerie, Listes, Annuaire, ENT
Direction des Technologies de l' Information et de la Communication,  Université de Tours
Bat D, 60 rue du Plat d'étain BP 12050
37020 Tours cedex 1

Le 16 févr. 2016 à 14:52, Thibaut Jacob (via sympa-fr Mailing List) <adresse@cachée> a écrit :

Bonjour,
Merci pour vos réponses. J'ai appliqué les plusieurs modifications pré-cité mais j'arrive à un résultat similaire.

1)
Cependant, j'ai l'impression qu'il y a des erreurs dans ma configuration depuis la modification, voici le résultat après un reboot de mysql : en rouge
( le serveur MYSQL dispose de plusieurs base Sympa, 1 seule étant active et uniquement en MyISAM )

-------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.69-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics ------------------------------------------- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 8G (Tables: 107) [--] Data in InnoDB tables: 24M (Tables: 9) [!!] Total fragmented tables: 19

-------- Security Recommendations  ------------------------------------------- [OK] All database users have passwords assigned
-------- Performance Metrics ------------------------------------------------- [--] Up for: 30m 20s (18K q [10.093 qps], 140 conn, TX: 8M, RX: 6M)
[--] Reads / Writes: 59% / 41%
[--] Total buffers: 442.0M global + 16.4M per thread (151 max threads)
[OK] Maximum possible memory usage: 2.8G (37% of installed RAM)
[OK] Slow queries: 0% (0/18K)
[OK] Highest usage of available connections: 15% (23/151)
[!!] Key buffer size / total MyISAM indexes: 384.0M/5.9G
[!!] Key buffer hit rate: 81.3% (143K cached / 26K reads)
[OK] Query cache efficiency: 77.5% (11K cached / 15K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 16 sorts)
[!!] Temporary tables created on disk: 26% (110 on disk / 420 total)
[OK] Thread cache hit rate: 83% (23 created / 140 connections)
[OK] Table cache hit rate: 84% (140 open / 166 opened) [OK] Open file limit used: 6% (261/4K)
[OK] Table locks acquired immediately: 100% (5K immediate / 5K locks)
[!!] InnoDB data size / buffer pool: 24.3M/8.0M
-------- Recommendations ----------------------------------------------------- General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
    key_buffer_size (> 5.9G)
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)
    innodb_buffer_pool_size (>= 24M)

c'est assez étrange :

mysql> SHOW STATUS LIKE "key%";
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| Key_blocks_not_flushed | 0      |
| Key_blocks_unused      | 315536 |
| Key_blocks_used        | 10822  |
| Key_read_requests      | 143134 |
| Key_reads              | 26729  |
| Key_write_requests     | 13632  |
| Key_writes             | 3358   |
+------------------------+--------+
7 rows in set (0.00 sec)


extrait fichier my.cnf :

# The MySQL server [mysqld]
datadir         = /appli/mysql_sympa
port            = 3306
socket          = /appli/mysql_sympa/mysql.sock skip-locking
log_slow_queries = /var/log/mysql/mysql-slow.log key_buffer_size = 384M
max_allowed_packet = 32M
table_open_cache = 512
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
open_files_limit = 4326
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency thread_concurrency = 4


2)
Toujours un problème de latence pour la première recherche ou "Index des listes", de plus, il faut bien 2-3 minutes avant que le fcgi répondent correctement.

3)
J'utilise depuis la version 6.2 le module fcgid, et non fast-cgi qui résulte par des erreurs 500 lors d'une action sur le moteur de liste.
Le module fcgid ne généré pas d'erreur/latence avec un nombres de listes bas ( 10-100 listes ), seulement, passé la barre des 500, la latence ce fait ressentir.
Cordialement,

Le 16/02/2016 12:28, Patrice Garnier (via sympa-fr Mailing List) a écrit :

Bonjour,

J’ai moi aussi des soucis de perf depuis mon passage en 6.2.6 (depuis une 5.2.3) , J’ai suivi les conseils de Dominique avec mysqltuner et les conseils de phpmyadmin plus un peu de recherches mysql et ça a grandement amélioré les perfs.

essentiellement j’ai augmenté les compteurs suivants

Doublement des ces paramètres : 

#mysql> SHOW VARIABLES LIKE 'key_buffer_size';

#+-----------------+----------+

#| Variable_name   | Value    |

#+-----------------+----------+

#| key_buffer_size | 67108864 | #+-----------------+----------+ key_buffer_size         = 128M #mysql> SHOW VARIABLES LIKE 'sort_buffer_size'; #+------------------+---------+ #| Variable_name    | Value   | #+------------------+---------+ #| sort_buffer_size | 2097144 | #+------------------+---------+ sort_buffer_size        = 4M read_rnd_buffer_size    = 4M #mysql> SHOW VARIABLES LIKE 'open_files_limit'; #+------------------+-------+ #| Variable_name    | Value | #+------------------+-------+ #| open_files_limit | 2558  | #+------------------+-------+

open_files_limit        = 4326

aussi ma base sympa est en innoDB

# * InnoDB

# # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. # Read the manual for more InnoDB related options. There are many! #

innodb_buffer_pool_size=512M

J’ai aussi activé les slow queries :

log_slow_queries        = /var/log/mysql/mysql-slow.log

J’ai constaté que les requêtes lentes concernent l’enregistrement des sessions sympa

# Time: 160215 16:01:46

# User@Host: sympa_db[sympa_db] @ yuanzi.univ-tours.local [10.193.4.153] # Query_time: 2.093816  Lock_time: 0.000133 Rows_sent: 0  Rows_examined: 0 SET timestamp=1455548506; UPDATE session_table SET date_session = '1455548443', remote_addr_session = '92.160.107.45', robot_session = 'listes.univ-tours.fr', email_session = 'nobody', start_date_session = '1455548440', hit_session = '2', data_session = ';is_family_owner=\"\";data="\"\";checked_cas=\"0\"'" WHERE id_session = '49494942235977' AND prev_id_session IS NOT NULL OR prev_id_session = '49494942235977';

action 1 : Ajout d’index sur le champ prev_id_session (id_session est la clé primaire) 

action 2 : la table contenait plus de 700 000 enregistrements de sessions qui concernaient toutes les sessions depuis ma migration ( septembre 2015)

j’ai mis en cron une tache d’effacement des vieilles sessions inutiles : 

mysql -h mysql.univ-tours.local -u sympa —password=secret -B -e "USE sympa_db; DELETE FROM session_table WHERE date_session < `date +%s  --date="2 days ago"`;"

je n’ai plus que 5000 enregistrements dans la table …

action 3 j’ai cherché si il y avait une option dans le fichier de conf de sympa pour régler la conservation des données de sessions je n’ai pas trouvé mais j’ai trouvé un paramètre qui était commenté

je l’ai décommenté et mis l’expiration à 1 mois

## logs_expiration_period

## Nombre de mois avant expiration de la journalisation

logs_expiration_period  1

un petit redémarrage de tout ça et j’ai amélioré mes perfs dans un facteur 2 - 3 

C’est pas mal , l’interface redevient utilisable mais c’est toujours pas nerveux, je vais continuer à chercher

QUESTION A LA LISTE : est il normal que sympa se comporte de la sorte pour la table des sessions ? / Ai-je oublié un paramètre dans la conf ??

ps : j’avais déjà effectué des optimisatisons auparavant (activation du cache db et des conf binaires sur les conseils de David Verdin) 

extraits de sympa.conf

## cache_list_config

## Utilisation de la version binaire de la liste de configuration de la

## structure sur le disque (non | fichier_binaire) ## Mettre ce paramètre à "binary_file" si vous gérez une grande quantité de ## listes (1 000+); ça devrait accélérer le démarrage de l'interface web #cache_list_config      none cache_list_config       binary_file # http://www.sympa.org/manual/conf-parameters/part3#cache_list_config  #  list_table database table should be filled at the first time by running sympa.pl --sync_list_db db_list_cache   on ## log_level ## Verbosité des logs ## 0: normal, 2,3,4: pour le déboguage #log_level      0 ## pour la prod pas de debug log_level       0

Puis évidemment wws tourne sous fast-cgi

## use_fast_cgi ## Est-ce-que le module fast_cgi d'Apache (ou Roxen) est installé ( 0 | 1 ) ## Ce module fournit une interface beaucoup plus rapide use_fast_cgi    1

Vérif de l’installation module fastcgi perl # /usr/local/sympa/bin/sympa_wizard.pl --check ##############################################################################

# The programme va vous aider à installer tous les modules Perl (CPAN) requis par Sympa. ## Sympa nécessite l'installation de 50 à 65 modules pour fonctionner correctement.  # L'ensemble du processus d'installation devrait prendre autour de 15 minutes. # Vous devrez tout d'abord l'outil de ligne de commande CPAN lui-même # et sélectionner votre serveur CPAN favori. # Notez que vous pouvez préférer installer ces modules à l'aide de votre # gestionnaire de paquetage (yum, apt-get) préféré. # Vous pouvez interrompre ce programme à tout moment. Il pourra être relancé # sans dommage par la suite. ############################################################################## Appuyez sur une touche pour continuer...


Vérification de la version de l'interpréteur Perl :
Votre version de Perl est suffisante (5.014002 >= 5.008)
Vérification des modules OBLIGATOIRES :
module Perl             depuis CPAN             STATUS -----------             ---------               ------ Archive::Zip            Archive-Zip             OK (1.30   >= 1.05) CGI                     CGI                     OK (3.52   >= 3.51) Class::Singleton        Class-Singleton         OK (1.5    >= 1.03) DBD::mysql              DBD-mysql               OK (4.020  >= 4.008) DBI                     DBI                     OK (1.616  >= 1.48) DateTime::Format::Mail  DateTime-Format-Mail    OK (0.402  >= 0.28) DateTime::TimeZone      DateTime-TimeZone       OK (1.93   >= 1.08) Digest::MD5             Digest-MD5              OK (2.51   >= 2.00) Email::Simple           Email-Simple            OK (2.208  >= 2.100) Encode                  Encode                  OK (2.42_01 >= 1.0) File::Copy::Recursive   File-Copy-Recursive     OK (0.38   >= 0.36) File::NFSLock           File-NFSLock            OK (1.21   >= 1.0) File::Path              File-Path               OK (2.08_01 >= 2.08) HTML::FormatText        HTML-Format             OK (2.10   >= 1.0) HTML::StripScripts::ParserHTML-StripScripts-ParserOK (1.03   >= 1.03) HTML::TreeBuilder       HTML-Tree               OK (4.2    >= 1.0) IO::File                IO                      OK (1.15   >= 1.10) IO::Scalar              IO-stringy              OK (2.110  >= 1.0) LWP::UserAgent          libwww-perl             OK (6.03   >= 1.0) List::Util::XS          Scalar-List-Utils       OK (1.42   >= 1.20) Locale::Messages        libintl-perl            OK (1.24   >= 1.22) MHonArc::UTF8           MHonArc                 OK (2.6.19 >= 2.6.18) MIME::Base64            MIME-Base64             OK (3.13   >= 3.03) MIME::Charset           MIME-Charset            OK (1.012  >= 1.011.3) MIME::EncWords          MIME-EncWords           OK (1.014.3 >= 1.014) MIME::Lite::HTML        MIME-Lite-HTML          OK (1.23   >= 1.23) MIME::Tools             MIME-tools              OK (5.502  >= 5.423) Mail::Address           MailTools               OK (2.08   >= 1.70) Net::CIDR               Net-CIDR                OK (0.18   >= 0.16) Net::DNS                Net-DNS                 OK (0.66   >= 0.65) Proc::ProcessTable      Proc-ProcessTable       OK (0.53   >= 0.44) Sys::Syslog             Sys-Syslog              OK (0.27   >= 0.03) Template                Template-Toolkit        OK (2.22   >= 2.21) Term::ProgressBar       Term-ProgressBar        OK (2.10   >= 2.09) Text::LineFold          Unicode-LineBreak       OK (2012.04 >= 2011.05) Time::HiRes             Time-HiRes              OK (1.972101 >= 1.29) URI::Escape             URI-Escape              OK (3.31   >= 1.35) Unicode::CaseFold       Unicode-CaseFold        OK (1.00   >= 0.02) XML::LibXML             XML-LibXML              OK (1.89   >= 1.0)
Vérification des modules OPTIONNELS :
module Perl             depuis CPAN             STATUS -----------             ---------               ------ AuthCAS                 AuthCAS                 OK (1.6    >= 1.4) CGI::Fast               CGI-Fast                OK (1.08   >= 1.08) Crypt::CipherSaber      Crypt-CipherSaber       OK (0.61   >= 0.50)
ps  auxf :  sympa    17242  0.7  3.0 457176 251988 ?       S    Jan29  33:56 /usr/bin/perl /usr/local/sympa/bin/sympa_msg.pl sympa    17245  0.0  0.6 251504 54448 ?        S    Jan29   0:13 /usr/bin/perl /usr/local/sympa/bin/sympa_automatic.pl sympa    17248  1.2  2.6 418340 217040 ?       S    Jan29  55:35 /usr/bin/perl /usr/local/sympa/bin/task_manager.pl sympa    17251  0.2  1.2 304828 105052 ?       S    Jan29   9:09 /usr/bin/perl /usr/local/sympa/bin/bulk.pl sympa    16202  0.0  1.2 304828 104076 ?       S    13:16   0:05  \_ /usr/bin/perl /usr/local/sympa/bin/bulk.pl sympa    16209  0.0  1.2 304828 104068 ?       S    13:16   0:05  \_ /usr/bin/perl /usr/local/sympa/bin/bulk.pl sympa    20006  0.1  1.2 304828 104000 ?       S    14:52   0:01  \_ /usr/bin/perl /usr/local/sympa/bin/bulk.pl sympa    17254  0.0  0.7 258876 59508 ?        S    Jan29   0:16 /usr/bin/perl /usr/local/sympa/bin/bounced.pl sympa    17257  0.0  2.0 370056 166892 ?       S    Jan29   0:34 /usr/bin/perl /usr/local/sympa/bin/archived.pl root     21729  0.0  0.0  89440  7072 ?        Ss   Jan29   0:07 /usr/sbin/apache2 -k start www-data  6860  0.0  0.0  87660  2992 ?        S    Jan31   0:00  \_ /usr/sbin/apache2 -k start www-data  6861  0.0  0.0  87760  3140 ?        S    Jan31   0:01  \_ /usr/sbin/fcgi-pm -k start sympa     7050  0.5  1.7 343220 139976 ?       S    Jan31  10:08  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa     8387  0.4  1.3 314928 111620 ?       S    Jan31   9:12  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa     8465  0.5  1.7 350140 144660 ?       S    Jan31  10:09  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa     8567  0.5  1.7 349896 146576 ?       S    Jan31  11:00  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa    31486  1.0  1.7 349228 145892 ?       S    05:18   6:12  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa    31663  0.7  1.4 318004 114720 ?       S    05:26   4:30  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa    32019  1.2  1.7 350172 146688 ?       S    05:48   7:06  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa    32101  0.8  1.7 346080 140680 ?       S    05:50   5:00  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa    32105  1.0  1.8 350452 147244 ?       S    05:50   5:56  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi sympa    20848  2.3  1.1 295280 93264 ?        S    15:07   0:01  |   \_ /usr/bin/perl /usr/local/sympa/bin/wwsympa.fcgi www-data  6862  0.0  0.0  88936  2824 ?        S    Jan31   0:00  \_ /usr/sbin/apache2 -k start www-data  6863  0.1  0.1 2019828 13688 ?       Sl   Jan31   2:50  \_ /usr/sbin/apache2 -k start www-data  6864  0.1  0.1 2020008 13780 ?       Sl   Jan31   2:50  \_ /usr/sbin/apache2 -k start

Il y a encore peut être des optimisations à faire dans fastcgi (je regarde dès que possible avec qq les données que j’ai récupéré)

Si vous avez des pistes je suis aussi preneur

amicalement, 
— Patrice Garnier  -  (+33) 247 367 312  Messagerie, Listes, Annuaire, ENT Direction des Technologies de l' Information et de la Communication,  Université de Tours Bat D, 60 rue du Plat d'étain BP 12050 37020 Tours cedex 1

Le 16 févr. 2016 à 10:48, Thibaut Jacob (via sympa-fr Mailing List) <adresse@cachée> a écrit :

Bonjour,

Je viens de me rendre compte, votre version de sympa est en version 6.1.23

Hors, les problèmes de lenteur constaté sont en version 6.2.X ( testé en 6.2.1 et 6.2.12 ) L'interface sympa ayant changé énormément entre les 2 versions ( 6.1 to 6.2 ) , vous n'observez pas les mêmes type de ralentissement. En effet, en version 6.1.23, malgré un grand nombre de liste, je n'observai pas cette "latence " dans l'interface.

La latence visible est directement visible sur le sympa renater https://listes.renater.fr/sympa
David, observez vous également ce ralentissement depuis la version 6.2 ?

Cordialement,


Le 15/02/2016 11:15, LALOT Dominique a écrit :

Bonjour,
ii  libapache2-mod-fcgid                       1:2.3.9-1                  amd64                      FastCGI interface module for Apache 2
ubuntu 14.04 LTS

Fais tu tourner mysqltuner.pl pour voir si ta base mysql répond bien?
Voici ce qui sort de mon installation. A+

Dom

 >>  MySQLTuner 1.2.0 - Major Hayden <adresse@cachée>  >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/  >>  Run with '--help' for additional options and output filtering
[OK] Logged in using credentials from debian maintenance account.

-------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.47-0ubuntu0.14.04.1
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics ------------------------------------------- [--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1G (Tables: 13) [--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] InnoDB is enabled but isn't being used [!!] Total fragmented tables: 7

-------- Security Recommendations  ------------------------------------------- [!!] User '@listes-new' has no password set. [!!] User '@localhost' has no password set.
-------- Performance Metrics ------------------------------------------------- [--] Up for: 19d 4h 21m 10s (42M q [25.499 qps], 69K conn, TX: 95B, RX: 35B)
[--] Reads / Writes: 83% / 17%
[--] Total buffers: 948.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 1.3G (27% of installed RAM)
[OK] Slow queries: 0% (2/42M)
[OK] Highest usage of available connections: 24% (37/151)
[OK] Key buffer size / total MyISAM indexes: 96.0M/60.5M
[OK] Key buffer hit rate: 99.9% (283M cached / 265K reads)
[OK] Query cache efficiency: 69.8% (27M cached / 39M selects)
[!!] Query cache prunes per day: 21933 [OK] Sorts requiring temporary tables: 0% (483 temp sorts / 457K sorts)
[OK] Temporary tables created on disk: 24% (23K on disk / 96K total)
[OK] Thread cache hit rate: 99% (197 created / 69K connections)
[OK] Table cache hit rate: 23% (83 open / 359 opened)
[OK] Open file limit used: 4% (103/2K) [OK] Table locks acquired immediately: 99% (14M immediate / 14M locks)

-------- Recommendations ----------------------------------------------------- General recommendations:
    Add skip-innodb to MySQL configuration to disable InnoDB
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Increasing the query_cache size over 128M may reduce performance
Variables to adjust:
    query_cache_size (> 512M) [see warning above]



--
Dominique LALOT
Responsable Pôle Environnement Numérique ( Aix * Marseille Université
Coordonnées: http://annuaire.univ-amu.fr/showuser.php?uid=lalot Ma signature ne contient pas d'images et sauve la planète

________________________________________ De : adresse@cachée <adresse@cachée> de la part de Thibaut Jacob <adresse@cachée> Envoyé : lundi 15 février 2016 10:58 À : adresse@cachée Objet : Re: [sympa-fr] Lenteur index sympa
Bonjour,

J'ai effectué les modifications, mais je n'ai pas vu de différence, la
lenteur est toujours présente.

Je vais testé une base vierge dans laquelle je vais créer 1000 listes (
via les familles ) voir si ce n'est pas ma base de départ qui cause
problème.

Vous utilisez également fcgid version 2.3.9 ?
Le 12/02/2016 18:00, LALOT Dominique a écrit :

Bonjour
Avez vous mis ceci:
cache_list_config binary_file
db_list_cache on
Je suis sur une 6.1.23 et c'est très rapide et avec plusieurs milliers de listes A+

Dom

--
Dominique LALOT
Responsable Pôle Environnement Numérique ( Aix * Marseille Université
Coordonnées: http://annuaire.univ-amu.fr/showuser.php?uid=lalot Ma signature ne contient pas d'images et sauve la planète

________________________________________ De : adresse@cachée <adresse@cachée> de la part de "Thibaut" <adresse@cachée> Envoyé : vendredi 12 février 2016 09:52 À : adresse@cachée Objet : [sympa-fr] Lenteur index sympa
Bonjour,

( Info env : Red Hat 6.4, apache 2.2.15, fcgid 2.3.9
version testé  : 6.2.1 )
Nous observons une lenteur de l'interface sympa depuis la version 6.2 de
sympa.

Nous avons récemment modifié l'accès à l'interface privilégiant le module FCGID au module Fastcgi ( erreur 500 comme décrite dans la documentation )
mais nous observons une lenteur lors d'une recherche via : Index des Listes et Chercher une liste.

J'ai fais plusieurs tests avec 600 listes présentes sur le serveur, il faut à peut prêt 20 secondes pour obtenir un affichage des 600 listes.
Autre phénomène, il s'avère qu'après le lancement de sympa/apache les 3
premières minutes, l'attente est  encore plus longue !

Je remarque qu'ici également sur ce moteur de liste, l'index des listes semble peu rapide, cela malgré un nombre de listes moins important.

La fonction "Index des listes"  présente dans cette nouvelle version est elle différente à la fonction "Liste des listes" d'une Sympa version 6.1 ?
Avez vous le même ressenti sur vos moteurs de listes en version 6.2.X ?

Cordialement,
Thibaut Jacob

--
Thibaut JACOB
Pôle Hébergement National
Ingénieur d'étude
DSI - Rectorat d'Orléans-Tours
02 38 79 45 04

--
Thibaut JACOB
Pôle Hébergement National
Ingénieur d'étude
DSI - Rectorat d'Orléans-Tours
02 38 79 45 04

-- 
Thibaut JACOB
Pôle Hébergement National
Ingénieur d'étude
DSI - Rectorat d'Orléans-Tours
02 38 79 45 04

-- 
Thibaut JACOB
Pôle Hébergement National
Ingénieur d'étude
DSI - Rectorat d'Orléans-Tours
02 38 79 45 04

Attachment: png8xOaWOHm14.png
Description: PNG image