Dans l'application toute connexion sql fermer correctement, Aussi lorsque l'utilisateur se déconnecter sa connexion fermer encore la mémoire de processus sql augmenter dans la RAM et après un certain temps Application ralentir.lorsque plusieurs utilisateurs se connectent, puis après un certain temps ASP.Net C# Application obtiennent lent
Utilisez-vous les fournisseurs SqlMembership par défaut? Ou avez-vous créé quelque chose par vous-même? Si c'est l'option 2, je vous suggère de commencer le profilage de votre code et de tester le stress. Vous pouvez également utiliser SQL Profiler pour voir ce qui est envoyé à la base de données. Vous pouvez également utiliser sp_lock ou le nouveau sys.dm_tran_lock pour voir s'il y a un verrouillage de ligne quelque part.
Existe-t-il d'autres processus s'exécutant sur le même serveur, ce qui peut empêcher SQL Server d'obtenir suffisamment de RAM pour fonctionner correctement? Sysinternals ont de bons outils pour les vérifier.
oui nous utilisons les fournisseurs SqlMembership par défaut, aussi SQL Profiler pour voir ce qui est envoyé à la base de données et son look tout va bien. aussi sur l'exploration problème nous remarquons que la mémoire dans l'utilisation de RAM par le serveur SQL ne libère pas et donc ralentir l'application. Mais nous ne savons pas pourquoi cela arrive et comment surmonter cela. – Shrik
Cette question est vague. Parlez-vous des connexions d'application utilisant un fournisseur basé sur SQL Server, ou des connexions au serveur de base de données lui-même (via Management Studio ou quelque chose de similaire)?
Pas exactement, en fait, nous ne pouvons pas détecter le problème avec la connexion à la base de données ou ales. Pour une connexion correcte avec le serveur sql, nous mettons en place un pool de connexion pour chaque utilisateur qui établit une connexion séparée à partir du pool de connexions et ferme la session tout en se déconnectant. – Shrik
@Shrik: SQL Server est un utilisateur de mémoire de classe A - par conception. Par défaut, il est configuré pour prendre toute la mémoire qu'il peut récupérer. Il va effectivement déplacer les données du disque dans la mémoire physique - de sorte que l'accès futur de ces données sera beaucoup plus rapide.
Lorsque le service du serveur sql se trouve dans sa propre boîte, ce n'est pas vraiment un problème. Mais lorsque d'autres applications tentent de s'exécuter sur cette boîte, de sérieux goulots d'étranglement se produisent. Ce scénario est ce que je lis entre les lignes dans votre discussion. Si vos applications sont en cours d'exécution sur la boîte SQL et que la performance souffre chaque fois que sql server commence à «faire son truc», soit: Limiter le # de mémoire sql disponible (pas si bon) ou donner serveur SQL sa propre boîte.
Si votre serveur sql est déjà dans sa propre boîte, la première place que je ferais pour différencier l'origine de la 'lenteur' est d'exécuter une requête/instruction 'lente' typique - à partir de l'application & de SQL Serveur, via SSMS. Donc, pas très high tech, je sais, mais tellement très révélateur. Si la requête est rapide et agile via SSMS, laissez le SGBD seul et concentrez-vous sur l'application et les couches physiques/logicielles réseau. Si la requête n'est pas si bonne, regardez @ SQL Server.
S'il s'agit d'un serveur sql, mon problème est que vous avez une requête peu performante, avec la façon dont vous la décrivez, s'aggrave à mesure que l'application progresse, mais s'améliore après le redémarrage de l'application. (qui btw, si un redémarrage de l'application, mais pas Sql Server 'corrige' le problème, il s'agit probablement d'un problème d'application).
Et comme toujours, les journaux sont votre ami! Voyez ce que SQL Server dit. Par exemple, votre application peut faire un usage intensif de SQL CLR. Quand un assemblage est appelé pour la première fois, c'est SLOOOOW. Deuxième fois, RAPIDE. SQL Server gère ses espaces de mémoire, et parfois, il va pousser les assemblys de mémoire. La prochaine fois que l'assemblage est appelé - devinez quelle est l'expérience de l'utilisateur? SLOOOOOW. Devinez où l'on peut voir si SQL Server pousse les assemblys de la mémoire?
Essayons une partie de ce dépannage, vous postez les résultats et je parie que quelqu'un peut vous aider un peu plus. Rappelez-vous: TOUT registre, message d'erreur ou données concrètes que vous pouvez nous donner nous aidera vraiment à répondre à vos questions.
Bonne chance!
Mauvaise question.Vous avez probablement des problèmes sur le code de vos utilisateurs authentifiés – Aristos
Je pense que vous ne comprenez pas le problème clairement – Shrik