Discussion :

[Sidiart]

Bonjour,

j'espère poser ma question sur le bon forum, je n'ai pas trouvé de forum dédié à SQL Server CE.

Je développe depuis quelques temps une application Winform .NET hébergeant une base de donnée SQL Server Compact Edition 3.5 que j'adresse en Linq To SQL en C#.

Alors que cette application tourne parfaitement avec un faible nombre d'enregistrements j'observe une brusque montée de l'utilisation CPU quelques minutes après le lancement de l'application lorsque le fichier base de donnée dépasse les 10-12 Mo.
Cette brusque augmentation de l'occupation CPU se produit systématiquement 1 minute après le lancement de l'application sans qu'aucune manipulation ne soit faite sur l'IHM. Aucune autre thread ou boucle infinie n'est explicitement lancée par l'application pendant ce délai.

J'ai tenté plusieurs chose pour corriger le problème:
1- Vérification de l'intégrité de la base via SqlCeEngine.Verify
2- Compactage de la base via SqlCeEngine.Shrink

rien n'y fait...

Je soupçonne SQL Server CE de provoquer ce phénomène dans la mesure où la taille de la base à un lien direct avec l'utilisation de la CPU.
Je n'ai pas trouvé d'information sur un tâche qui serait exécutée en tâche de fond par SQL Server CE dans la documentation.

Je suis preneur de tout conseil, je sèche complètement ;-)

Merci d'avance !

[Pol63]

10Mo c'est ridicule sur un pc, ca ne vient pas de là
combien de lignes par table ? des requêtes exécutées souvent ? il y a des indexes sur les tables ? %age de cpu utilisé ?

[Sidiart]

C'est clair que ça fait pas grand chose 10Mo.

Je vais essayer de répondre à ta question:

- Jusqu'à 100000 lignes environs par table
- Requêtes peu voir pas exécutées en l'occurrence. Quand l'application se fige (CPU à 50% sur un Core2 Duo) aucune requête n'a été exécutée depuis plus d'une minute environ. Toutes terminées.
- Chacune des tables est munie d'une clé primaire.
- 50% de la CPU utilisée.

[Pol63]

à ma connaissance sql server CE n'a pas de processus associé, étant une base fichier
donc si ton appli monte en charge cpu je ne vois pas ce qui te ferais dire que c'est sql server ce la cause
de plus si tu es sûr de ne faire aucune requête à ce moment là ca voudrait dire que c'est impossible que ca soit sql server CE qui prenne la charge cpu, car avec une base fichier c'est seulement au moment de l'accès aux données que la base de données est en activité

[GuruuMeditation]

Un petit coup de profiler, histoire de voir si ça viens du code ou pas

[Sidiart]

Bonjour,

Merci pour vos retours.

Pour le profiler c'est une bonne idée mais il me semble que ce genre d'application m'aiderait à trouver une fuite mémoire ou à analyser la répartition du temps dans l'exécution de mes algorithmes, or ici rien n'est explicitement exécuté lorsque le figeage/pic CPU apparait. Je ne suis pas un expert sur ce genre d'outil, possible que je rate une fonction essentielle.

Concernant l'absence de processus SQL Server CE en tâche de fond, Pol83, c'est également ce qui apparait dans la documentation MSDN. De ce que j'ai lu, le seul processus pouvant se lancer automatiquement est le processus d'Autoshrink exécuté dés que la taille de la base franchit un trigger paramétrable dans les options du projet. Ce trigger est par défaut paramétré à 60Mo soit une taille très supérieures à ma base de 12Mo.

J'avance par contre à petit pas sur l'origine du problème. Le contenu de l'une des tables de ma base semble poser problème. En effet lorsque je vide cette table de l'ensemble de ses enregistrements plus de figeage ni de pic CPU. Je sais que c'est assez irrationnel au regard de ce que je dis dans la paragraphe précédent mais les faits sont particulièrement têtus..

La table incriminée contient au moment des faits 22000 entrées en gros.
Schéma de la table:
ID - Int
DateHour - DateTime
Type NVarchar(100)
Connexion_ID NVarchar(100)
DateHour_R - DateTime
Status - NVarchar(100)

Une idée ?

[Pol63]

http://stackoverflow.com/questions/2...multiple-users

indexes et profiling y sont cités
et les orm ne sont pas forcément réputé pour leurs performances et leurs optimisations, linq to sql étant le 1er des prémices d'orm en .net c'est peut etre une piste ...

d'ailleurs tu n'as pas répondu à toutes mes questions, notamment aux niveaux des indexes, parce que si tu demandes une ligne avec un where sur une colonne non indexée, c'est normale que le cpu monte en flèche sur une durée proportionnelle au nombre de ligne de la table

[Sidiart]

Le problème c'est qu'ici je ne cherche pas à optimiser une requête mais à comprendre ce qui fait qu'après 1 minute sans activité particulière (en tout cas aucune requête SQL en cours) mon application occupe 50% de la CPU et fige.

Je n'ai pas fait de démarche particulière pour indexer la table que je décris plus haut mais lorsque je consulte la table en question via l'application je n'ai pas de retard particulier avant le figeage.

[Pol63]

tu lances l'appli depuis vs, quand l'application fige tu clics sur pause et tu regardes où est l'exécution en cours, tu sauras quelle partie de ton code fait que ca fige

[Sidiart]

... brillante suggestion... Je viens mettre dans le mille avec ta méthode.

Je viens de m'apercevoir qu'un control hébergeant un champ date déclenche une callback lié à l'évolution de l'horaire 1 minute après le lancement de l'application et exécute en boucle une série de requêtes particulièrement gourmandes...

Des requêtes étaient donc bien lancées en tâche de fond. Désolé de vous avoir fait plancher sur le sujet et merci encore pour vos conseils !

[Pol63]

quand on expose son problème, il ne faut pas forcément essayer d'interpréter, car là tu pars directement à dire "sql server ce est lent au dessus de 10mo alors que je fais pas de requête"
alors que le problème ne vient pas d'sql server ce et tu fais des requetes ...

tu aurais juste dis "mon appli fige" on t'aurait directement dit de faire pause