[Recherche] aide pour optimisation base Mysql

[Torlax]

Bonjour à tous !

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

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é 28 Mars 2013 par Torlax

[SStephane]

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 !

[lebel]

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.

[Torlax]

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...

[Dan]

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.

[Torlax]

Merci beaucoup pour vos réponses, je vais essayer de faire ca a coup d'explain

[Torlax]

Bon, je viens aux nouvelles

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

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é 31 Mars 2013 par Torlax

[Kioob]

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»).

[Torlax]

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é 31 Mars 2013 par Torlax

[Kioob]

A partir du moment où tu modifies innodb_log_file_size, il faut éteindre MySQL proprement, déplacer les 2 fichiers ib_logfile[01] ailleurs, puis re-démarrer MySQL, afin qu'il re-construise ces fichiers à la bonne taille. A noter que 5G ici me semble monstrueux... j'ai pas souvenir avoir dépassé 256Mo sur ce critère, avec pourtant de grosses bases, très sollicitées.

Pour le innodb_flush_log_at_trx_commit, je pense que la valeur 2 aurait suffit, et pour ma part j'aurais ajouté innodb_file_per_table ainsi que innodb_flush_method = O_DIRECT et innodb_file_format = barracuda.

Dans tous les cas, généralement il faut superviser l'impact de tout ça avant de modifier, et de préférence comprendre l'impact de la modification avant de l'appliquer.

[Torlax]

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é 1 Avril 2013 par Torlax

[Kioob]

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.

[Torlax]

Et voilà, migration faite :

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

Modifié 1 Avril 2013 par Torlax

[Kioob]

En 20 minutes MySQL avait déjà chargé son buffer ? Parce que si tu n'attends pas au moins ça, tu ne compares pas grand chose...

[Torlax]

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 :

Modifié 1 Avril 2013 par Torlax

[Kioob]

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 ?

[Torlax]

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é 2 Avril 2013 par Torlax

[Kioob]

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.

[Torlax]

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 ? :

Modifié 2 Avril 2013 par Torlax

[Torlax]

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)

[Kioob]

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 ?

[Torlax]

Non, je suis sur de moi pour le coup

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é 2 Avril 2013 par Torlax

[Kioob]

Désolé mais là comme ça je vois pas : le fichier de conf a l'air ok, mais d'après tes logs il est clairement ignoré par MySQL.

[Torlax]

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 :-)

[Kioob]

Mais de rien