فیلم گفتگو: مروری بر اهمیت Performance Tuning و Monitoring در نرمافزارهای سازمانی
زمان تقریبی مطالعه: 13 دقیقه
وقتی شما نرمافزاری را در سازمان بهرهبرداری میکنید، سرعت پاسخگویی نرمافزار به درخواستهای کاربران، به احتمال زیاد پس از چند ماه یا حداکثر چند سال استفاده از نرمافزار تغییر خواهد کرد و کندتر خواهد شد. یک سری عوامل وجود دارند که در این تغییر سرعت پاسخگویی تاثیرگذارند، مانند افزایش حجم پایگاه داده و یا تغییر رفتار کاربران در خصوص استفاده از نرمافزار. در این مواقع، راهکارها و ابزارهایی وجود دارند که به شما در رفع کندی و بهینهسازی عملکرد نرمافزار کمک میکنند که در میان آنها بهینهسازی عملکرد (Performance Tuning) و مانیتورینگ (Monitoring) پایگاه داده نرمافزار از اهمیت ویژهای برخوردار هستند.
در فیلم گفتگوی زیر، در خصوص این دو مبحث جذاب بحث و تبادل نظر شده که سرفصل مباحث و متن کامل گفتگو را میتوانید در ادامه مطالعه نمایید.
مشاهده فهرست مطالب
- 1 اهمیت Performance Tuning در نرمافزارها
- 2 عوامل تاثیرگذار بر لزوم Performance Tuning در نرمافزارها
- 3 آیا افزایش منابع اولین راهکار برای رفع کندی نرمافزارها است؟
- 4 اهمیت نصب و پیکربندی صحیح نرمافزارها در حفظ کارایی و سرعت پاسخگویی سیستم
- 5 اهمیت معماری توزیع یافته در کارایی و سرعت سیستم
- 6 اهمیت معماری Data warehouse در کارایی و سرعت سیستم
- 7 ابزارهای حوزه Performance Tuning و Monitoring
فیلم کامل گفتگو
محتوای متن کامل این گفتگو را از اینجا بخوانید :
+ خدمت همه عزیزانی که ما را تماشا میکنند عرض سلام دارم.
اهمیت Performance Tuning در نرمافزارها
( 00:23 تا 01:21 )
+ ما در این گفتگو سعی میکنیم در خصوص مبحث جذاب بهینهسازی عملکرد (Performance Tuning) صحبت بکنیم که در حوزهی نرم افزارهای اینترپرایز یک جایگاه خیلی ویژه ای داره و اهمیت بالایی رو در واقع برای خودش ایجاد میکنه.
+ خدمت آقای دکتر تجویدی هستیم از اساتید به نام در حوزه پایگاه داده هستیم سلام آقای دکتر امیدوارم که خیلی خوب باشید
– سلام ممنونم
+ خیلی خوشحالم که تشریف آوردید
– ممنون متشکرم من هم سلام عرض میکنم خدمت شما و همه بینندگان عزیز در خدمت شما هستیم
عوامل تاثیرگذار بر لزوم Performance Tuning در نرمافزارها
(01:21 تا 06:25)
+ سلامت باشید تشکر میکنم آقای دکتر ما تو حوزه نرم افزارهای اینترپرایز یک مطلبی به عنوان یک اصل در واقع وجود داره به نظر من که رفتار نرمافزار در ابتدای استفاده لزوما همان رفتاری نخواهد بود که بعد از چند ماه یا چند سال در واقع نرمافزار از خودش بروز میده یک سری عوامل وجود دارند که در این تغییر رفتار تاثیرگذار هستند در خصوص این عوامل میخواستم که از شما سوال بکنم اصولا چه عاملهایی میتونه در تغییر رفتار نرمافزار تو حوزه البته پرفورمنس منظورم هستش تاثیرگذار باشه و ما در حوزه تنظیم این پرفورمنس یا همون تیون کردنش با چه الگوهایی میتونیم وارد بشیم؟ آیا به ذات در واقع با یک بار تیون کردن یک نرمافزار از ابتدا میتونیم ما گارانتی بکنیم که نرمافزار بعد از چند ماه یا چند سال این خوب کار میکنه؟
– من سوال شما را اینجوری برداشت میکنم که خب یه نرمافزاری روز اولش نوشته شده تو سایت مشتری نصب شده و احتمالا سرعت مطلوبی هم داره به مرور زمان کندی داره ایجاد میشه خب این طبیعیه به هر حال به مرور زمان حجم دیتا اضافه میشه و حالا دیگه منابع درگیر میشن منابع سختافزاری و طبیعیه که سیستم کند بشه. خوب قطعا اینجاست که دیگه بحث تیونینگ مطرح میشه و فرمایش دومتون هم دقیقا درسته سیستم تیون شده توی مرحلهای با یه حجم دیتایی و با یه تغییری که حالا توی اون نقطه زمانی رخ داده ولی بعدش به مرور زمان دوباره ممکنه کندی ایجاد بشه بخاطر همین بهینهسازی عملکرد (Performance Tuning) رو میگن که یه سفره نه یه مقصد یعنی اینجوری نیست که بگن سیستم ما را تیون کنید تموم بشه دیگه برای چی دوباره یه ماه دیگه سیستم کند میشه خوب طبیعی است هم حجم دیتا و هم به هر حال سیستم پویا است تغییراتی که داره رو اون سیستم رخ میده طبیعیه که به مرور زمان دوباره کندی مطرح بشه. اگر تغییرات رو سیستم رخ نده خوب حجم دیتا به تنهایی باعث این میشه حالا اینکه چقدر طول میکشه بر اساس رشد دیتا میشه گفت یعنی خیلی فرمول ثابتی نداره اما اگر تند تند اصطلاحا پابلیش گذاشته بشه تقریبا میشه گفت بعد از هر پابلیشی که خصوصا اگر تغییری توی سطح بانک اطلاعاتی یا سطح کوئریها باشه به احتمال قوی دوباره نیاز به بهینهسازی عملکرد (Performance Tuning) هست.
+ درسته درسته آقای دکتر من از فرمایشات شما مبحث اون Grow up دیتا را به عنوان یک عاملی که میتونه تاثیر بزاره فهمیدم تغییراتی که در ساختار نرمافزار در واقع هستش که به قول شما با پابلیش ها و با اون رشدی که نرمافزار داره امکاناتی که اضافه میکنه خوب ممکنه این امکانات تیون نشده باشه که در واقع نزد مشتری باید این تیونینگ اتفاق بیفته من یه چیزی میخوام با اجازه شما بهش اضافه بکنم نرمافزارهایی که خوب کار میکنن در واقع در نزد مشتری، مشتری این نرمافزارها را کشف میکنه یک سری امکانات و ویژگی هایی را بعد از مدتی کشف میکنه توش مثلا توی یک پروژهای در واقع یک روش اجرایی در خصوص بهره برداری از یک نرمافزاری تدوین شده بود و قرار بود نرمافزار با این امکانات کار بکنه نرمافزار چون خوب کار میکردش بعد از یه مدتی در واقع سازمان بهره بردار اومد پیش خودش گفت خیلی خوب حالا که در واقع این داره کار میکنه و نیازها رو داره کاور میکنه حالا بیایم بهره برداری بیشتری ازش داشته باشیم لذا در واقع اون سلیقه کاربری و اون توسعه کاربری هم به نظر من روی در واقع اینکه تیون بودن نرمافزار باید حتما اتفاق بیفته تاثیرگذار هستش
+ آقای دکتر من در واقع یک نکته ای رو من خیلی میشنوم منظور در سیستمهای اینترپرایزه که قراره در سازمانهای بزرگ مثل وزارت خانه ها بانک ها نصب شود این سیستم ها در واقع میره میشینه کار میکنه و بعد از یه مدتی دچار چالش میشن دیگه سازمان بهره بردار و اون شرکت نرم افزاری و ارائه دهنده محصول چیزی که من میشنوم و تو بازار در واقع حضور شما که یکم باب هستش اینه که به عنوان اولین پیشنهاد اولین جایی که سراغش میرن بعد از اون کندیه، مبحث زیر ساخت است یعنی سریع در واقع نگاهها میره به سمت منابع، رم، سی پی یو به قول معروف io دیسک و مباحثی از این دست و با اون نگرشی که تو اون سمت هستش سعی میشه که این موضوع حل بشه
آیا افزایش منابع اولین راهکار برای رفع کندی نرمافزارها است؟
(06:25 تا 09:53)
+ آیا در واقع این موضوع میتونه به عنوان اولین در واقع مطلع ورودی بابت مبحث بهینهسازی عملکرد (Performance Tuning) نگاه بشه بهش یا ما یه سری مباحث قبل تر و علی القاعده احتمالا ارزون تری هم در واقع البته تخصصیتر هم میتونیم داشته باشیم
– بله این خیلی طبیعیه که وقتی سیستم دچار کندی میشه انگشت اتهام بره به سمت واحد زیرساخت بگن که خوب منابعرو بیشتر کن رم بیشتر بهش بده سی پی یو بیشتر بهش بده و این احتمال هم است که اگر اون مجموعه زیر بار بره و منابع را بیشتر کنه حال سیستم بهتر بشه ولی حتی اگر اینجوری بشه موقته یعنی دوباره به زودی حال سیستم بد میشه و میدونیم که تا بی نهایت نمیتونیم منابع را اضافه کنیم پس طبیعیه وقتی سیستم دچار کندی میشه در مرحله اول نریم سراغ بحث زیرساخت و سختافزار کما اینکه تو اون لحظه هم ما میتونیم مانیتورینگ (Monitoring) داشته باشیم که ببینیم وضعیت منابع به چه شکلی است یعنی ممکنه کندی وجود داشته باشد حتی منابع تحت فشار نباشه ممکن هم هست کندی وجود داشته باشه منابع سیستم درگیر بشه و سیستم واقعا تحت فشاره ولی حتی تو حالت دوم هم به نظر من منطقی نیست که بگیم برو رم و سی پی یو را اضافه کن SSD به ما بده و در واقع ایراد بگیریم به اون واحد زیر ساخت که منابع خوبی را تخصیص ندادی درست اینه که ما ابتدا سیستم را تیون بکنیم چرا؟ چون تیون کردن حالا یکم اصطلاحات فنی من بگم به جای index scan، index seek کنه به جای اینکه یک تیبل یا یه ایندکسی لود بشه بیاد تو مموری buffer cache بگیره بخش کوچیکی از اون توی مموری میاد خب همین تیکه باعث میشه که تا اندازهای مموری آزاد بشه و به جای اینکه کاست بالا باشه سی پی یو ها درگیر بشن و در واقع یک کوئری کل سی پی یو را درگیر کنه شما با تیون کردن باعث میشه سی پی یو تایم کمتری میذاره برای پردازش اون کوئری و باعث میشه سی پی یو رها بشه خوب طبیعیه که ما اول سیستم را تیون کنیم منتها چون تیون کردن ته نداره حالا با توجه به دانش اون سازمان و اون مجموعه میاد سیستم را تیون میکنیم تیون کردن کوئریهارو بهبود میده ایندکس هارو اگر لازم باشه ایجاد میکنه تنظیمات را درست میکنه حالا دیگه وقتشه که بریم منابعرو چک کنیم در این حالت اگر منابع شرایط خوب داشت که هیچی اگر نه به نظرم وقتشه که یه در واقع بازنگری بکنیم وضعیت رم و سی پی یو را و اگر لازمه منابع افزایش پیدا کنه
+ پس پیشنهاد شما اینه که در گام اول تیونینگ اتفاق بیوفته حتما یه دور این اتفاق بیوفته اگر در واقع حال سیستم خوب بود خیلی عالیه در غیر این صورت بریم سراغ مبحث منابع
اهمیت نصب و پیکربندی صحیح نرمافزارها در حفظ کارایی و سرعت پاسخگویی سیستم
(09:53 تا 13:30)
+ آقای دکتر مبحث نصب و پیکر بندی صحیح سیستم یا در واقع بخش دیتابیس علی خصوص چقدر میتونه در طولانی بودن در واقع اون کیفیت سیستم اثرگذار باشد آیا ما نصب خوب داریم پیکربندی خوب و بد داریم یک سوالم این هستش سوال دیگرم هم این هستش که در واقع ما در حوزه پیکربندی و پیاده سازی سیستمها تاثیر سایر سیستمها میتونه که اثرگذار باشه به عنوان مثال ما یه نرمافزار اینترپرایز داریم در واقع تو یک سازمان بزرگ نصب میشه یک آنتی ویروس خیلی در واقع ساده میتونه خیلی تاثیر گذار باشه از این دو زاویه ما چقدر باید این دو تا موضوع رو جدی بگیریم یکی در واقع در خصوص پیکربندی صحیح و در واقع در خصوص تاثیری که سایر سیستمها روی اون سیستم جدید الورود میتونه داشته باشد؟
– در فرایند پرفومنس تیونینگ قطعا کانفیگ او اس و کانفیگ دیتابیس یا بگیم حتی کانفیگ خود اینستس RDBMS اینها همه بخشی از مراحل بهینهسازی عملکرد (Performance Tuning) است مثلا اگه بخوام یه مثال خدمت شما عرض کنم ما توی پیکربندی سی پی یو در سطح یک ماشین مجازی برامون مهمه که اون اعداد با اون موموهایی که در نظر گرفته شده بخونه اصطلاحا اون تیک هات پلاگه زمانیکه ماشینو کانفیگ کردن برداشته بشه یعنی خیلیها تیک هات پلاگ دوست دارن بزارن که در حالی که ماشین روشنه بتونن کارهای سی پی یو بدهند یا بگیرند نه این کار درستی نیست بخاطر اینکه اگر اون تیک باشد دیگه در واقع SQL server نوما را نمی فهمد خیلی وارد جزئیات نشیم ولی اگر من بخوام خیلی کوتاه عرض کنم نوما یعنی دسترسی غیر یکنواخت (Non-uniform memory access) به حافظه یعنی core سی پی یو به جای اینکه به مموری core خودش وصل بشه میره به یه مموری core دیگه وصل میشه و این باعث میشه که در شرایطی سیستم بد عمل کنه برای همه اینها کانفیگهاییه که لازمه . من این تیک در سطح ماشین خدمت شما عرض کردم در سطح اینستنس به همین شکل شما Max top را باید ست کنیم در سطح دیتابیس هم به همین شکل بنابراین کانفیگها که حتما لازمه. در قسمت فرمایش دومتون قطعا آنتی ویروسی که شما فرمودین یه مسیرهایی هست یا اصطلاحا فایلهایی در SQL است که حتما باید اکسلود بشه تو آنتی ویروس و اگر به خود سایت مایکروسافت هم مراجعه کنید تو قسمت آنتی ویروس اشاره کرده که چه فایل هایی باید اکسلود بشه که اگر این اتفاق نیفته خوب قطعا بله تاثیر گذاره و سیستم کنده
اهمیت معماری توزیع یافته در کارایی و سرعت سیستم
(13:30 تا 15:58)
+ آقای دکتر در سیستم هایی که Load Balance دارند دیتای زیادی دارند کاربران زیادی دارند و جز سیستم های زیر بار سازمان های بزرگ به حساب میاد معماری توزیع یافته چقدر میتونه که کمک بکنه توی حفظ در واقع پرفورمنس؟ آیا در واقع ما میتونیم انتظار داشته باشیم در یک سازمان اینترپرایز با یک سیستم بزرگ یک نرمافزاری که معماری توزیع یافته ندارد در دراز مدت این حالش خوب باشه خوب کار بکنه؟
– بحث توزیع یافته یه بحث مفصلیه یعنی اینکه اگر بخواهیم خیلی در موردش گسترده صحبت کنیم ممکنه بحث No SQL و بحث Big data و اینها هم بشه اگر صرفا تو حوزه RDBMS بخواهیم صحبت کنیم ما تو بحث RDBMS یعنی فارغ از اینکه سمت پلتفرمهای No SQL نریم هم میتونیم هم بحث Load Balance داشته باشیم و میتونیم یه سری کارها را به صورت آسنکرون انجام بدیم یعنی به هر حال ما با راه اندازی Always On هم میتونیم Load Balance روی بخش Read داشته باشیم هم میتونیم گاهی اوقات بار خواندن را از سرور Primary هدایت کنیم به سمت سرور Secondary و این قسمت آسنکرون هم خیلی مهمه یکی از کارهای جالبی که فراگستر واقعا انجام داده این که خودش اومده این چرخ را اختراع کرده یعنی همون سرورهای operation که فراگستر داره اگه بخوام خدمت بینندگان عزیز بگم شبیه اکسترنال External Activation توی سرویس بروکر هست یعنی بخشی از کارهایی که میتونه به صورت آسنکرون انجام بشه در واقع به عهده سرورهای دیگهای سپرده میشه که اینا خارج از سرور اصلیشون اینها رو پردازش کردند
اهمیت معماری Data warehouse در کارایی و سرعت سیستم
(15:58 تا 19:17)
+ درسته تشکر میکنم. آقای دکتر در خیلی از سازمانها و سیستمهای اینترپرایز مثل سیستمهای حوزه بانکی و مباحث از این دست ما میدونیم که ساختارهای با OLAP یا OLTP جداگانه دارند ساختارهایی که تو حوزه تراکنش و در واقع نوشتن و خواندن دیتا هست یک سمت هستش اون بخشهای حوزه گزارشات و داده ها محیط جدا هستش به دلیل همین در واقع کنترل فشاری که در واقع روی سیستم انجام میشه و این فشار کنترل میشه. وجود در واقع این ساختار و در واقع همون وجود data warehouse یا انبار داده چقدر تو این سیستم ها میتونه تاثیرگذار باشه از بعد پرفورمنس؟
– بحث data warehouse زمانی مطرح شد در واقع یک معماری هست که بعد از مدل ریلیشنال مطرح شد قبل از اینکه به data warehouse برسیم یکم راجع به مدل ریلیشنال صحبت کنیم مدل رابطه ای مدلیه که آقای کات آن را مطرح کرد از شرکت آی بی ام اومد این مدلی که خیلی مدل سنتی هم هست ولی به هر حال تا الان هست و کماکان هم داره استفاده میشه این مدل برای DML طراحی شد یعنی به شکلی طراحی شد که خیلی insert-delete-update را خوب هندل کند بنابراین بحثهای Redundancy و Anomaly و Null value توش دیده شد یعنی حداقل افزونگی حداقل Anomaly و حداقل مقادیر تهی خوب سال ها این مدل استفاده شد بعدها رسیدن به اینکه اگر این همه جداول متعدد این همه جوینهای زیاد نباشه read از دیتا یا اصطلاحا خواندن از دیتا خیلی سریعتر انجام میشه پس معماری warehouse مطرح شد بنابراین اگر ما بخواهیم مدل ریلیشنال را با warehouse مقایسه کنیم جایی که insert-delete-update داریم طراحیمون باید همون مدل ریلیشنال سنتی باشد اما جایی که read سنگین داریم میتونیم بریم warehouse ولی خیلی خوبه که این دوتا را از هم تفکیک کنیم یعنی ما برای او OLTP نریم سراغ warehouse چون warehouse دیتابیسی نیست که روش insert-delete-update میشه warehouse دیتابیس که با فرایند ATL داره پر میشه پس احتمالا یه تاخیر زمانی توش وجود داره وقتی بحث OLAP مطرح میشه اون تاخیر زمانی خیلی مهم نیست خیلی جاها من دیدم که از warehouse انتظار گزارش های OLTP دارند یعنی تا یه دیتایی رو وارد کردند اون لحظه میخواهند از warehouse بخونند ببینند نتیجه اعمال شده یا نه خوب معمولا هندل کردن این سخت میشه و سازمان ها دچار چالش میشن ولی به هر حال اگر بخواهیم نتیجه گیری کنیم وجود warehouse و گزارشات OLAP بله اونور خیلی سریعتر انجام میشه با تکنولوژی هایی هم که جدید اومده مدل Column store در واقع به صورت این معماری است که مایکروسافت ارائه داده ما میتونیم خواندنهای حجیم و به صورت Agree Gate را از warehouse داشته باشیم
+ و این روی پرفورمنس کمک میکنه این شکست دیتابیس و تفکیک وظایف رو پرفورمونس تاثیرگذار است
– بله
ابزارهای حوزه Performance Tuning و Monitoring
(19:17 تا 28:19)
+ آقای دکتر چه ابزارهایی رو در خصوص دو مبحث بهینهسازی عملکرد (Performance Tuning) و مانیتورینگ (Monitoring) شما میتونید معرفی بکنید و اگر اینها رو یک مقایسه داشته باشید خیلی ممنون میشم و یک سوال دیگه هم در این خصوص دارم آیا نرم افزارهای حوزه مانیتورینگ (Monitoring) این درست هستش که بار میذاره روی محصول اون نرم افزاری اگر یک چیزی هی watch بکنه هی بخواد مانیتور بکنه کنترل یکنه آیا به ذات من یک جا حتی عدد ۵ در صد هم شنیدم تو ذهنم هستش که معادل این هستش که تا حدود ۵ درصد، ۱۰ درصد انگار یک سامانه کاربر بیشتری در واقع به خودش در واقع داره، زمانی که مانیتورینگ (Monitoring) داره روش انجام میشه
– بله ببینید ما اگر بخواهیم در مورد ابزارهای بهینهسازی عملکرد (Performance Tuning) صحبت کنیم خوب یه محدوده خیلی وسیعی یعنی به نوعی میشه گفت همون تسک منیجر خودش یه ابزار تیونینگی است شما باهاش میتونید رم و CPU را مانیتور کنید همون لحظه تسک منیجر را باز کنید CPU usage بالا باشه حالا به نوساناتش کار نداشته باشیم ولی همینجوری میانگینش بالای ۶۰ درصد باشه میشه گفت که سیستم تا اندازهای تحت فشار هست resource مانیتور خودش دارای ابزار تیونینگیه یخورده حرفه ای تر بخواهیم بهش نگاه کنیم پرفورمنس مانیتور با اضافه کردن کانترها شما میتونید وضعیت CPU مموری و دیسک را در واقع مانیتور بکنیم از اون طرف بریم تو حوزه SQL server، Trace که حالا توصیه میشه که Trace به صورت سرور سایت اجرا بشه در واقع ما اگر بریم با پروفایلر یه Trace اجرا کنیم به صورت کلاینت سایت خودش بار خیلی زیادی میزاره روی سیستم ولی Trace سرور سایت بار خیلی کمتری در واقع رو سیستم میذاره یا extended event ها، sessionهایی که اونجا ایجاد میشه اینا همه ابزارهای مانیتورینگ (Monitoring) هستند که شما به وسیله این میتونید کوئریهای کند، بلاکینگ ددلاگ و حالا هر چیز دیگهای که مد نظرتون هست رو استخراج کنید کنار اون میتونیم سراغ ابزارهای دیگهای بریم مثل SQL Diagnostic Manager مانیتور Red Gate یا DPI که مال SolarWinds نیز هست همه اینها ابزار های مانیتورینگ (Monitoring) اند اما میشه خیلی مفصل در موردش صحبت کردیم معمولا شما وقتی Red Gate یا SQL Diagnostic Manager را نصب میکنید خوب بار بیشتری روی سیستم میگذاره یکسره در حال اجرای کوئری است که اینها را در واقع مانیتور کنه و یک جایی برای خودش توی ریپازیتوریش ذخیره کنه و ما بتونیم مراجعه کنیم و ببینیم اتفاقاتی که افتاده اگر هیستوری برای ما مهم باشه چارهای نداریم که بریم سراغ این ابزارها یعنی یعنی چی؟ یعنی ممکنه به من بگن که دیروز ساعت ۶ عصر چه اتفاقی روی دیتابیس افتاد حالا ممکنه اتفاقی هم روی دیتابیس نیوفتادهها به هر حال 6 عصر یه اتفاق غیر نرمالی رخ داده میخوام ببینم تو دیتابیس وضعیت اوکی بوده CPU پیک زده ویت بالایی داشتیم خب اگر ما این تیپ ابزارها رو نداشته باشیم SQL Diagnostic Manager یا حالا DPI سخت میشه کار اگر یک بلاکینگ باشه یا یه ددلاگ چرا با رفتن رفتن سراغ Trace سرور سایت یا extended event میتونیم بهش برسیم ولی ممکنه بلاکینگ نبوده خوبی این ابزارها اینه که همه چیزو تجمیع کرده برای ما. باز عرض میکنم اگه هیستوری برای ما مهمه استفاده از این ابزار لازمه اینکه بار میزاره بله چند درصد نمیدونم یه خورده هم باید دید حال سیستم چجوریه اگه سیستم منابعش لبالب داره کار میکنه نصب این ابزارها ممکنه چالش ایجاد کنه ولی به طور معمول میشه صرف نظر کرد از باری که اینا ایجاد میکنن یعنی اینقدر خوبی برای ما میاره که اون بدی کوچکش میشه فراموش کرد ولی به هر حال همه این مواردی که من خدمت شما عرض کردم ابزارهای بهینهسازی عملکرد (Performance Tuning) است حالا برای کسی که میخواد سیستمو تیون کنه قراره تو یک ساعت، دو ساعت مشکلات سیستم رو ببینه به نظر من Trace سرور سایت یا extended event بهتر میتونه مشکلاتو ببینه انجام بده ولی برای مجموعه ای که در واقع DBA داره و میخواد مانیتوری روی بانک اطلاعاتش داشته باشه روی روی مانیتورها و صفحات تلویزیون ببینه وضعیت دیتابیس به چه شکل هست و اگر اتفاقی میفته تو نمودار براش قابل مشاهده باشه اون موقع نصب این ابزارهای که عرض کردم مثل SQL مانیتور Red Gate میتونه مفید باشد
+ این نرمافزارها هشدار دهنده هم هستش دیگه؟
-بله کانفینگ Alert توشون هست که اگر اتفاق میافتد Alert بیاد که حالا اگر تنظیمات دیگر انجام شود در قالب اس ام اس و اینها هم میتونه یا ایمیل میتونه به ما خبر بده که مثلا فلان ساعت بکاپ نگرفته یا ددلاگ یا بلاکی رخ داده
+ آقای دکتر به عنوان سوال آخر میخواستم که خدمتتون یک روز یک در واقع متخصص حوزه تیونینگ رو بپرسم از ۸ صبح شما چیکار میکنید؟ موقعی که ما میخوایم تیون بکنیم در واقع یک نرمافزار رو از کجا در واقع وارد میشید؟ چه چیزهایی رو به عنوان در واقع شاخص های اولیه در نظر میگیرید؟ کوئریهارو چه شکلی بالا پایین میکنید و در واقع به اون نتیجه میرسید؟ آیا میتونم یک صبح تا عصر رو از شما بپرسم
– خیلی میشه درموردش صحبت کرد ولی اگر فکر کنم مثلا یه نکتهای که یادم میاد که حالا به نوعی به مجموعه فراگستر هم ربط داره ما یک کوئری بود که فکر میکنم بیش از دو دقیقه زمان میبرد و وقتی رفتیم پلن کوئری رو دیدیم اینکه خیلی آمار estimate و actual با هم برابری نداره یعنی تخمین SQL server اشتباهه در عمل یه اتفاق دیگری داره میفته و شکمون رفت به این سمت که اینکه stat ها به روز نمیشه در صورتی که اون مجموعه میگفت ما stat رو به روز میکنیم درست هم میگفتند ولی بعد از اینکه دقیق شدیم دیدیم به صورت فول stat یک جدول خیلی مهم ما را آپدیت نمی کردند به صورت سمپل داشتند این کار را انجام میدادند یه خورده با فشار و اصراری که ما داشتیم که این تیبل و این stat استثنا فول آپدیت کنید ما که شاید بگم یه ربع بیست دقیقه کلنجار رفتیم بعد آپدیت شد ۲ ثانیه و بعد از اون کوئری، تایمش به یک ثانیه نرسید اجراش
– خیلی چیزا میشه تعریف کرد یعنی از اینکه یک کوئری کند بود با تعریف یک ایندکس مشکلش حل شد کوئری را ما بازنویسی کردیم توی پلن index spool دیدیم باز با تعریف ایندکس تونستیم زمان کوئری را به شدت کاهش بدیم ولی گاهی اوقات هم فقط مانیتوره یعنی میریم بالا سر سیستم نگاه میکنیم میبینیم سیستم حالش خوبه هم از منظر دیتابیس هم با لاگین کردن تو اپ چرخیدن تو همه جای سیستم میبینیم حال سیستم خوبه میگیم خدا را شکر از اونجا خارج میشیم
+ خیلی تشکر میکنم بسیار بسیار آموزنده بود برای خود من و بی نهایت از شما سپاسگزار هستم به انتهای در واقع این ویدیوی گفتگو رسیدیم از خدمت همه عزیزان هم خداحافظی میکنم و ممنون هستم
– منم از همه بینندگان عزیز که حوصله به خرج دادم تشکر میکنم و خداحافظ
+ خدانگهدار