C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere
servant à vérifier que l'enregistrement n'existe pas déjà) ...
Pour le coup, mon mysqld se met à gonfler indéfiniement en mémoire et
pete un plomb...
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les
requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de
RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et
certainement performant ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ludo06
Pif wrote:
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere servant à vérifier que l'enregistrement n'existe pas déjà) ...
Pour le coup, mon mysqld se met à gonfler indéfiniement en mémoire et pete un plomb...
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et certainement performant ?
Merci ! Je ne sais pas si c'est applicable a ton environnement mais tu ne peux
pas bloquer la ou les tables pendant que tu fais ta selection/insertion et passer tes requetes en plusieurs fois (1000 par 1000 par exemple) ?
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere
servant à vérifier que l'enregistrement n'existe pas déjà) ...
Pour le coup, mon mysqld se met à gonfler indéfiniement en mémoire et
pete un plomb...
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les
requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de
RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et
certainement performant ?
Merci !
Je ne sais pas si c'est applicable a ton environnement mais tu ne peux
pas bloquer la ou les tables pendant que tu fais ta selection/insertion
et passer tes requetes en plusieurs fois (1000 par 1000 par exemple) ?
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere servant à vérifier que l'enregistrement n'existe pas déjà) ...
Pour le coup, mon mysqld se met à gonfler indéfiniement en mémoire et pete un plomb...
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et certainement performant ?
Merci ! Je ne sais pas si c'est applicable a ton environnement mais tu ne peux
pas bloquer la ou les tables pendant que tu fais ta selection/insertion et passer tes requetes en plusieurs fois (1000 par 1000 par exemple) ?
le problème c'est que mon programme java est trop rapide, tu coup, je pense que JDBC et MySQL essayent tous deux de mettre dans une file les requetes et de s'exécuter... au lieu de bloquer le processus appelant... .
ce que j'aimerais, c'est que la BD limite la rapidité de l'appelant ... chacun gere un cache que j'aimerais limiter...
mais c'est bizare, car meme avec un high priority ca ne marche pas ... pourtant logiquement, mes select on besoin du résultat avant que la suite ne s'exécute... par conséquent, il gere carrément une vue de ma table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Pif wrote:
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere servant à vérifier que l'enregistrement n'existe pas déjà) ...
Pour le coup, mon mysqld se met à gonfler indéfiniement en mémoire et pete un plomb...
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et certainement performant ?
Merci !
Je ne sais pas si c'est applicable a ton environnement mais tu ne peux pas bloquer la ou les tables pendant que tu fais ta selection/insertion et passer tes requetes en plusieurs fois (1000 par 1000 par exemple) ?
le problème c'est que mon programme java est trop rapide, tu coup, je
pense que JDBC et MySQL essayent tous deux de mettre dans une file les
requetes et de s'exécuter... au lieu de bloquer le processus appelant... .
ce que j'aimerais, c'est que la BD limite la rapidité de l'appelant ...
chacun gere un cache que j'aimerais limiter...
mais c'est bizare, car meme avec un high priority ca ne marche pas ...
pourtant logiquement, mes select on besoin du résultat avant que la
suite ne s'exécute... par conséquent, il gere carrément une vue de ma
table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X
fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Pif wrote:
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere
servant à vérifier que l'enregistrement n'existe pas déjà) ...
Pour le coup, mon mysqld se met à gonfler indéfiniement en mémoire et
pete un plomb...
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute
les requete genre 1000 par 1000 et pas de façon abusive (plus de 800
Mo de RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus
soft et certainement performant ?
Merci !
Je ne sais pas si c'est applicable a ton environnement mais tu ne peux
pas bloquer la ou les tables pendant que tu fais ta selection/insertion
et passer tes requetes en plusieurs fois (1000 par 1000 par exemple) ?
le problème c'est que mon programme java est trop rapide, tu coup, je pense que JDBC et MySQL essayent tous deux de mettre dans une file les requetes et de s'exécuter... au lieu de bloquer le processus appelant... .
ce que j'aimerais, c'est que la BD limite la rapidité de l'appelant ... chacun gere un cache que j'aimerais limiter...
mais c'est bizare, car meme avec un high priority ca ne marche pas ... pourtant logiquement, mes select on besoin du résultat avant que la suite ne s'exécute... par conséquent, il gere carrément une vue de ma table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Pif wrote:
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere servant à vérifier que l'enregistrement n'existe pas déjà) ...
Pour le coup, mon mysqld se met à gonfler indéfiniement en mémoire et pete un plomb...
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et certainement performant ?
Merci !
Je ne sais pas si c'est applicable a ton environnement mais tu ne peux pas bloquer la ou les tables pendant que tu fais ta selection/insertion et passer tes requetes en plusieurs fois (1000 par 1000 par exemple) ?
SL
Pif wrote:
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere servant à vérifier que l'enregistrement n'existe pas déjà) ...
normalement c'est le job du SGBD ca,
si tu veux avoir des enregistrements uniques il FAUT les declarer comme tels au niveau de MySQL (unique, primary key...)
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et certainement performant ?
Merci !
jette un oeuil sur les preparedStatement, ca pourrait t'interesser...
en esperant faire avancer le schimiliblik, tchao,
-- SL
Pif wrote:
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere
servant à vérifier que l'enregistrement n'existe pas déjà) ...
normalement c'est le job du SGBD ca,
si tu veux avoir des enregistrements uniques il FAUT les declarer comme
tels au niveau de MySQL (unique, primary key...)
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les
requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de
RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et
certainement performant ?
Merci !
jette un oeuil sur les preparedStatement, ca pourrait t'interesser...
C'est peut etre pas le forum le plus adapté, mais voici mon problème :
Je fais une grande série de requetes SELECT puis INSERT (la premiere servant à vérifier que l'enregistrement n'existe pas déjà) ...
normalement c'est le job du SGBD ca,
si tu veux avoir des enregistrements uniques il FAUT les declarer comme tels au niveau de MySQL (unique, primary key...)
J'aimerais savoir s'il y a un moyen de faire en sorte qu'il exécute les requete genre 1000 par 1000 et pas de façon abusive (plus de 800 Mo de RAM) ... il y a le HIGH PRIORITY, mais y'a pas un moyen plus soft et certainement performant ?
Merci !
jette un oeuil sur les preparedStatement, ca pourrait t'interesser...
en esperant faire avancer le schimiliblik, tchao,
-- SL
Christophe Tela
mais c'est bizare, car meme avec un high priority ca ne marche pas ... pourtant logiquement, mes select on besoin du résultat avant que la suite ne s'exécute... par conséquent, il gere carrément une vue de ma table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Tu serais pas dans une transaction par hasard ? Je ne connais pas MySQL, mais dans la plupart des bases de données, il faut faire un commit() de temps en temps pour "purger" la transaction, lorque tu fais des grosses insertions de données.
mais c'est bizare, car meme avec un high priority ca ne marche pas ...
pourtant logiquement, mes select on besoin du résultat avant que la
suite ne s'exécute... par conséquent, il gere carrément une vue de ma
table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X
fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Tu serais pas dans une transaction par hasard ? Je ne connais pas MySQL,
mais dans la plupart des bases de données, il faut faire un commit() de
temps en temps pour "purger" la transaction, lorque tu fais des grosses
insertions de données.
mais c'est bizare, car meme avec un high priority ca ne marche pas ... pourtant logiquement, mes select on besoin du résultat avant que la suite ne s'exécute... par conséquent, il gere carrément une vue de ma table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Tu serais pas dans une transaction par hasard ? Je ne connais pas MySQL, mais dans la plupart des bases de données, il faut faire un commit() de temps en temps pour "purger" la transaction, lorque tu fais des grosses insertions de données.
Pif
j'ai en transaction autocommit() ca posait en effet problème...
depuis que j'ai enlevé cette option et que je fais moi meme les commits, c'est un peu mieux, mais ca explosre quand meme ( plus tard ... )
des idées pour controler le cache de MySQL ?
merci !
Christophe Tela wrote:
mais c'est bizare, car meme avec un high priority ca ne marche pas ... pourtant logiquement, mes select on besoin du résultat avant que la suite ne s'exécute... par conséquent, il gere carrément une vue de ma table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Tu serais pas dans une transaction par hasard ? Je ne connais pas MySQL, mais dans la plupart des bases de données, il faut faire un commit() de temps en temps pour "purger" la transaction, lorque tu fais des grosses insertions de données.
j'ai en transaction autocommit()
ca posait en effet problème...
depuis que j'ai enlevé cette option et que je fais moi meme les commits,
c'est un peu mieux, mais ca explosre quand meme ( plus tard ... )
des idées pour controler le cache de MySQL ?
merci !
Christophe Tela wrote:
mais c'est bizare, car meme avec un high priority ca ne marche pas ...
pourtant logiquement, mes select on besoin du résultat avant que la
suite ne s'exécute... par conséquent, il gere carrément une vue de ma
table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X
fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Tu serais pas dans une transaction par hasard ? Je ne connais pas MySQL,
mais dans la plupart des bases de données, il faut faire un commit() de
temps en temps pour "purger" la transaction, lorque tu fais des grosses
insertions de données.
j'ai en transaction autocommit() ca posait en effet problème...
depuis que j'ai enlevé cette option et que je fais moi meme les commits, c'est un peu mieux, mais ca explosre quand meme ( plus tard ... )
des idées pour controler le cache de MySQL ?
merci !
Christophe Tela wrote:
mais c'est bizare, car meme avec un high priority ca ne marche pas ... pourtant logiquement, mes select on besoin du résultat avant que la suite ne s'exécute... par conséquent, il gere carrément une vue de ma table en mémoire ou alors j'ai rien compris, j'ai pourtant vérifié X fois que j'avais pas un ResultSet ou un Statement qui n'était pas fermé !?
Tu serais pas dans une transaction par hasard ? Je ne connais pas MySQL, mais dans la plupart des bases de données, il faut faire un commit() de temps en temps pour "purger" la transaction, lorque tu fais des grosses insertions de données.
Pif
normalement c'est le job du SGBD ca, si tu veux avoir des enregistrements uniques il FAUT les declarer comme tels au niveau de MySQL (unique, primary key...)
je veux compter la fréquence d'un mot, ou plus généralement d'une chaine de caractères dans un texte, du coup, par la suite un identifiant numérique est bien plus intéressant à mémoriser... mais du coup je suis obliger de jouer sur des select pour récupérer l'identifiant associé à un mot... je chargerais bien tout en mémoire, mais j'ai plusieurs millions de termes dans la base...
la rapidité de cette instruction est une question, mais ca n'empeche que le problème reste le meme, et ne ferait qu'empirer en rajoutant des contraintes d'intégrité : une longue série de INSERT provoque un cache qui est trop important, je veux pouvoir limiter ce cache et bloquer le processus appelant..
jette un oeuil sur les preparedStatement, ca pourrait t'interesser...
déjà fait ! merci !
en esperant faire avancer le schimiliblik, tchao,
normalement c'est le job du SGBD ca,
si tu veux avoir des enregistrements uniques il FAUT les declarer comme
tels au niveau de MySQL (unique, primary key...)
je veux compter la fréquence d'un mot, ou plus généralement d'une chaine
de caractères dans un texte, du coup, par la suite un identifiant
numérique est bien plus intéressant à mémoriser... mais du coup je suis
obliger de jouer sur des select pour récupérer l'identifiant associé à
un mot... je chargerais bien tout en mémoire, mais j'ai plusieurs
millions de termes dans la base...
la rapidité de cette instruction est une question, mais ca n'empeche que
le problème reste le meme, et ne ferait qu'empirer en rajoutant des
contraintes d'intégrité : une longue série de INSERT provoque un cache
qui est trop important, je veux pouvoir limiter ce cache et bloquer le
processus appelant..
jette un oeuil sur les preparedStatement, ca pourrait t'interesser...
normalement c'est le job du SGBD ca, si tu veux avoir des enregistrements uniques il FAUT les declarer comme tels au niveau de MySQL (unique, primary key...)
je veux compter la fréquence d'un mot, ou plus généralement d'une chaine de caractères dans un texte, du coup, par la suite un identifiant numérique est bien plus intéressant à mémoriser... mais du coup je suis obliger de jouer sur des select pour récupérer l'identifiant associé à un mot... je chargerais bien tout en mémoire, mais j'ai plusieurs millions de termes dans la base...
la rapidité de cette instruction est une question, mais ca n'empeche que le problème reste le meme, et ne ferait qu'empirer en rajoutant des contraintes d'intégrité : une longue série de INSERT provoque un cache qui est trop important, je veux pouvoir limiter ce cache et bloquer le processus appelant..
jette un oeuil sur les preparedStatement, ca pourrait t'interesser...
déjà fait ! merci !
en esperant faire avancer le schimiliblik, tchao,
Sebastien Mathy
Pif wrote:
j'ai en transaction autocommit() ca posait en effet problème...
depuis que j'ai enlevé cette option et que je fais moi meme les commits, c'est un peu mieux, mais ca explosre quand meme ( plus tard ... )
des idées pour controler le cache de MySQL ?
Il faut aller voir dans le fichier my.cnf
Pif wrote:
j'ai en transaction autocommit()
ca posait en effet problème...
depuis que j'ai enlevé cette option et que je fais moi meme les commits,
c'est un peu mieux, mais ca explosre quand meme ( plus tard ... )
sur la doc de mysql sur leur propre site ils sont avares en détails à ce sujet !
Christophe Tela
sur la doc de mysql sur leur propre site ils sont avares en détails à ce sujet ! C'est vrai. Par contre, tu peux regarder dans ton installation, tu dois
avoir un fichier nommé my-huge.cnf qui à travers ses commentaires et ses exemples doit pouvoir te permettre de tenter des solutions.
sur la doc de mysql sur leur propre site ils sont avares en détails à ce
sujet !
C'est vrai. Par contre, tu peux regarder dans ton installation, tu dois
avoir un fichier nommé my-huge.cnf qui à travers ses commentaires et ses
exemples doit pouvoir te permettre de tenter des solutions.
sur la doc de mysql sur leur propre site ils sont avares en détails à ce sujet ! C'est vrai. Par contre, tu peux regarder dans ton installation, tu dois
avoir un fichier nommé my-huge.cnf qui à travers ses commentaires et ses exemples doit pouvoir te permettre de tenter des solutions.
