Discussion :

[MecaNico]

Bonjour,

je développe actuellement un programme en C# qui travaille avec une base de données sous SQL server 2000.

Mon SQL server 2000 est correctement configuré pour tirer parti de mes 2 processeurs.

Dans mon programme j'ai une liste de 200 000 strings qui correspondent à des requêtes SQL dans valeur de retour que je dois faire executer dans ma BD quelque soit leurs ordres de traitements.

en ouvrant une connexion et en balançant séquentiellement les requetes apr. un exécute non-query je m'aperçois que SQL Server ne tire parti que d'un seul processeur.

J'avais pensé à créer plusieurs threads qui ouvrait plusieurs connections mais avant de faire cela je voudrais être sur mon problème vienne du fait que SQL server n'attribue qu'un seul processeur à une seule connexion.


Quelles seraient vos idées pour que je puisse balancer mes 200 000 requêtes SQL UPDATE en passant par du code C# et de la façon la plus optimisé possible ?

Merci

[Piotrek]

Salut

Pour des operations d'insertions basiques, c'est rarement le processeur du serveur SQL qui est un goulot d'etranglement, c'est presque toujours le sous systeme disque. Si tu as un array de 8 disques scsi en raid 10 et un processeur poussiereux, il se pourrait que le processeur pose probleme.

Dans tous les cas il faut, pour que tu puisse optimiser, savoir ou se trouve le goulot d'etranglement: reseau, vitesse d'emission des requetes de la part du client, vitesse de traitement des requetes par le serveur... Et tout depend de ton environnement materiel specifique. Il n'y a pas de reponse toute faite, et la solution c'est d'etudier finement les etudier les compteurs de SQL Server et d'ADO.NET sur le client

Le premier lien donne deja un bon conseil pour des insert en masse:

So which option is best? In all cases, you will still be producing a lot of disk I/O. There is no way to get around this if you deal with 1,000,000 rows. But by using one or just a few transactions, you reduce the number of log flushes significantly, and disk I/O is reduced significantly, which helps to reduce the I/O bottleneck, boosting performance.

Enfin sur le client, l'erreur bateau c'est de faire des concatenations de strings sans StringBuilder

[MecaNico]

merci pour ta réponse,

alors pour le problème qui était qu'un seul processeur n'était utilisé j'ai résolu le problème en passant une de mes bases de données sur un serveur SQL 2005 et en envoyant les requête d'UPDATE et INSERT en asynchrone grace à la méthode beginExecuteNonQuery.

Ca me fais déja gagné pas mal de temps.


Mais j'ai regardé tes liens et je suis sur que je vais encore gagner de precieux cycles CPU.

Si d'autres personnes ont des astuces je suis preneur car j'ai encore beaucoup d'optimisation à faire pour que le délai soit correct

[zeavan]

1)utiliser des index.

2) ensuite une erreur difficile a percevoir :
verifie si dans tes stored procedures si tu utilises des functions dans des group by et bien les functions a ce moment la casse l'indexation.
donc il te faut faire la chose suivante

set uneVariable = MaFunction(...);

puis groupby uneVariable.

il y en encore bcp mais celui dont je te parle n'est pas evident a deceler et pas forcement tres connu. (en tout cas moi a une epoque cea m'avais bien embeter).