Mon Mysql Pédale et plante

[Mike91]

Bonjour,

voila je suis webmaster d'un site et je pense que il doit plus être accessible maintenant. je viens d'acquerir un serveur dédié ou j'ai donc installer MySQL/PHp .... Le truc c'est que j'ai un forum assez enorme ( enfin pas non plus démentielle, mais gros ) de l'odre de 15 000 sujets dans la table "forum_sujet" et 80 000 messages dans la "forum_msg".

Avec cette requete :

Code :

1
2
3
4
5
6
 SELECT fs.ID, COUNT(fm.ID) AS 'NbMsg'
                                           FROM forum_sujet fs
                                           LEFT JOIN  forum_msg fm ON fs.ID = fm.ID_sujet
                                           LEFT JOIN  categorie c ON fs.ID_forum = c.ID
                                           WHERE valid_news = 1
                                           GROUP BY fs.ID DESC ORDER BY fs.Dernier_Date DESC

Cette requete fonctionne mais au bon d'un moment quelques heures ... ça crash, le serveur plente, et il faut tout redemarré. De plus cette requete est hyper lente, elle peut prendre presque 40sec parfois !!

j'ai donc optimisé avec ça :

Code :

1
2
3
4
 SELECT fs.ID, COUNT(fm.ID) AS 'NbMsg'
                                           FROM forum_sujet fs, forum_msg fm
                                           WHERE fs.ID = fm.ID_sujet AND valid_news = 1
                                           GROUP BY fs.ID DESC ORDER BY fs.Dernier_Date DESC

Sauf que celle là, c'est radical, ça fé tout plenté direct, reboot complet, il veut plus rien savoir, Mysql patine dans la semoule !!

J'ai d'abord pensé un crash de table, j'ai donc réparer , optimisé, analyser ces deux tables !! et rien de particulier, tout va bien !! Et ça rame à mort avec la premiere requete, et ça plente direct avec la deuxième.

VOila je suis donc perdu, le site n'est plus en ligne et crash tout le temps !! j'ai pensé à l'espace memoire attribué à Mysql pour de grosse requete ... j'ai modifier, ça avait l'air d'aller, mais ça a fini par cracher qd même. Est ce que Mysql accumule quelques chose au cours du temp ??? et fini par plenter ? pourquoi ma deuxieme requete patine dans le semoule ( renvoi aucune erreur evidemment ) ....

Voila j'y arrive plus .... si quelqu'un à une idée ????

PS : j'ai 128Mo de RAM sur mon dédié.

[Alexandre T]

Code :

1
2
3
4
5
6
 
SELECT fs.ID, COUNT(fm.ID) AS 'NbMsg'
    FROM forum_sujet fs
    INNER JOIN forum_msg fm ON fs.ID = fm.ID_sujet
    WHERE valid_news = 1
    GROUP BY fs.ID DESC ORDER BY fs.Dernier_Date DESC

1 - Cette jointure est préférable.

2- Lancez et retournez-nous le résultat un EXPLAIN PLAN de cette requête :

Code :

1
2
3
4
5
6
 
EXPLAIN SELECT fs.ID, COUNT(fm.ID) AS 'NbMsg'
    FROM forum_sujet fs
    INNER JOIN forum_msg fm ON fs.ID = fm.ID_sujet
    WHERE valid_news = 1
    GROUP BY fs.ID DESC ORDER BY fs.Dernier_Date DESC

3- Merci de nous retourner la description des tables :

Code :

1
2
 
SHOW CREATE TABLE FORUM_SUJET\G

Code :

1
2
 
SHOW CREATE TABLE FORUM_MSG\G

[Mike91]

Voila pour le explain

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE fs ALL PRIMARY NULL NULL NULL 14438 Using where; Using temporary; Using filesort
1 SIMPLE fm ref ID_sujet ID_sujet 4 moteurprog.fs.ID 6

et les tables ça donne ça :

CREATE TABLE `forum_msg` (
`ID` int(8) NOT NULL auto_increment,
`ID_sujet` int(11) NOT NULL default '0',
`Titre` varchar(100) NOT NULL default '',
`Message` longtext NOT NULL,
`Date` datetime default NULL,
`Membre` varchar(80) NOT NULL default '',
`ID_membre` int(11) NOT NULL default '0',
PRIMARY KEY (`ID`),
KEY `ID_sujet` (`ID_sujet`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=101429 ;


CREATE TABLE `forum_sujet` (
`ID` int(8) NOT NULL auto_increment,
`ID_forum` int(3) NOT NULL default '0',
`Referant` int(1) NOT NULL default '0',
`Titre` varchar(100) NOT NULL default '',
`Type` int(11) NOT NULL default '0',
`Clicks` int(5) NOT NULL default '0',
`ID_ss_cat` int(8) NOT NULL,
`Membre` varchar(80) NOT NULL default '',
`Dernier_Date` datetime default NULL,
`Dernier_pseudo` varchar(80) NOT NULL default '',
`Vue` int(1) NOT NULL default '0',
`Date_crea` datetime NOT NULL default '0000-00-00 00:00:00',
`resolu` int(1) NOT NULL default '0',
`ID_membre` int(11) NOT NULL default '0',
`Bloquer` int(1) NOT NULL default '0',
`FAQ` int(1) NOT NULL default '0',
`valid_news` int(1) NOT NULL default '1',
`Delestage_date` date NOT NULL,
`sondage` int(1) NOT NULL default '0',
PRIMARY KEY (`ID`),
KEY `ID_forum` (`ID_forum`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=21533 ;

Voila !! pour infos a quoi sert le explain ?

[Alexandre T]

Un index sur Valid_news peut aider.

EXPLAIN permet de lister les index possibles et de dire lesquels sont utilisés, lesquels ne le sont pas.

Mais apparement, pas bcp d'optimisation possible niveau modèle. Niveau configuration serveur par contre...

Quelques notes à lire sont déjà dans lLa FAQ MySQL

[gregory.broissard]

c'est pas possible qu'avec aussi peu de volumétrie, on fasse planter un serveur, ou qu'une requête comme ca dure 40 secondes!

Il doit y avoir autre chose que la requete SQL...

[Maximilian]

Comme dit Alexandre un index sur valid_news (et sur Dernier_date) peut être utile.

Sinon c'est dans un script PHP ou même en ligne de commande ça fait tout planter ?

[chat hotplug]

MMmhh...

Ou alors le forum est ultra fréquenté à tel point que les tables sont rarement accessibles (LOCK TABLE ?).

Par contre un petit début du style

Code :

SELECT HIGH_PRIORITY

Ca pourrait contribuer à l'optimisation...

[Mike91]

merci pour vos réponses ... vraisemblablement après plusieurs test !! c'est la RAM qui est en cause, output memory sur des requetes SQL qui s'accumulent et ça fini par tout crashé !! Pour le moment c'est donc un pote qui m'heberge la base de donnée sur son serveur et le site sur mon dédié. ça marche correctement.

Pour le problème de la requete qui fé tout plenté, elle marche désormais sur l'autre base de donnée. Donc ça devait provenir de la RAM !!

Voila sinon pour rajouter un index sur valid_news ? ce champs ne prend comme valeur que 0 ou 1, est ce qu'un index est bien nécessaire ? même pour 2 valeurs ?

Merci à vous !

[Alexandre T]

Ah si il n'y a que deux valeurs, non, en effet ! Si vous faites un EXPLAIN suivi de la requête vous verrez les index disponibles et ceux utiliser. Ceux qui apparement ne sont pas utilisé peuvent à la rigueur être supprimé. Mais il est étonnant qu'une faible RAM fasse rebooter le serveur quand il atteint le maximum de RAM disponible. En général, il swappe dans un premier temps.

Il est possible de mieux configurer le serveur. Peut-on avoir un SHOW VARIABLES (je ne suis plus sûr de la syntaxe).

[Mike91]

Voila :

Serveur: localhost
Base de données: moteurprog
Généré le : Mardi 20 Juin 2006 à 16:44
Généré par: phpMyAdmin 2.6.4-pl4 / MySQL 5.0.22-standard-log
requête SQL: SHOW VARIABLES ;
Enregistrements: 210
Variable_name Value
auto_increment_increment 1
auto_increment_offset 1
automatic_sp_privileges ON
back_log 50
basedir /usr/
binlog_cache_size 32768
bulk_insert_buffer_size 8388608
character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/
collation_connection utf8_general_ci
collation_database latin1_swedish_ci
collation_server latin1_swedish_ci
completion_type 0
concurrent_insert 1
connect_timeout 5
datadir /home/mysql-data/
date_format %Y-%m-%d
datetime_format %Y-%m-%d %H:%i:%s
default_week_format 0
delay_key_write ON
delayed_insert_limit 100
delayed_insert_timeout 300
delayed_queue_size 1000
div_precision_increment 4
engine_condition_pushdown OFF
expire_logs_days 0
flush OFF
flush_time 0
ft_boolean_syntax + -><()~*:""&|
ft_max_word_len 84
ft_min_word_len 4
ft_query_expansion_limit 20
ft_stopword_file (built-in)
group_concat_max_len 1024
have_archive YES
have_bdb NO
have_blackhole_engine NO
have_compress YES
have_crypt YES
have_csv NO
have_example_engine NO
have_federated_engine NO
have_geometry YES
have_innodb YES
have_isam NO
have_ndbcluster NO
have_openssl DISABLED
have_query_cache YES
have_raid NO
have_rtree_keys YES
have_symlink YES
init_connect
init_file
init_slave
innodb_additional_mem_pool_size 1048576
innodb_autoextend_increment 8
innodb_buffer_pool_awe_mem_mb 0
innodb_buffer_pool_size 8388608
innodb_checksums ON
innodb_commit_concurrency 0
innodb_concurrency_tickets 500
innodb_data_file_path ibdata1:10M:autoextend
innodb_data_home_dir
innodb_doublewrite ON
innodb_fast_shutdown 1
innodb_file_io_threads 4
innodb_file_per_table OFF
innodb_flush_log_at_trx_commit 1
innodb_flush_method
innodb_force_recovery 0
innodb_lock_wait_timeout 50
innodb_locks_unsafe_for_binlog OFF
innodb_log_arch_dir
innodb_log_archive OFF
innodb_log_buffer_size 1048576
innodb_log_file_size 5242880
innodb_log_files_in_group 2
innodb_log_group_home_dir ./
innodb_max_dirty_pages_pct 90
innodb_max_purge_lag 0
innodb_mirrored_log_groups 1
innodb_open_files 300
innodb_support_xa ON
innodb_sync_spin_loops 20
innodb_table_locks ON
innodb_thread_concurrency 8
innodb_thread_sleep_delay 10000
interactive_timeout 28800
join_buffer_size 131072
key_buffer_size 268435456
key_cache_age_threshold 300
key_cache_block_size 1024
key_cache_division_limit 100
language /usr/local/mysql/share/mysql/english/
Variable_name Value
large_files_support ON
large_page_size 0
large_pages OFF
license GPL
local_infile ON
locked_in_memory OFF
log ON
log_bin ON
log_bin_trust_function_creators OFF
log_error
log_slave_updates OFF
log_slow_queries OFF
log_warnings 1
long_query_time 10
low_priority_updates OFF
lower_case_file_system OFF
lower_case_table_names 1
max_allowed_packet 1047552
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connect_errors 10
max_connections 100
max_delayed_threads 20
max_error_count 64
max_heap_table_size 16777216
max_insert_delayed_threads 20
max_join_size 18446744073709551615
max_length_for_sort_data 1024
max_prepared_stmt_count 16382
max_relay_log_size 0
max_seeks_for_key 4294967295
max_sort_length 1024
max_sp_recursion_depth 0
max_tmp_tables 32
max_user_connections 0
max_write_lock_count 4294967295
multi_range_count 256
myisam_data_pointer_size 6
myisam_max_sort_file_size 2147483647
myisam_recover_options OFF
myisam_repair_threads 1
myisam_sort_buffer_size 67108864
myisam_stats_method nulls_unequal
net_buffer_length 16384
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
new OFF
old_passwords OFF
open_files_limit 1024
optimizer_prune_level 1
optimizer_search_depth 62
pid_file /home/mysql-data/mysqld.pid
prepared_stmt_count 0
port 3306
preload_buffer_size 32768
protocol_version 10
query_alloc_block_size 8192
query_cache_limit 1048576
query_cache_min_res_unit 4096
query_cache_size 16777216
query_cache_type ON
query_cache_wlock_invalidate OFF
query_prealloc_size 8192
range_alloc_block_size 2048
read_buffer_size 1044480
read_only OFF
read_rnd_buffer_size 4190208
relay_log_purge ON
relay_log_space_limit 0
rpl_recovery_rank 0
secure_auth OFF
server_id 1
skip_external_locking ON
skip_networking OFF
skip_show_database OFF
slave_compressed_protocol OFF
slave_load_tmpdir /home/mysqltmp/
slave_net_timeout 3600
slave_skip_errors OFF
slave_transaction_retries 10
slow_launch_time 2
socket /var/run/mysqld/mysqld.sock
sort_buffer_size 1048568
sql_mode
sql_notes OFF
sql_warnings OFF
storage_engine MyISAM
sync_binlog 0
sync_frm ON
system_time_zone CEST
table_cache 256
table_lock_wait_timeout 50
table_type MyISAM
thread_cache_size 8
thread_stack 126976
time_format %H:%i:%s
time_zone SYSTEM
timed_mutexes OFF
tmp_table_size 33554432
Variable_name Value
tmpdir /home/mysqltmp
transaction_alloc_block_size 8192
transaction_prealloc_size 4096
tx_isolation REPEATABLE-READ
updatable_views_with_limit YES
version 5.0.22-standard-log
version_comment MySQL Community Edition - Standard (GPL)
version_compile_machine i686
version_compile_os pc-linux-gnu
wait_timeout 28800

[Maximilian]

Envoyé par Mike91

key_buffer_size 268435456

268 Mo sur un serveur avc 128 Mo de RAM