20 minutes pour un import de 15000 lignes, normal ?

Phenol · 24/02/2011, 10h32

Bonjour,

Un client de la Web Agency où je bosse se sert d'un CSV (en provenance de Sage) pour importer ses produits, leurs caractéristiques ainsi que d'autres informations liées à ceux-ci.

Bref, plutôt qu'effectuer une requête SQL de type INSERT par produits/caractéristiques, nous avons décidé de créer un fichier .sql contenant toutes les requêtes (1 par ligne) et de l'importer par la suite via un script Shell.

Ce .sql comporte donc environ 15000 lignes et met actuellement 20 minutes à être importé.

Ma question est la suivante : est-ce une durée normale ? Si non, comment réduire cette durée, quels paramètres optimiser sur le serveur dédié (http://www.ovh.com/fr/produits/superplan_best_of.xml) ?

Informations :
- les tables concernées sont en InnoDB
- un import local (WAMP) du .sql met environ 1 minute à être effectué (via PHPMyAdmin > Importer)

Je suis à votre disposition pour toute information qui pourrait vous aider à répondre à ma question.

Merci par avance.

patic · 24/02/2011, 10h50

Bonjour,
Avez vous essayé de tester le lancement du script directement en local, c'est à dire après avoir uploadé le fichier (par ftp par exemple) sur le serveur puis via le shell à distance ?
Cela vous indiquerait déjà d'où vient le problème, la connexion ou bien le serveur ...

Phenol · 24/02/2011, 10h55

Tout d'abord merci pour votre réponse.

Pour répondre à votre question : Oui, le script Shell télécharge le .sql avant de l'exécuter en local.

patic · 24/02/2011, 11h14

On s'est mal compris, pour trouver l'origine du problème, il faudrait tester manuellement, sans utiliser le script automatique déjà fait.
Vous téléchargez manuellement le fichier .sql sur le serveur puis vous ouvrez un shell à distance, lancez une session mysql et exécutez le script. Si ce dernier point met toujours 20 minutes, vous aurez déjà identifié la source du problème. En gros il faut découper les tâches du script une à une, jusqu'à tomber sur le problème.

Phenol · 24/02/2011, 11h31

Le script Shell ne fait qu'un "mysql .......... < data.sql".

J'ai testé directement la commande dans le Shell avec le même résultat.

J'espère répondre concrètement à votre question et l'avoir bien comprise.

Merci encore.

Nudger · 24/02/2011, 11h59

Bonjour,

15000 en 20 minutes, ça fait 12,5 par seconde.
Suivant le contexte c'est peut-être pas si mal que ça.

- Combien de lignes contient la table ?
- Combien de colonnes contient la table ?
- Combien d'index y a-t-il sur cette table ?
- Y a-t-il des triggers sur la table ?
- Le script est-il exécuté sur le serveur qui héberge la base MySQL ?

CinePhil · 24/02/2011, 13h55

Citation:

Un client de la Web Agency où je bosse se sert d'un CSV (en provenance de Sage) pour importer ses produits, leurs caractéristiques ainsi que d'autres informations liées à ceux-ci.

Plutôt que de faire 15 000 INSERT, tu as essayé LOAD DATA INFILE ?
Et s'il faut ensuite répartir les données dans plusieurs tables, tu charges le CSV dans une table temporaire avec LOAD DATA INFILE puis avec les requêtes adéquates, tu répartis les données dans les bonnes tables.
C'est peut-être plus long à préparer mais si c'est une opération répétitive, ce sera sûrement plus rapide à terme.

qi130 · 24/02/2011, 16h10

Les tables sont en InnoDB...

Il y a donc des FK et le contrôle de leur respect ce qui n'est pas gratuit non plus.

Est il envisageable d'effectuer un commit de temps en temps afin d'alléger la journalisation ?

kedare · 24/02/2011, 17h18

Tu fais bien tout dans une seule transaction ?
Si c'est pas le cas il y a un commit a chaque insert donc c'est normal que ca soit lent...

slefevre01 · 24/02/2011, 18h35

Salut,
peux-tu transmettre ton my.cnf ?

Comme t'es sur un dédié, tu peux exécuter mysqltuner qui te fournira qq pistes d'optimisation. http://blog.mysqltuner.com/download/

Sébastien

patic · 25/02/2011, 10h00

Bonjour,
A mon avis, si le test met 1 minute sur une simple machine tournant sous windows comparé à 20 minutes sur un serveur sous linux je suppose que c'est que vous n'avez pas la même configuration entre les deux machines, sous windows mysql est bien plus lent même avec la 5.5. Voir les contraintes comme les clés étrangères des tables en innodb, les triggers, les index aussi.
Avez vous essayé avec un ETL du type de Pentaho Kettle (à condition que vous ayez un accès distant à la base), c'est ultra simple dans des cas d'import sans modification comme ici ?
Sinon, découpez votre script .sql pour voir quelle partie est la source d'étranglement.

24/02/2011, 10h32	#1
Phenol Membre à l'essai Cédric D. Développeur Web Inscription : mai 2004 Messages : 68 Détails du profil Informations personnelles : Nom : Cédric D. Âge : 28 Localisation : France Informations professionnelles : Activité : Développeur Web Informations forums : Inscription : mai 2004 Messages : 68 Points : 24 Points : 24	20 minutes pour un import de 15000 lignes, normal ? Bonjour, Un client de la Web Agency où je bosse se sert d'un CSV (en provenance de Sage) pour importer ses produits, leurs caractéristiques ainsi que d'autres informations liées à ceux-ci. Bref, plutôt qu'effectuer une requête SQL de type INSERT par produits/caractéristiques, nous avons décidé de créer un fichier .sql contenant toutes les requêtes (1 par ligne) et de l'importer par la suite via un script Shell. Ce .sql comporte donc environ 15000 lignes et met actuellement 20 minutes à être importé. Ma question est la suivante : est-ce une durée normale ? Si non, comment réduire cette durée, quels paramètres optimiser sur le serveur dédié (http://www.ovh.com/fr/produits/superplan_best_of.xml) ? Informations : - les tables concernées sont en InnoDB - un import local (WAMP) du .sql met environ 1 minute à être effectué (via PHPMyAdmin > Importer) Je suis à votre disposition pour toute information qui pourrait vous aider à répondre à ma question. Merci par avance.
	00

24/02/2011, 10h50	#2
patic Membre confirmé Inscription : novembre 2007 Messages : 134 Détails du profil Informations forums : Inscription : novembre 2007 Messages : 134 Points : 213 Points : 213	test sur le serveur Bonjour, Avez vous essayé de tester le lancement du script directement en local, c'est à dire après avoir uploadé le fichier (par ftp par exemple) sur le serveur puis via le shell à distance ? Cela vous indiquerait déjà d'où vient le problème, la connexion ou bien le serveur ...
	00

24/02/2011, 11h59	#6
Nudger Membre Expert Thomas Arnaud Directeur de projet Inscription : octobre 2010 Messages : 452 Détails du profil Informations personnelles : Nom : Thomas Arnaud Âge : 36 Localisation : France, Paris (Île de France) Informations professionnelles : Activité : Directeur de projet Secteur : High Tech - Produits et services télécom et Internet Informations forums : Inscription : octobre 2010 Messages : 452 Points : 1 012 Points : 1 012	Bonjour, 15000 en 20 minutes, ça fait 12,5 par seconde. Suivant le contexte c'est peut-être pas si mal que ça. - Combien de lignes contient la table ? - Combien de colonnes contient la table ? - Combien d'index y a-t-il sur cette table ? - Y a-t-il des triggers sur la table ? - Le script est-il exécuté sur le serveur qui héberge la base MySQL ? __________________ www.nudge.org Surveillez et optimisez vos applications Java
	00

24/02/2011, 16h10	#8
qi130 Expert Confirmé Sénior Pierre Ingénieur qualité méthodes Inscription : mars 2003 Messages : 3 726 Détails du profil Informations personnelles : Nom : Pierre Âge : 51 Localisation : France Informations professionnelles : Activité : Ingénieur qualité méthodes Secteur : Finance Informations forums : Inscription : mars 2003 Messages : 3 726 Points : 4 739 Points : 4 739	Les tables sont en InnoDB... Il y a donc des FK et le contrôle de leur respect ce qui n'est pas gratuit non plus. Est il envisageable d'effectuer un commit de temps en temps afin d'alléger la journalisation ? __________________ "Il n'y a pas de bonnes réponses à une mauvaise question." (M. Godet) ----------------------- Pensez à cloturer votre sujet - Aucune réponse aux sollicitations techniques par MP Usus magister est optimus
	00

24/02/2011, 18h35	#10
slefevre01 Membre du Club Inscription : mars 2005 Messages : 66 Détails du profil Informations personnelles : Âge : 39 Informations forums : Inscription : mars 2005 Messages : 66 Points : 44 Points : 44	Salut, peux-tu transmettre ton my.cnf ? Comme t'es sur un dédié, tu peux exécuter mysqltuner qui te fournira qq pistes d'optimisation. http://blog.mysqltuner.com/download/ Sébastien __________________ DBA SQLServer, Oracle, Mysql, DB2, Postgresql
	00

24/02/2011, 10h55	#3
Phenol Membre à l'essai Cédric D. Développeur Web Inscription : mai 2004 Messages : 68 Détails du profil Informations personnelles : Nom : Cédric D. Âge : 28 Localisation : France Informations professionnelles : Activité : Développeur Web Informations forums : Inscription : mai 2004 Messages : 68 Points : 24 Points : 24	Tout d'abord merci pour votre réponse. Pour répondre à votre question : Oui, le script Shell télécharge le .sql avant de l'exécuter en local.
	00

24/02/2011, 11h14	#4
patic Membre confirmé Inscription : novembre 2007 Messages : 134 Détails du profil Informations forums : Inscription : novembre 2007 Messages : 134 Points : 213 Points : 213	On s'est mal compris, pour trouver l'origine du problème, il faudrait tester manuellement, sans utiliser le script automatique déjà fait. Vous téléchargez manuellement le fichier .sql sur le serveur puis vous ouvrez un shell à distance, lancez une session mysql et exécutez le script. Si ce dernier point met toujours 20 minutes, vous aurez déjà identifié la source du problème. En gros il faut découper les tâches du script une à une, jusqu'à tomber sur le problème.
	00

24/02/2011, 11h31	#5
Phenol Membre à l'essai Cédric D. Développeur Web Inscription : mai 2004 Messages : 68 Détails du profil Informations personnelles : Nom : Cédric D. Âge : 28 Localisation : France Informations professionnelles : Activité : Développeur Web Informations forums : Inscription : mai 2004 Messages : 68 Points : 24 Points : 24	Le script Shell ne fait qu'un "mysql .......... < data.sql". J'ai testé directement la commande dans le Shell avec le même résultat. J'espère répondre concrètement à votre question et l'avoir bien comprise. Merci encore.
	00

24/02/2011, 17h18	#9
kedare Membre extrêmement actif Mathieu Administrateur systèmes et réseaux Inscription : juillet 2005 Messages : 1 476 Détails du profil Informations personnelles : Nom : Mathieu Localisation : France Informations professionnelles : Activité : Administrateur systèmes et réseaux Informations forums : Inscription : juillet 2005 Messages : 1 476 Points : 1 260 Points : 1 260	Tu fais bien tout dans une seule transaction ? Si c'est pas le cas il y a un commit a chaque insert donc c'est normal que ca soit lent...
	00

25/02/2011, 10h00	#11
patic Membre confirmé Inscription : novembre 2007 Messages : 134 Détails du profil Informations forums : Inscription : novembre 2007 Messages : 134 Points : 213 Points : 213	configuration différente ? Bonjour, A mon avis, si le test met 1 minute sur une simple machine tournant sous windows comparé à 20 minutes sur un serveur sous linux je suppose que c'est que vous n'avez pas la même configuration entre les deux machines, sous windows mysql est bien plus lent même avec la 5.5. Voir les contraintes comme les clés étrangères des tables en innodb, les triggers, les index aussi. Avez vous essayé avec un ETL du type de Pentaho Kettle (à condition que vous ayez un accès distant à la base), c'est ultra simple dans des cas d'import sans modification comme ici ? Sinon, découpez votre script .sql pour voir quelle partie est la source d'étranglement.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email