Aller au contenu

[Recherche] aide pour optimisation base Mysql


Torlax

Sujets conseillés

Bonjour à tous ! happy.gif



Etant totalement désespéré, je m'adresse à vous en dernier recours smartass.gif



Je vous retrace l'historique de mon problème :



Je m'occupe actuellement d'un site avec un nombre de connexion plutot énorme (150 000 à 300 000 visiteurs par jours en moyenne). Le site en question est un bon gros Wordpress (9 plugins actif, plugins plutôt propre parmi les plus connu) avec une base sql pesant 380 Mo et environs 9000 articles, ainsi qu'un forum IPB don la base sql pèse 150 Mo... Auparavant, nous avions un gros HG XXL chez ovh pour gérer le tout. J'avais monté un ESX avec ma VM dessus qui comprenais Apache, php5, Mysql, bref... Après optimisation, on arrivais à grimper à environs 4000/4500 connexions simultanés (via Google Analytics) avec un Load Average assez élevé... J'ai donc fait le choix de partir sur deux serveur MG SSD plus petit (mono Xeon, 64 Go de ram sur les deux), le tout avec un Vrack (Baie Virtuelle), un bloc RIPE, et j'ai connecté mes deux serveur en "privé". Sur le premier (le frontal) J'y ai mis Apache + PHP et sur le seconds, mon Mysql. En gros j'ai réparti la charge sur deux serveur quoi... Après optimisation, j'obtiens à peu prêt la même tolérance à la charge qu'auparavant, mais avec des temps de réponses plutot rapide. Le souci, c'est que pendant les pic d'audience, ça se vautre méchamment...



Constatations actuelles :



- Mes logs apache ne me remonte aucunement la fameuse alerte comme quoi j'aurais atteins "Max_connection" (réglé sur 1024 actuellement).


- Mes logs Mysql ne me remonte aucunement "Too many connections"


- J'utilise bien un Opcode, ici APC (avec valeur 2Go de cache)


- Coté Wordpress, W3 Total Cache paramétré


- Cloudflare actif pour décharger apache de toute la partie "statique"



En fait, quand ça pète, ça donne réellement l'impression que Apache suit correctement, Mysql sature, il tombe... les requête s'empilent et font ensuite pétés apache + php.



J'en viens à ma demande... La partie ou je m'y connais le moins bien est Mysql (comme beaucoup...) Et je suspecte beaucoup d'avoir une base non optimisé (manque d'index, problème de jointures etc...) en plus de (peut être) quelques script foireux. Pour les scripts foireux, nous y travaillons : Nous allons faire développer notre propre thème, avec tout ce que nous avons besoin en plugin directement intégré pour décharger Wordpress.



Là ou je bute, c'est l'optimisation de ma base Mysql... Les index, etc... Je ne sais pas dutout par ou commencer. J'ai également essayé de passé toutes mes table en Innodb pour éviter les lock au niveau des tables, ça s'écroule encore plus vite qu'en Myisam, en ayant pourtant pris soin de ne pas faire de réglages foireux (Pool_Buffer_Size à 50/80% de ma ram, etc...). J'ai également essayé "Apache + Varnish", "Nginx + Varnish", "Apache + Nginx en reverse proxy", malgré tout ça, rien à faire ça fini toujours par explosé quasiment dans les mêmes circonstances.



Si une bonne âme se sent de me conseiller sur ce que je devrais faire, m'aiguiller ou carrément me proposer un audit, je suis preneur... Enfin, je vous met mes fichiers de config actuel ci-dessous :



Merci à tous !




My.ini :



[mysqld]
port = 3306
socket = /var/run/mysqld/mysqld.sock
bind-address = xxx.xxx.xxx.xxx

skip-external-locking
max_connections = 500
key_buffer_size = 10G
max_allowed_packet = 1M
table_open_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 128K
table_cache = 2048
query_cache_limit = 30M
query_cache_size = 128M #(J'attends les 48h de Tuning-primer ici pour augmenter cette valeur)
thread_cache_size = 20
max_heap_table_size = 128M #(J'attends les 48h de Tuning-primer ici pour augmenter cette valeur)


[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer_size = 8M
sort_buffer_size = 8M

[mysqlhotcopy]
interactive-timeout




Apache.conf :




Timeout 300
KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 2
HostnameLookups Off

<IfModule mpm_prefork_module>
StartServers 64
MinSpareServers 64
MaxSpareServers 128
ServerLimit 1500
MaxClients 1500
MaxRequestsPerChild 300
</IfModule>



Résultat TuningPrimer (ça ne fait pas 48h là, donc ne veut pas dire grand chose mais j'vous le met quand meme...) :




MySQL Version 5.5.30-1~dotdeb.0 x86_64

Uptime = 0 days 12 hrs 50 min 46 sec
Avg. qps = 124
Total Questions = 5735385
Threads Connected = 3

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10.000000 sec.
You have 0 out of 5735409 that take longer than 10.000000 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 20
Current threads_cached = 17
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 500
Current threads_connected = 4
Historic max_used_connections = 39
The number of used connections is 7% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

INNODB STATUS
Current InnoDB index space = 0 bytes
Current InnoDB data space = 0 bytes
Current InnoDB buffer pool free = 98 %
Current innodb_buffer_pool_size = 128 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 10.29 G
Configured Max Per-thread Buffers : 406 M
Configured Max Global Buffers : 10.26 G
Configured Max Memory Limit : 10.66 G
Physical Memory : 39.38 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 88 M
Current key_buffer_size = 10.00 G
Key cache miss rate is 1 : 660
Key buffer free ratio = 80 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 128 M
Current query_cache_used = 43 M
Current query_cache_limit = 30 M
Current Query cache Memory fill ratio = 34.20 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 64 K
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 2 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 65536 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 2048 tables
Current table_definition_cache = 400 tables
You have a total of 253 tables
You have 311 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 128 M
Current tmp_table_size = 16 M
Of 65393 temp tables, 38% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 256 K
Current table scan ratio = 388 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 21
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=ALWAYS'.

Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

Je te recommande de logguer les requêtes qui posent problème http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html


(***edit : > 1s par exemple, pas 10 comme par défaut)


Et à l'usage d'ajouter des index si besoin, voire tout simplement d'ajouter les clés étrangères qui sont absentes (de mémoire) sur l'ainstall de base de wordpress, phpmyadmin (si tu l'as) donne certaines infos -de mémoire, je l'utilise pas-.



Des fois, une seule requête peut poser problème, j'ai eu le cas avec un simple formulaire d'authentification (qui s'est réglé avec un index des 2 premières lettres sur le login).



En tout cas bonne chance, c'est chiant !


Lien vers le commentaire
Partager sur d’autres sites

Les index sont à poser lorsqu'il y a des jointures de table ou des recherches sur des champs particuliers. Ils sont plus efficaces sur les Integer que sur les champs texte bien sur.


Ca peut réellement soulager ton serveur.


Lien vers le commentaire
Partager sur d’autres sites

Merci pour vos réponses :-) N'y connaissant que le strict minimum a la structure que peut avoir une base SQL, la méthode pour trouver ou se trouve les jointures me semble vachement nébuleuse... En fait c'est pas de faire qui me gêne, loin de là, en ce moment je passe des nuits complète à optimiser... C'est plutôt de ne pas connaitre comment est structuré réellement une base, ça m'handicape dans mon élan...


Lien vers le commentaire
Partager sur d’autres sites

Une fois que tu auras loggué les requêtes lentes (slow queries) tu pourras utiliser EXPLAIN (par exemple sous phpMyAdmin) pour voir ce qui coince avec celles-ci.



Cela devrait grandement t'aider.


Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Bon, je viens aux nouvelles happy.gif



Il se trouve que je n'ai aucunes requêtes qui prennent plus d'une seconde à s’exécuter a_thumbsup_20.gif



Par contre, j'ai pas mal de requêtes qui n'utilisent pas (ou mal) les index, petit exemple :




# Time: 130330 19:15:14
# User@Host: X[X] @ [xxx.xxx.xxx.xxx]
# Query_time: 0.000218 Lock_time: 0.000016 Rows_sent: 0 Rows_examined: 1
SET timestamp=1364667314;
DELETE FROM ipb_sessions WHERE ip_address='xxx.xxx.xxx.xxx' OR id='google=xx3xxcxxxxbb60xx8xx6xx2x6c82xxx_session';
# Time: 130330 19:15:39
# User@Host: X[X] @ [xxx.xxx.xxx.xxx]
# Query_time: 0.000534 Lock_time: 0.000033 Rows_sent: 28 Rows_examined: 56
SET timestamp=1364667339;
SELECT f.*,p.* FROM ipb_forums f LEFT JOIN ipb_permission_index p ON ( p.perm_type='forum' AND p.app='forums' AND p.per$
# User@Host: X[X] @ [xxx.xxx.xxx.xxx]
# Query_time: 0.000185 Lock_time: 0.000033 Rows_sent: 19 Rows_examined: 63
SET timestamp=1364667339;
SELECT s.id, s.member_id, s.member_name, s.seo_name, s.login_type, s.running_time, s.member_group, s.uagent_type,pp.cns_$
# Time: 130330 19:15:57
# User@Host: X[X] @ [xxx.xxx.xxx.xxx]
# Query_time: 0.000172 Lock_time: 0.000017 Rows_sent: 0 Rows_examined: 1
SET timestamp=1364667357;
DELETE FROM ipb_sessions WHERE ip_address='xxx.xxx.xxx.xxx' OR id='google=xx3xxcxxxxbb60xx8xx6xx2x6c82xxx_session';


Edit :



./tuning-primer.sh me dit que j'ai 8590 requête qui ont mis plus d'une seconde à s’exécuter, par contre je ne les voient pas dans mon "slow.log"...




SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 1.000000 sec.
You have 8590 out of 7684513 that take longer than 1.000000 sec. to complete
Your long_query_time seems to be fine
Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

Hello,



pour ma part je tracerais toutes les requêtes supérieures à 100ms (c'est déjà beaucoup pour du web...), et ferais analyser le résultat par un outil type «mk-query-digest» (ou pt-query-digest selon la version) issu de maat-kit (= perconal-toolkit). Au moins tu sauras où commencer.



Petite remarque en passant : comme tu le dis tu es en full MYISAM pour tes tables, ça tombe bien, MYISAM gère très très mal les accès concurrents, ce qui vu ta charge est probablement la source du problème. INNODB de son coté tient vraiment beaucoup mieux, à condition de le configurer (oui la grosse abération de MySQL c'est de débarquer avec un INNODB inutilisable «out of the box»).


Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

J'ai déjà essayé de le faire, en le configurant comme ceci :




innodb_data_home_dir = /var/lib/mysql
innodb_data_file_path = ibdata1:50M:autoextend
innodb_log_group_home_dir = /var/lib/mysql
innodb_buffer_pool_size = 20G
innodb_additional_mem_pool_size = 32M
innodb_log_file_size = 5G
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50



Avec cette config, Mysql ne démarrais plus du tout... (fameux ".....Failed")



J'ai alors essayé de réduire : "innodb_log_file_size = 5G" à 3G et "innodb_log_buffer_size = 8M" à 1M



Là ça à démarré, et curieusement, ça n'était pas stable du tout (fracassage toutes les 5 minutes)... Mais en effet je n'avais plus aucuns lock de table


Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

innodb_log_file_size ne doit pas faire au moins 20% de la valeur du pool_size ? Ensuite, si je comprends bien, c'est le logfile0 et logfile1 que je déplace une fois mysql arrêté proprement ?

Par contre, si je passe toutes mes tables (wordpress et IPB donc) en innodb c'est pas contre-productif si je perds mes index fulltext ?

innodb_file_per_table et innodb_file_format = barracuda seront pris en compte sur les bases existantes ou j'ai des manips à faire ?


Je vais faire un autre essai ce soir... En prenant soins de faire un full backup avant :-D

Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

non, cette "recommandation" concernant innodb_log_file_size date d'une époque où MySQL n'était utilisé que pour des petites bases. Voici un article un peu plus intéressant à ce sujet : http://www.mysqlperformanceblog.com/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/ (qui évoque l'autre article de Peter Zaitsev, détaillant le comment du pourquoi).



Sinon oui ce sont bien les fichier ib_logfile0 & ib_logfile1 dont je parlais.



Et oui innodb_file_per_table & innodb_file_format sont à appliquer avant la conversion en InnoDB pour pouvoir en profiter.



Quant aux indexes fulltext, ils ne sont pas compatibles avec InnoDB (sauf version très récente, et encore le fonctionnement diffère). Donc les tables utilisant des indexes fulltext ne pourront pas être converties.


Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Et voilà, migration faite smartass.gif :



Tout tourne en ce moment même avec ça (grand merci Kioob, et très intéressant ton article) :




innodb_data_home_dir = /var/lib/mysql
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/lib/mysql
innodb_buffer_pool_size = 20G
innodb_additional_mem_pool_size = 32M
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_file_format = barracuda
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 50

On fait des tests de monté de charge là... voir comment ça se comporte...



Edit : Bon... ça ne tiens pas... à 3000 connexions Mysql s'éffondre, j'insiste bien, c'est Mysql qui pète sick.gif


Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

En 20 minutes buffer explosé oui je pense, et empilement de Task coté Apache/Php, j'ai tout repassé en Myisam pour temporiser...



Quand ça pète, impossible d'arreter proprement Mysql, ça part direct en "Failed". Rien dans error.log...



Screen de mon "planton" coté Google Analytics, hécatombe difficile de faire des test en prod sad.gif :



1179510107.jpg


Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

Je parlais du buffer InnoDB, as-tu laissé le temps à InnoDB de charger les données (en particulier les indexes), avant de lui couper la chique ?



Sur un MySQL standard, «vanilla», il faut voir InnoDB comme un diesel : il peut mettre longtemps à atteindre sa vitesse de croisière. Le couper après 20/30 minutes est très étonnant.


Mais hormis cela, vu que tu as du activer les logs slow queries, quelles sont les requêtes qui poseraient tant de mal à InnoDB ?

Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Aucunes. Je n'est rien dans les logs a part le démarrage du moteur de base de données et l'initialisation des buffers. Et dans le slow.log j'ai les mêmes log de requêtes qui n'utilisent pas d'index que dans mon post plus haut. Tout a tres bien fonctionné jusqu'à 2000/2500 visiteurs puis plantage. Mysql était complètement planté, même pas possible de l'arrêter. Et côté Apache php, les requêtes se sont empilées et le load average c'est envollé, sans pour autant s'effondrer.

Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

même pas possible de l'arrêter.


Mais si, c'est juste le «max connections» qui est atteint.



Tes logs «slow» tu les avais bien réduits à 100ms ? Car c'est difficile d'imaginer une saturation sans en avoir de trace ici.



De même, en surveillant en temps réel avec un outil type mytop ou innotop, le problème doit être facilement identifiable.


Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Je vais continuer à fouiller... Je suis toujours à 500 en max_connections.



Par contre, au quotidien je trouve que Mysql bouffe vraiment rien en CPU (htop de gauche, à droit c'est mon apache/php)... C'est normal ? :



1179570469.jpg


Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

Mon log de démarrage Innodb :




130401 21:03:19 mysqld_safe mysqld from pid file /var/lib/mysql/Srvxxxxxx.pid ended
130401 21:04:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130401 21:04:45 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-que$
130401 21:04:46 [Note] Plugin 'FEDERATED' is disabled.
130401 21:04:46 InnoDB: The InnoDB memory heap is disabled
130401 21:04:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130401 21:04:46 InnoDB: Compressed tables use zlib 1.2.3.4
130401 21:04:46 InnoDB: Using Linux native AIO
130401 21:04:46 InnoDB: Initializing buffer pool, size = 128.0M
130401 21:04:46 InnoDB: Completed initialization of buffer pool
130401 21:04:46 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
130401 21:04:46 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
130401 21:04:46 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130401 21:04:46 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
130401 21:04:46 InnoDB: Waiting for the background threads to start
130401 21:04:47 InnoDB: 5.5.30 started; log sequence number 2170520588
130401 21:04:47 [Note] Server hostname (bind-address): 'xxx.xxx.xxx.xxx'; port: 3306
130401 21:04:47 [Note] Server socket created on IP: 'xxx.xxx.xxx.xxx'.
130401 21:04:47 [Note] Event Scheduler: Loaded 0 events
130401 21:04:47 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.30-1~dotdeb.0-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)

Lien vers le commentaire
Partager sur d’autres sites

130401 21:04:46 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: Setting log file ./ib_logfile0 size to 5 MB

Buffer de 128M au lieu de 20G, et logfile de 5M au lieu de 256M. Tu te serais pas planté dans ta conf ?

Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Non, je suis sur de moi pour le coup smile.gif



Voilà ma config brut de fonderie à l'instant même :




[mysqld]
port = 3306
socket = /var/run/mysqld/mysqld.sock
bind-address = xxx.xxx.xxx.xxx

skip-external-locking
max_connections = 500
key_buffer_size = 10G
max_allowed_packet = 1M
table_open_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 128K
table_cache = 2048
query_cache_limit = 30M
query_cache_size = 128M
thread_cache_size = 20
max_heap_table_size = 128M

#skip-networking
server-id = 1

# Uncomment the following if you want to log updates
#log-bin=mysql-bin

log_error = /var/log/mysql/error.log
log-slow-queries = /var/log/mysql/slowww.log
long_query_time = 1
log-queries-not-using-indexes

# binary logging format - mixed recommended
#binlog_format=mixed

# Causes updates to non-transactional engines using statement format to be
# written directly to binary log. Before using this option make sure that
# there are no dependencies between transactional and non-transactional
# tables such as in the statement INSERT INTO t_myisam SELECT * FROM
# t_innodb; otherwise, slaves may diverge from the master.
#binlog_direct_non_transactional_updates=TRUE

# Uncomment the following if you are using InnoDB tables

# (using the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking
server-id = 1

# Uncomment the following if you want to log updates
#log-bin=mysql-bin

log_error = /var/log/mysql/error.log
log-slow-queries = /var/log/mysql/slowww.log
long_query_time = 1
log-queries-not-using-indexes

# binary logging format - mixed recommended
#binlog_format=mixed

# Causes updates to non-transactional engines using statement format to be
# written directly to binary log. Before using this option make sure that
# there are no dependencies between transactional and non-transactional
# tables such as in the statement INSERT INTO t_myisam SELECT * FROM
# t_innodb; otherwise, slaves may diverge from the master.
#binlog_direct_non_transactional_updates=TRUE


innodb_data_home_dir = /var/lib/mysql
innodb_data_file_path = ibdata1:50M:autoextend
innodb_log_group_home_dir = /var/lib/mysql
innodb_buffer_pool_size = 20G
innodb_additional_mem_pool_size = 32M
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_file_format = barracuda
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer_size = 8M
sort_buffer_size = 8M

[mysqlhotcopy]
interactive-timeout


On dirais qu'il prend les valeurs par défaut... Aurais-je fait une erreur de placement dans ma config ? J’apprécie bcp ton aide en tout cas !


Modifié par Torlax
Lien vers le commentaire
Partager sur d’autres sites

Ouais, c'est chelou on dirais qu'il m'ignore toute la partie innodb le sagouin... Bah, je finirais bien par trouvé ou ça coince... Merci pour ton aide en tt cas encore une fois :-)

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...