كيفية الكشف عن SqlServer اتصال التسريبات في ASP.net التطبيقات ؟

Question

أنا حاليا أقوم ببعض واجهة المستخدم الرسومية اختبار على ASP.net 2.0 تطبيق.RDBMS هو SQL Server 2005.المضيف هو Win Server 2003 / IIS 6.0.

ليس لدي شفرة المصدر من التطبيق لأنه كان مبرمجا من قبل شركة خارجية من عدم الإفراج عن المدونة.

لقد لاحظت أن التطبيق يؤدي بشكل جيد عندما كنت إعادة تشغيل IIS ولكن بعد بعض التجارب ، بعد أن كنت قد فتحت و أغلقت المتصفح الخاص بي لبضع ساعات, التطبيق يبدأ في الحصول على أبطأ وأبطأ.أنا أتساءل عما إذا كان هذا السلوك بسبب سوء إغلاق اتصال الممارسة من المبرمجين :وأنا الشك مفتوح تسرب اتصال على قاعدة البيانات هنا.

أعتقد .صافي جامع القمامة في نهاية المطاف قريبة منها ولكن...هذا يمكن أن يستغرق بعض الوقت ؟

لدي SQL Server إدارة Studio و لاحظت من مراقبة النشاط أن هناك عدد قليل جدا من الاتصالات فتحت على قاعدة البيانات.

من كل ما قيل أعلاه ، وإليك بعض الأسئلة المتعلقة السؤال الرئيسي :

1. هل هناك أي طريقة لمعرفة في SQL Server 2005 إذا اتصالات فتح لأنهم ينتظرون تستخدم في تجمع الاتصال أو إذا انهم مفتوحة لأنها تستخدم من قبل التطبيق ؟

2. لا somone أعرف من جيد على الانترنت/ورقة الموارد أين يمكنني أن تعلم كيفية استخدام الأداء عدادات أو أي نوع آخر من الأدوات للمساعدة في تعقب هذه النوع من القضايا ؟

3. إذا عدادات أداء أفضل الحل ما هي المتغيرات التي أنا يجب أن تشاهد ؟

Answer 1

يمكنك دائما التحقق من سلاسل اتصال من شبكة الإنترنت.التكوين (خاصة إذا كان لديهم اتصال تجميع تفعيلها ، إذا كان لديهم أي اتصال حدود تمكين).

أيضا, إذا كنت تستخدم IIS 6 ، يمكنك تعيين تطبيق ويب لاستخدام تطبيق منفصل وحمام سباحة تعيين خيار آخر لإعادة تدوير الذاكرة والعمليات.

عن عدادات الأداء التي يمكن أن تحقق كم جامع القمامة التوالي ، مقدار الذاكرة يستخدم التطبيق ، إلخ.

إذا كان لديك حق الوصول إلى ملقم sql ، يمكن رصد اتصالات من التطبيق الخاص بك (هناك عدادات الأداء المحددة لكل تثبيت مثيل SQL Server).

كانت هناك بعض المواد في MSDN مجلة.أيضا يمكن استخدام SOS التصحيح المكتبة أن نعلق على تطبيق عملية التحقق من ذلك يدويا.

و إذا لم يكن لديك رمز المصدر ، في محاولة لاستخدام عاكس للحصول على مصادر التطبيق (أنها ستكون مفيدة جدا من أجل التصحيح)

@في وقت لاحق تحرير:هل يمكن أن تحقق هذه السؤال هنا stackoverflow.com أيضا

Answer 2

وجدت هذا الموضوع في البحث عن مشكلة مماثلة.لقد جاء مع sql التالية باعتبارها وسيلة جيدة لتصحيح راشح اتصالات في SQL Server:

SELECT S.spid, login_time, last_batch, status, hostname, program_name, cmd,
(
      select text from sys.dm_exec_sql_text(S.sql_handle)
) as last_sql
FROM sys.sysprocesses S
where dbid > 0
and DB_NAME(dbid) = '<my_database_name>'
and loginname = '<my_application_login>'
order by last_batch asc

ما هذا يعطيك كل الاتصالات المفتوحة على بيانات معينة و تسجيل الدخول ، جنبا إلى جنب مع آخر sql تنفيذها في هذا الصدد ، , بحسب الوقت الذي sql التي تم تنفيذها.

بسبب تجمع الاتصال لا يمكنك الاعتماد فقط على حقيقة أن هناك الكثير من الاتصالات التسكع أن أقول لك أن لديك اتصال تسرب بسبب تجمع الاتصال سوف تبقى الاتصالات في جميع أنحاء حتى لو كانت مغلقة بشكل صحيح من القانون.ومع ذلك, إذا كان لديك اتصال تسرب, ما سوف نراه هو أن بعض الاتصالات تصبح "المجمدة"—أنها سوف تظهر في الاستعلام أعلاه و "last_batch" الطابع الزمني لن يتغير أبدا.الاتصالات الأخرى أيضا تسكع ، ولكن في كل مرة جديدة sql تشغيل عليهم ، "last_batch" الطابع الزمني يحصل على تحديث.وبالتالي فإن التأثير هو أن تجميد الاتصالات سوف تطفو إلى أعلى من هذا الاستعلام.

إذا كان لديك التعليمات البرمجية المصدر التطبيق في السؤال ، والحقيقة أن هذا يعطيك الماضي sql أعدم على اليتامى الصدد هو قيمة للغاية من أجل التصحيح.

Answer 3

أنا واجهت هذه المشكلة وجدت SQL Server منشئ ملفات التعريف أن يكون أداة عظيمة, لقد رصد الموقع في اختبار قصيرة المدى و لاحظت الكثير من الاتصالات التي يجري إنشاؤها (sp_who) التي لم تكن استخدامها من قبل تجمع الاتصال ، حتى لقد فتحت SQL Server منشئ ملفات التعريف ثم تحقق مما إذا كان كل شيء يدعو إلى SP مصنوعة من القانون تليها "sp_reset_connection" المكالمة.إن الدعوة ليست هناك قبل بدء دفعة جديدة أنت فقط تفتقر إلى أول اتصال.

Answer 4

MSDN إشارة عن (ADO.NET عدادات الأداء) واضحة جدا حول ما يمكن أن تبحث عنه عند التنميط التطبيق.يمكنك مراقبة عدادات باستخدام perfmon تطبيق المضمنة في نظام التشغيل Windows.

بخلاف ذلك, أنا أقترح التعلم عن ADO.NET تجمع الاتصال.إذا كنت تشك حقا خطأ في التعليمات البرمجية الخاصة بهم ، يمكنك أن تأخذ نظرة على ذلك باستخدام الأحمر بوابة عاكس (مجانا الآن) الذي يفكك MSIL إلى C#.

Answer 5

وأود أن تبدأ من خلال النظر في اتصالات يبحث في نشاط مرات ، ومعرفة ما إذا كان يمكنك العثور على البنود التي هي إبقاء الاتصالات مفتوحة.

وأود أن أقول أنه إذا فكر الحل هو إعادة تشغيل IIS ، قد تنظر أيضا في استخدام الذاكرة من التطبيق لمعرفة ما إذا كان هناك تسرب الذاكرة أو شيء هناك والتي يؤدي وجودها إلى النمو.

إذا فتح اتصالات كانت قضية ، في مراقبة النشاط سوف تشاهد عدد كبير جدا من الاتصالات مع أي نشاط.

على عدادات الأداء قد تبدأ في النظر في "ملقم SQL :الإحصائيات العامة" كائن الأداء.

Answer 6

تود Denlinger كتب رائعة فئة http://www.codeproject.com/KB/database/connectionmonitor.aspx والتي الساعات Sql Server اتصالات وتقارير عن تلك التي لم يتم التخلص منها بشكل صحيح خلال فترة من الزمن.سلك إلى موقع الويب الخاص بك ، سوف تتيح لك معرفة عندما يكون هناك تسرب.