PDA

View Full Version : مشكل هنگي SQL و Lock page in memory ?



die_soft2003
سه شنبه 24 خرداد 1390, 13:08 عصر
مشكل هنگي SQL و Lock page in memory ?


به نام هستي بخش
سلام
من يك سرور خوب از hp دارم كه 32 گيگ رم داره !
روش ويندوز سرور 2008 R2 x64 نصبه به همراه يك SQl 2008 x64 با update هاش.
sql رو تيونيگ كردم يك سري تغييرات زير را دادم :
1- Usw AWE : از قبل فعال بود من دستش نزدم ؟ مگه براي ويندوز هاي 32بيتي نيست ؟
2- Min memory : روي 15% از كل رم تنظيم كردم
3- Max Memory : روي 85% رم.
4- Min memory per query : چون 64 بيتي بود روي 6144 تنظيم كردم.
5- Boost SQL Server Priority را فعال كردم
6- Maxmimum Worker thread را روي 2048 گذاشتم چون هم 64بيتي بود هم توي برنامه هامون از thread استفاده كرديم.
7- Cost threshold for parallelism را هم از 5 به 15 تغيير دادم
*. اكثر اين تنظيمات را از روي كتاب ماكروسافت براي تيونينگ كردن SQL انجام دادم. *
باقي تنظيمات كه روي ويندوز سرور بود نشد درست دست بزنم مانند Virtual memory خوب خواستم اينو تغيير بدم ديدم خود ويندوز زده به صورت خودكار روي همه درايو ها فعال هست !! منم گفتم شايد اين بهتر باشه نظر شما چيه ؟
تنظيم Lock page in memory نتونستم تنظيم كنم !!!
چون ما از SQL به صورت Remot استفاده مي كنيم من با چه يوزري اونجا اضافه كنم ؟ آيا گروه Administrators كافيه ؟‌
تنظيماتي كه من انجام دادم ايرادي ندارن ؟‌
با اين تنظيماتي كه انجام دادم بازم هنگي دارم ؟!!! كندي دارم ! يا بايد Reset كنم يا Stop/Start !!!
برنامه هامونم با .net نوشتيم و هميشه هم مراقب بوديم كه Connection باز الكي نداشته باشيم و ... !
ايراد كار كجاست ؟‌
اساتيد گرامي يه كمكي به من بي نوا بكنن !!!

حمیدرضاصادقیان
سه شنبه 24 خرداد 1390, 14:03 عصر
سلام.
دوست عزیز این مواردی که فرمودید خوب خوبه.
ولی بیشتر بحث هنگ کردن ، کند شدن ها ، برمیگرده به ساختار جداول شما ، نوع کوئری های نوشته شده ، نوع ایندکسهای استفاده شده .
شما برای اینکه دقیقتر متوجه بشید یکبار با SQL PRofiler عملیات سرور رو تحت نظر بگیرید.بعد در اینجا باید ببینید چه کوئری هایی بیشتر از همه در حال اجرا هستند. میزان رم مصرفی اونها چقدر هست؟
تعداد Lock های کوئری ها چقدر است؟
تا بعد بریم سر تستهای بعدی.

die_soft2003
سه شنبه 24 خرداد 1390, 14:12 عصر
به نام هستي بخش
سلام

ممنون دستت درد نكنه ، اما از نظر كوئري نويسي و غيره زياد روش كار شده كه كم هزينه و كم بار باشه ! يعني چك كرديم كه و تا اونجايي كه شده بهينه سازي كرديم. من با Profiler كار نكردم يك مثال ميتوني برام بزني كه چكار كنم كه و نتيجشو بذارم ببنيد ؟
راستي درمورد Lock page in memory توضيحي نداري برام بدي ؟ با چه User يا گروه راهش بندازم ؟‌ اصلا نياز هست ؟

Touska
شنبه 28 خرداد 1390, 09:57 صبح
من با Profiler كار نكردم

پس چرا میگین کم هزینه و کم باره ، چطوری اینو تست کردید.

برای استفاده از این لینک کمک بگیرید : http://msdn.microsoft.com/en-us/library/ff650699.aspx
و راهنمای فارسی : http://www.dotnettips.info/2010/08/sql-wcf-ria-services.html

موفق باشید :)

die_soft2003
یک شنبه 29 خرداد 1390, 08:47 صبح
به نام هست يخبش
سلام
بازم ممنون؛ برنامه نويسش من نيستم و ميدونم كه همكارام كه برنامه نويسش هستند روش خيلي كاركردن كه بار كمي داشته باشه و با Tools هاي خود SQL توابع و SP ها را چك كردن و هزينه هاي آن هارا حساب كردن؛ يه دليل ديگه اينه كه مشكل اصلي در اجراي برنامه نيست يعني مثلا اگر يك گزارش سنگيني با SQL گرفته ميشه به راحتي جواب ميده اما يك هفته درست كار ميكنه بعد يه بار 2روز درست كار ميكنه يه بار 1ماه درست كار ميكنه !!!
دارم ميرم دنبال Profiler ببينم چي ازش درميارم.(متاسفانه وقت ميخواد كه اينم خيلي كم دارم!!!)

AminSobati
جمعه 03 تیر 1390, 12:54 عصر
سلام دوست عزیزم،
تقریبا تمام موارد 1 تا 7 که عنوان کردین، غیر ضروری بوده. فرضا مورد اول، به 32bit مربوط میشه و در 64bit توسط SQL Server نادیده گرفته خواهد شد (Lock Page in Meory نیز)
همچنین وقتی سرور مختص به SQL Server هست و وظیفه دیگه ای مثل IIS یا DC و ... به عهده اش نیست، خود SQL Server با OS کاملا هماهنگ خواهند بود و هر کدوم که حافظه نیاز داشته باشند، دیگری براش آزاد میکنه.
Cost threshold رو به 5 دقیقه برگردونین.
و اما در مورد هنگی، به احتمال زیاد نداشتن اینکسهای بهینه باعث Table Scan میشه و دستورات ویرایشی Block خواهند شد. Profiler نقطه خوبی برای شروع هست. فرضا فیلتر کنین روی دستوراتی که Duration بیش از 5000 میلی ثانیه دارند. ببینین کدوم دستورات زمان زیادی صرف میکنند و بهینه سازی رو روی اونها متمرکز کنید