پشت صحنهای که کمتر دیده میشود، اما همیشه درگیر کار است!
اگر زیاد با SQL Server کار نکرده باشید، احتمالاً اسم UMS یا User Mode Scheduler کمتر به گوشتان خورده باشد. خیلی از افراد فقط هنگام بررسی عملکرد (Performance Tuning) یا مطالعه مباحث عمیق تر موتور دیتابیس، با این اصطلاح رو به رو میشوند. اما واقعیت این است که UMS یکی از قطعات مهم در معماری SQL Server است که نقش جدی در مدیریت Threadها و برنامه ریزی اجرای درخواستها بازی میکند.
در این مقاله سعی میکنم خیلی خشک و تئوریک جلو نروم و در عین حال تمام توضیحات فنی لازم را هم ارائه بدهم تا یک برداشت کامل از این بخش مهم SQL Server داشته باشید. چند تا موضوع رو باهم دیگه بررسی خواهیم کرد:
مباحث مربوط به UMS
مباحث مربوط به مدل Cooperative Scheduling
مباحث مربوط به Worker Thread
مباحث مربوط به معماری SOS Scheduler
UMS مخفف User Mode Scheduler است و بخشی از معماری پردازشی SQL Server محسوب میشود که وظیفه اش این است:
مدیریت اجرای Thread ها و درخواست ها در سطح User-Mode، بدون اینکه مدام به Context Switching سطح Kernel وابسته باشد.
به زبان سادهتر:
SQL Server برای اینکه سریع تر و روان تر کار کند، تصمیم گرفته خیلی از عملیات زمان بندی (Scheduling) را خودش انجام دهد و کمتر به ویندوز تکیه کند. این سیستم اختصاصی همان UMS است.
سیستم عامل ویندوز خودش یک Scheduler دارد که وظیفه مدیریت Threadها را بر عهده دارد، اما SQL Server چند دلیل مهم داشته که به سراغ UMS برود:
کاهش Context Switching غیرضروری
هر بار که یک Thread از حالت اجرا خارج و یک Thread دیگر فعال میشود، یک Context Switch رخ میدهد.
این عملیات هزینه بر است و روی سیستمهای پرترافیک میتواند واقعاً عملکرد را کند کند. SQL Server با داشتن Scheduler خودش، این تغییر حالتها را تا حد امکان به صورت کنترلشده انجام میدهد.
هماهنگ ماندن با معماری Internal SQL Engine
موتور SQL Server شدیداً مبتنی بر مدل cooperative scheduling است؛ یعنی Threadها وقتی نیاز به اجرای دیگران باشد، داوطلبانه کنترل را relinquish میکنند.
این مدل با Scheduler ویندوز سازگار نیست، بنابراین سیستم اختصاصی نیاز دارد.
مدیریت بهتر I/O و Worker Thread ها
SQL Server دقیقاً میداند کدام Query درگیر I/O است، کدام Worker بلاک شده و کدام باید ادامه پیدا کند. ویندوز چنین دیدی ندارد.
تا نسخه 2000 (SQL Server 2000): UMS فعال بود و بخش اصلی Scheduling در SQL بود.
از نسخه 2005 به بعد: UMS جای خود را به SOS Scheduler داد.
اما هنوز هم بخشهایی از UMS به عنوان لایه پایه (Low-Level) در معماری جدید حضور دارد.
یعنی عملاً امروز ما از «SOS Scheduler» صحبت میکنیم و UMS لایه زیرین آن محسوب میشود. پس در نتیجه معمار ها و طراح پایگاه داده هایی که به صورت تخصصی دارند روی سیستم های پایگاه داده کار میکنند، باید بدونند که امروزه ما SOS رو هم داریم. ما در UMS، چند تا جز اصلی داشتیم. یکی Schedular و دیگری Worker Thread. هر CPU یک Scheduler داشت. هر Scheduler مسئول این بود که Worker Thread های مربوط به همان CPU را مدیریت کند. هر Worker وظیفه اجرای یک Task را بر عهده داشت. معمولاً هر Connection یا Job یک Worker دریافت میکرد.(در این مورد من خیلی مطمئن نیستم. برای من وقتی داشتم کار میکردم اینطوری بود. همین موضوع رو در رفرنس مایکروسافت هم خودش توضیح داده. به هر حال من از این مورد خیلی اطمینان ندارم.)
Cooperative Scheduling یعنی چه؟
SQL Server بر اساس مدل «زمانبندی مشارکتی» کار میکرد:
Worker خودش تشخیص میداد که باید کنترل را واگذار کند یا به زبام خودمونی ما برنامه نویس ها yield کنه.
این کار معمولاً وقتی انجام میشود که Worker:
منتظر I/O باشد
Query بلاک شده باشد
یا CPU را بیش از حد استفاده کرده باشد
مزیت: کنترل کامل در دست SQL Server بود.
عیب: اگر یک Worker yield نمیکرد، کل Scheduler قفل میشد. (خیلی وقت ها قفل میشد و ما به دلیل سواد پایین نمیدونستیم موضوع چی هست. الان میفهمیم که موضوع چی بود اون زمان ها ...)
UMS چه ربطی به Performance دارد؟
خیلی زیاد ربط داره! اگر در SQL Server با مشکلات زیر مواجه بشیم، همیشه باید سراغ Scheduler ها بریم:
CPU 100%
Wait Types مثل SOS_SCHEDULER_YIELD (فرصت بشه بیشتر در مورد WT ها صحبت میکنیم. مثلا ما Wait هایی داریم با عناوین Threadpool w8 یا Cmemthread w8 که الان نمیشه اینجا وارد بحثشون بشیم)
Thread Pool Exhaustion
Query هایی که فقط روی یک CPU گیر میکنند
کاهش حجم Worker Thread ها
وقتی Scheduler تحت فشار قرار بگیرد، SQL Server به شکل قابل توجهی کند میشود.
UMS در نسخههای جدید چه نقشی دارد؟
گرچه امروز بیشتر از SOS Scheduler استفاده میکنیم، ولی UMS هنوز در لایه داخلی وجود دارد. UMS امروز دیگر سیستم اصلی Scheduling نیست، اما پایه معماری SOS محسوب میشود.
این موضوعاتی که بیان شد رو چطور باید در پایگاه داده مانیتور کنیم؟
عزیزانی که کارشون مانیتورینگ هست، میدانند. ما موضوع DMV ها رو داریم در SQLSERVER که هم وضعیت Scheduler ها و هم وضعیت Worker ها رو نشون میده ولی فعلا این مقاله جای مناسبی برای ورود بخ بحث فنیش نیست.
UMS یک بخش مهم و تاریخی از معماری SQL Server است که تا نسخه 2000 اصلیترین سیستم Scheduling بود. در نسخههای جدید با اینکه SOS Scheduler جای آن را گرفته، اما UMS همچنان زیرساخت این مدل محسوب میشود. اگر علاقهمند به Performance Tuning باشید، شناخت نحوه کار Scheduler ها و Worker Thread ها میتواند در تحلیل مشکلات پیچیده SQL Server خیلی کمک کننده باشد.
