Discussion :

[re12]

J'ai bien accès à la configuration de MySQL

J'ai mis key_buffer_size à 32M

C'est pareil, même après l'optimisation.
Le disque gratte à chaque

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
SELECT COUNT(*) AS nb_lignes
FROM product

[CinePhil]

Le disque gratte à chaque

Que veux-tu dire par là ?

Tu disais plus haut qu'il s'agit d'une machine virtuelle. Dans une baie de virtualisation bien dimensionnée ?

Combien de mémoire vive est affectée à cette machine virtuelle ?

[re12]

Alors la VM est installé sur le disque de ma machine.

1Go de mémoire vive, une debian avec MySQL 5.1.61
J'utilise VirtualBox

[CinePhil]

1 Go de mémoire pour un SGBD, ce n'est pas beaucoup. Si en plus cette RAM est partagée entre la machine principale et la machine virtuelle, pas étonnant que Debian swappe !

Je pensais à un serveur virtuel sur une baie VMWare.

Au fait, pourquoi avoir virtualisé cette machine sur ta machine ?
Elle est sous Winbug ?

[ericd69]

même si c'est le cas c'est pas le soucis... vilain linuxien normand...

c'est vrai qu' 1go c'est pas beaucoup... surtout pour brasser une bd qui contient une table avec 20M tuples et des jointure dessus...

donc augmente déjà ça...

après une question qui me turlupine... tu as mis quoi en index de clé primaire dans cette colossale table? parce que même si mysql s'y reprend à plusieurs fois pour générer le count... on parle toujours de product ou d'une autre table?

le show table status dit quoi pour la taille d'index?

et oui précise ce que tu appelle "le disque gratte" car si sa se trouve si tu as un vieux DD, il est juste en train de mourir, ce qui expliquerait ses contre-performances...

[re12]

Alors je viens de passer à 3Go.

Je passe à 15s pour le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT COUNT(*) as total
FROM product

Je l'ai virtualité car c'est pour une application en cours de développement.
Je travaille sur Mac.

Le show table status donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
		"Name": "product",
			"Engine": "InnoDB",
			"Version": 10,
			"Row_format": "Compact",
			"Rows": 16156729,
			"Avg_row_length": 43,
			"Data_length": 705691648,
			"Max_data_length": 0,
			"Index_length": 0,
			"Data_free": 714080256,
			"Auto_increment": 16156434,
			"Create_time": "2012-05-21 15:27:09",
			"Update_time": null,
			"Check_time": null,
			"Collation": "utf8_unicode_ci",
			"Checksum": null,
			"Create_options": "",
			"Comment": ""

Ce que j'entend par le disque gratte c'est qu'il y a une lecture qui est faite sur le disque.

[ericd69]

<troll>un mac qu'elle idée, on parle de vrais ordinateurs ou serveurs</troll>

bon on avance... la virtualisation jouant énormément sur le reste...

"Max_data_length": 0,
"Index_length": 0,

bizarre ces 2 valeurs... elles devraient pas être nulles...

à savoir qu'innodb est beaucoup plus lent que mysiam de par son aspect relationnel... si le besoin d garantir les transaction sur cette table n'est pas avéré autan la passer en myisam... tu y gagneras temps d'accès encore un peu...

oublie pas d'augmenter la taille du buffer d'index au début de la section [mysqld] vu que les réglage innodb sont à part...

[Fred_34]

Si tu n'as pas besoin du nombre exact d'enregistrements, tu peux faire ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT TABLE_ROWS As total FROM information_schema.TABLES WHERE   TABLE_NAME="product"

[re12]

Malheureusement j'ai besoin du nombre exact de ligne

[punkoff]

Et quand vous faites un explain sur la requete il utilise bien l'index ?

[re12]

Voici le résultat de l'explain :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
EXPLAIN SELECT COUNT(*) AS total
FROM product

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	product	index	NULL	PRIMARY	4	NULL	16156729	Using index

[ericd69]

à priori il utilise l'index...

donc essaye de gonfler encore la configuration de ta VM si tu peux...

[re12]

J'ai passé la vm 4 à core, 8Gb de ram.

Mais il y a encore et toujours cette lecture du disque dur au premier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT COUNT(*) AS total
FROM product

La requête met 9 secondes à s'exécuter

[punkoff]

Il fait combien de Mo votre index en fait ?

[ericd69]

c'est normal, ton index ne représente pas que la taille des données mais aussi la taille du btree qui les organise... donc avec environ 20M tuplues tu va te retrouver avec un index qui doit faire entre 50 et 200M selon l'ordre du btree qu'utilise mysql (ils le dis pas... 2 mini mais on ne sait pas si l'ordre augmente pour limiter la taille sur des gros index) donc ils faudra plusieurs lecture pour le passer en revue...

essaye de doubler les valeur innodb...

après comme je l'avais déjà dit soit tu devras passer à un sgbd qui as des possibilité de prendre, avec des réglages de bases des tables plus conséquentes... ou tu devras peut-être revoir ton modèle de données et scinder ta table horizontalement selon des critères bien choisis...

même si tu n'as pas un dédié ça ne passera pas pour les requêtes... vu que 9 secondes, ce n'est pas acceptable pour une simple requête de comptage...

[punkoff]

D'après ce que je comprend ça n'est qu'à la 1ere execution que le select met 9 secondes à s'executer.

Donc... c'est le moment où le SGBD met en RAM l'index qui est sur disque (après plus de problème au niveau de l'execution vu que tout ce passe depuis la RAM).

[re12]

On est bien d'accord que c'est trop long pour une simple requête.

Voici les stats de la table :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Données		740		Mio
Index		        148,7 	Mio

Concernant le choix d'un autre SGBD que me conseilleriez vous ? postresql souffre apparemment du même problème

[punkoff]

Nan mais là remettez en cause :
- votre matèriel
- la VM
- le combo mac / linux

Je ne pense pas que cela vienne de MySql.

[punkoff]

hmm,

je viens de relire le thread et un truc ne me semble pas précis.

Vous dites avoir mis 3go puis 8go de ram a votre VM.

Soites. Mais avez-vous, par la même occasion, impacté les paramètres de MySql (comme le suggérait Eric) ?

Car juste mettre de la ram sans rien touché ne va pas servir à grand chose.

Vu que votre table est en innobdb : http://www.mysqlperformanceblog.com/...fer_pool_size/

[re12]

Effectivement je n'ai pas augmenté la config linux derrière.

Je vais faire le test sur une machine dédiée, car effectivement c'est peut-être un problème de matériel.