Jump to content
Torlax

[Recherche] aide pour optimisation base Mysql

Rate this topic

Recommended Posts

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

Edited by Torlax

Share this post


Link to post
Share on other 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 !


Share this post


Link to post
Share on other 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.


Share this post


Link to post
Share on other 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...


Share this post


Link to post
Share on other 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.


Share this post


Link to post
Share on other sites

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
Edited by Torlax

Share this post


Link to post
Share on other 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»).


Share this post


Link to post
Share on other sites

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


Edited by Torlax

Share this post


Link to post
Share on other sites

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.


  • Upvote 1

Share this post


Link to post
Share on other sites

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

Edited by Torlax

Share this post


Link to post
Share on other 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.


Share this post


Link to post
Share on other sites

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


Edited by Torlax

Share this post


Link to post
Share on other sites

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


Share this post


Link to post
Share on other sites

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


Edited by Torlax

Share this post


Link to post
Share on other 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 ?

Share this post


Link to post
Share on other sites

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.

Edited by Torlax

Share this post


Link to post
Share on other 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.


Share this post


Link to post
Share on other sites

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


Edited by Torlax

Share this post


Link to post
Share on other 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)

Share this post


Link to post
Share on other 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 ?

Share this post


Link to post
Share on other sites

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 !


Edited by Torlax

Share this post


Link to post
Share on other sites

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


Share this post


Link to post
Share on other 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 :-)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By billcom
      Bonjour à tous,



      J'ai, sur un site d'offre d'emploi, une liste de domaines et plusieurs offres.


      Chaque offre à un domaine correspondant.



      Structure des tables :

      table domaine
      id_domaine
      nom_domaine
      ...

      table offre
      id_offre
      id_domaine
      date
      ...

      Sur une page du site, j'aimerai lister tous les domaines ainsi que les trois dernières offres du domaine en question.



      Pour avoir ce résultat, je fais actuellement :

      Une requête qui récupère les domaines;
      Puis quand j'affiche les domaines avec un foreach(), je fais une requête qui récupère les 3 dernières offres correspondant au domaine courant.
      Le problème, c'est que faire une requête dans une boucle n'a jamais été top et effectivement la page est longue à charger.



      J'ai alors mis en cache la requête (remember / j'utilise le framework Laravel) afin que la page soit plus rapide. Cependant au premier chargement la page met très longtemps a apparaître.



      J'aimerai optimiser ce premier chargement.



      J'ai essayé de faire une requête avec une sous-requête mais sans succès et je ne sais même pas si c'est possible.



      Si vous êtes un champion de SQL ou que vous voyer la faille dans mon raisonnement, j'attend votre aide



      Merci d'avance.

    • By eechoo
      Bonjour à tous,



      Auriez vous une soluc pour afficher un code ou un mot aléatoirement avec du PHP sur mon site ?



      Pourquoi PHP ?



      Car je veux aussi que ce mot soit stocker au même moment dans la BBD ( une table bien précise )



      Concrètement :



      1 - Un internaute clique sur un bouton paypal de mon site



      2 - il est dirigé vers paypal et effectue le paiement



      3- le paiement terminé il est dirigé vers la page de connexion sur mon site. Et c'est la qu'intervient le code aléatoire ( ex : voiçi votre mot de passe et nom d'utilisateur )



      Donc : mon site > paypal > retour sur mon site et login > téléchargement du fichier.



      Ou alors connaissez vous vous un script pret à l'emploi permettant de télécharger un fichier uniquement aprés un paiement, car à part ces étapes je ne vois pas d'autres solutions



      Merci par avance,



      Bonne soirée à tous.

    • By eechoo
      Bonjour à tous,



      Ca faisait longtemps.



      J'ai parcouru le forum et on en parle beaucoup ( des jointures ) mais je m'y perd. étant designer et non pas devellopeur je ne sais pas trop comment joindre 2 tables c'est à dire :



      J'ai installer une mini boutique sur mon site. Ca fonction tres bien sauf que c'est livré sans catégories. C'est à dire qu'on peut juste mettre des produits mais pas des catégories.



      J'ai donc créer une table dans phpmyadmin pour les catégories, juqu'ici tout va bien.



      J'ai donc la table des produits comportant : ID, nom du produit, prix, etc..



      J'ai aussi la table des catégories comportant : ID, nom de la catégorie, description, etc...



      C'est la que je bloque, comment lié ces 2 tables afin d'afficher les produits d'une categorie spécifique.



      Merci à tous

    • By billcom
      Bonjour le hub,



      Je bloque sur une requête sql pour MYSQL.



      J'ai une liste d'evenement avec un id "id_ev" et une date de début type DATE "date_deb_ev". Certains évènements sont déjà passé et d'autre sont à venir.

      J'aimerai écrire une requête qui me permet d'afficher l'ensemble des évènements avec pour ordre d'affichage



      Dans un premier temps les évènements à venir trié par date_deb_ev ASC et ensuite les évènement passé par date_deb_ev DESC le tout en une seule requête



      Pour le moment j'ai ça


      SELECT id_ev, date_deb_ev
      FROM evenements
      ORDER BY CASE WHEN
      date_deb_ev >= CURDATE() THEN 0 ELSE 1 end ASC,
      id_ev ASC




      +-------+-------------+
      | id_ev | date_deb_ev |
      +-------+-------------+
      | 59 | 2014-04-30 |
      | 106 | 2014-05-23 |
      | 110 | 2014-04-26 |
      | 146 | 2014-05-21 |
      | 147 | 2014-04-30 |
      | 156 | 2014-04-26 |
      | 172 | 2014-04-30 |
      | 175 | 2014-05-23 |
      | 202 | 2014-05-21 |
      | 224 | 2014-05-27 |
      | 226 | 2014-05-27 |
      | 227 | 2014-05-28 |
      | 242 | 2014-05-21 |
      | 243 | 2014-04-28 |
      | 254 | 2014-04-26 |
      | 266 | 2014-04-30 |
      | 267 | 2014-04-30 |
      | 268 | 2014-05-24 |
      | 270 | 2014-06-18 |
      | 278 | 2014-04-30 |
      +-------+-------------+
      20 rows in set (0.04 sec)


      ça me retourne un resultat mais rien de cohérent avez vous une idée ou une piste pour mener à bien ma requête ?

×
×
  • Create New...