دیتابیس چرا کند شده؟ مانیتورینگ سرور برای کشف گلوگاه و Query کند
CPU سرور طبیعی است ولی ثبت سفارش کند شده؟ آموزش تشخیص Query کند، Lock Wait، Deadlock، Connection Pool و گلوگاه MySQL و PostgreSQL با رویکرد عملی مانیتورینگ سرور.
صفحه سفارش باز می‌شود، اما ثبت نهایی خرید گاهی هشت ثانیه طول می‌کشد. CPU سرور زیر فشار نیست و فضای RAM هم کافی است. مشکل کجاست؟ در بسیاری از این موقعیت‌ها، پاسخ در دیتابیس پنهان شده است: یک Query بدون ایندکس مناسب، قفل طولانی یک تراکنش یا تمام‌شدن ظرفیت Connection Pool. مانیتورینگ سرور اگر فقط مصرف منابع را نشان دهد، چنین مشکلی را دیر آشکار میکند. برای تشخیص باید رفتار خود پایگاه‌داده را هم ببینیم.
این راهنما مخصوص عیب‌یابی کندی MySQL، MariaDB و PostgreSQL است. یاد می‌گیرید از روی زمان پاسخ، شمار اتصالها، Queryهای کند و Lock Wait بفهمید کجا باید دنبال علت بگردید. هدف آموزش فهرستی از دستورهای پراکنده نیست؛ می‌خواهیم یک روش کم‌خطر برای بررسی کندی در محیط واقعی داشته باشیم، بدون اجرای Query سنگین یا دست‌کاری بی‌برنامه دیتابیس عملیاتی.
چرا مانیتورینگ CPU نمی‌تواند کندی دیتابیس را توضیح دهد؟
وقتی درخواست وب منتظر آزادشدن قفل یک ردیف است، ممکن است تقریباً هیچ پردازشی روی CPU انجام ندهد. بااین‌حال کاربر منتظر می‌ماند و Worker وب اشغال می‌شود. همین وضعیت برای انتظار روی دیسک یا اشباع تعداد اتصال‌های دیتابیس رخ می‌دهد. بنابراین باید زمان انتظار را از میزان کار پردازنده جدا کنیم.
برای شروع، زمان کل درخواست را به بخش‌های کاربردی تقسیم کنید: ورود درخواست به برنامه، اتصال یا دریافت اتصال از Pool، اجرای Query، انتظار روی قفل، کار پردازشی برنامه و ساخت پاسخ. اگر Trace کامل ندارید، ثبت زمان Queryهای مهم و شناسه درخواست هم نقطه شروع مناسبی است. هیچ‌کدام از این داده‌ها به‌تنهایی اثبات نمی‌کنند که مشکل از سرور دیتابیس است؛ باید با هم مقایسه شوند.
سه علامت هشداردهنده در یک نگاه
- زمان پاسخ بالا با CPU عادی: احتمال انتظار روی Lock، اتصال یا دیسک را بررسی کنید.
- خطای اتصال در اوج ترافیک: تعداد اتصال‌های فعال، زمان انتظار Pool و حد مجاز اتصال را کنار هم ببینید.
- کندی بعد از یک انتشار کد: تغییر Queryها، N+1، ایندکس و حجم داده برگشتی را پیش از افزایش سخت‌افزار بررسی کنید.
کدام شاخص‌ها در مانیتورینگ دیتابیس واقعاً مهم‌اند؟
| شاخص | چه چیزی روشن میکند؟ | خطای رایج در تفسیر |
|---|---|---|
| زمان پاسخ Query در p95 و p99 | تجربه درخواست‌های کندتر از حالت معمول | اکتفا به میانگین و پنهان‌کردن کندی‌های شدید |
| اتصال‌های Active و Idle | نحوه مصرف ظرفیت اتصال دیتابیس | فرض اینکه هر اتصال باز نشانه فشار است |
| زمان انتظار Connection Pool | مدت انتظار برنامه برای اتصال آزاد | اشتباه‌گرفتن انتظار برنامه با اجرای SQL |
| Lock Wait و Deadlock | برخورد تراکنش‌های هم‌زمان | پاک‌کردن نشانه‌ها با Restart عجولانه |
| Disk I/O Latency | کندی عملیات ذخیرهسازی | فقط بررسی درصد پرشدن دیسک |
| نرخ خطا و Timeout | اثر اختلال دیتابیس روی سرویس | قضاوت صرف از روی وضعیت «Online» دیتابیس |
این شاخص‌ها را در یک بازه زمانی مشترک و در کنار نرخ درخواست‌ها بررسی کنید. برای مثال اگر p95 ناگهان افزایش یافته اما ترافیک ثابت مانده، یک تغییر در برنامه یا وضعیت قفل‌ها ممکن است مهم‌تر از افزایش ظرفیت باشد.
پیش از تغییر تنظیمات چه چیزی را ثبت کنیم؟
برای عیب‌یابی درست، حداقل زمان دقیق رخداد، نام مسیر کند، نسخه منتشرشده، شناسه درخواست و مدت اجرای بخش دیتابیس را ثبت کنید. از همان ابتدا برای اطلاعات حساس محدودیت بگذارید: متن کامل SQL ممکن است شامل ایمیل، شماره تلفن یا داده مشتری باشد. به‌جای کپی‌کردن بی‌محابای Queryها، از Query Fingerprint یا متن پارامتری‌شده و دسترسی محدود استفاده کنید.
یک نمونه قابل لمس از خطای N+1
تصور کنید فهرست ۵۰ سفارش را نمایش می‌دهید و برای هر سفارش یک Query جداگانه اطلاعات مشتری اجرا می‌شود. برنامه ابتدا یک Query برای فهرست و سپس حدود ۵۰ Query دیگر می‌فرستد؛ یعنی تقریباً ۵۱ رفت‌وبرگشت به دیتابیس، درحالی‌که با بارگذاری رابطه‌ای مناسب ممکن است تعداد Queryها به‌طور محسوسی کمتر شود. عدد دقیق و راهکار به ساختار داده بستگی دارد. این مثال نشان می‌دهد چرا باید تعداد Query در هر درخواست را هم اندازه بگیریم، نه فقط میانگین زمان یک Query را.
در MySQL و MariaDB از کجا شروع کنیم؟
در MySQL و MariaDB، ابزارهایی مانند Slow Query Log، وضعیت اتصالها و نمای پردازش‌ها می‌توانند جهت بررسی را مشخص کنند. فعال‌سازی و سطح جزئیات لاگ باید با نسخه دیتابیس، حجم ترافیک و سیاست محرمانگی سازگار باشد؛ بعضی تنظیمات در محیط پرترافیک سربار دارند.
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW FULL PROCESSLIST;
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';این فرمان‌ها برای مشاهده وضعیت‌اند. استفاده از حساب دارای دسترسی محدود را ترجیح دهید و خروجی خام را به تیکت عمومی منتقل نکنید. اگر یک Query مشخص مشکوک بود، ابتدا Plan اجرای آن را در محیط کنترل‌شده با EXPLAIN تحلیل کنید؛ اجرای آزمایشی Queryهای سنگین با EXPLAIN ANALYZE روی Production میتواند واقعاً Query را اجرا کند و بار ایجاد کند.
ایندکس همیشه درمان قطعی نیست
ایندکس میتواند جست‌وجوی مناسب را سریع‌تر کند، اما هزینه نوشتن و فضای ذخیرهسازی دارد. برای Query کند، ترتیب ستون‌های شرط، مرتب‌سازی، حجم ردیف‌های برگشتی و Plan را بررسی کنید. افزودن یک ایندکس بدون آزمون، ممکن است مشکل خواندن را کم و هزینه درج داده را بیشتر کند. تغییر Schema نیز باید همراه با پشتیبان، زمان مناسب و برنامه بازگشت انجام شود.
در PostgreSQL چگونه Lock و Queryهای پرهزینه را ببینیم؟
در PostgreSQL، نمای pg_stat_activity وضعیت Sessionها و نوع انتظار را نشان می‌دهد. افزونه pg_stat_statements هم برای گردآوری آمار اجرای دستورهای SQL کاربرد دارد، اما ممکن است به تغییر تنظیمات و راه‌اندازی دوباره نیاز داشته باشد. پیش از فعال‌سازی، مستندات رسمی pg_stat_statements را با نسخه سرور خود تطبیق دهید.
SELECT pid, state, wait_event_type, wait_event
FROM pg_stat_activity
WHERE datname = current_database()
LIMIT 20;فهرست Wait Eventها، از جمله انتظار روی Lock و I/O، در مستندات پایش PostgreSQL توضیح داده شده است. خروجی بالا صرفاً مشاهده وضعیت است. برای تشخیص علت، تراکنش‌های مرتبط و مدت انتظار را بررسی کنید؛ Terminateکردن Sessionها بدون شناخت عملیات جاری ممکن است موجب Rollback بزرگ یا شکست درخواست مشتری شود.
تفاوت Lock Wait و Deadlock چیست؟
در Lock Wait، یک تراکنش منتظر آزادشدن قفل است. در Deadlock، چرخه‌ای از انتظار میان تراکنش‌ها ایجاد می‌شود و دیتابیس ناچار است یکی را لغو کند. هر انتظار طولانی Deadlock نیست؛ بااین‌حال هر دو می‌توانند زمان پاسخ برنامه را بالا ببرند. الگوی ترتیب دسترسی به جدول‌ها، طول عمر تراکنش و Indexها در پیشگیری نقش دارند.
نمونه عیب‌یابی: سفارش‌ها فقط در ساعت اوج کند می‌شوند
فرض کنید نرخ درخواست ثابت رشد میکند، اما نزدیک ساعت شلوغی، p95 ثبت سفارش از ۴۰۰ میلی‌ثانیه به چهار ثانیه می‌رسد. CPU دیتابیس هنوز ظرفیت دارد. در Log برنامه، زمان انتظار برای گرفتن اتصال زیاد شده است. قبل از افزایش تعداد اتصال مجاز، این مراحل را طی کنید:
- زمان شروع کندی را با نمودار ترافیک و تغییرات اخیر برنامه مقایسه کنید.
- تعداد اتصال‌های استفاده‌شده، اتصال‌های Idle و مدت انتظار Pool را ثبت کنید.
- بررسی کنید آیا یک درخواست، اتصال را بیشتر از زمان لازم نگه می‌دارد یا تراکنش بلندمدت باز مانده است.
- Queryهای کندتر و تعداد Query هر درخواست را بررسی کنید؛ از لاگ‌های حاوی اطلاعات حساس محافظت کنید.
- بهینهسازی را ابتدا در محیط آزمایشی و با بار مشابه بسنجید.
- پس از انتشار تغییر، p95، نرخ خطا و زمان انتظار اتصال را با دوره مشابه قبل مقایسه کنید.
اگر صرفاً حد Connection را بالا ببرید، ممکن است فشار هم‌زمان بیشتری به دیتابیس تحمیل کنید و مشکل شدیدتر شود. معیار تصمیم، کاهش زمان انتظار و خطای واقعی است؛ نه فقط افزایش عدد مجاز Sessionها.
هشدار دیتابیس باید چه زمانی ارسال شود؟
به‌جای اعلان برای هر Query که کمی بیشتر از معمول طول کشیده، از ترکیب شاخص‌ها استفاده کنید. برای نمونه، وقتی p95 زمان ثبت سفارش در چند پنجره متوالی افزایش یافته و هم‌زمان Timeout اتصالها نیز بیشتر شده است، احتمال اثرگذاری بر کاربران بیشتر است. برای بررسی این روش می‌توانید راهنمای هشدار هوشمند و کاهش پیام‌های کاذب را بخوانید.
آستانه مناسب تابع هدف سرویس است. دیتابیسی که گزارش شبانه را پردازش میکند با دیتابیس احراز هویت کاربران یکسان نیست. ابتدا برای عملیات حیاتی هدف زمانی تعیین کنید و سپس با داده واقعی، حد هشدار و مدت انتظار را مشخص کنید. در کنار خطا، پیام بازیابی را هم ثبت کنید تا پایان حادثه روشن باشد.
معرفی سامانه مانیتورینگ آوازتک برای بررسی سلامت دیتابیس
وقتی علت کندی میان برنامه، دیتابیس و سرور تقسیم شده است، دیدن همه نشانه‌ها در چند ابزار جداگانه وقت می‌گیرد. سامانه Avaztek Monitoring طبق معرفی رسمی محصول، پایش منابع سرور، وضعیت سرویس‌ها و مانیتورینگ دیتابیس را در یک محیط ارائه میکند. کنار هم قرارگرفتن وضعیت دیتابیس با CPU، حافظه، دیسک و شبکه کمک میکند در زمان کندی، مشخص شود بررسی را از کدام بخش شروع کنیم.
بخش Log Explorer برای جست‌وجو و فیلتر رخدادها کاربرد دارد. می‌توان زمان خطای برنامه را با تغییرات وضعیت سرور تطبیق داد و برای نشانههای مهم هشدار تعریف کرد. نکته: وجود قابلیت «مانیتورینگ دیتابیس» به معنی اجرای خودکار Query Profiling یا بهینهسازی Index در تمام موتورهای دیتابیس نیست. برای تحلیل SQL باید از ابزار خود موتور و سطح دسترسی مجاز هم کمک گرفت.
برای آشنایی با جزئیات قابلیت‌ها، صفحه امکانات و پلن‌های مانیتورینگ آوازتک را بررسی کنید. اگر قصد شروع پایش دارید، ثبت‌نام در سامانه مانیتورینگ مسیر رسمی ورود است. ابتدا یک دیتابیس کم‌خطر را به پایش اضافه و شاخصهای پایه آن را با نمودار زمان پاسخ برنامه مقایسه کنید.
پرسش‌های متداول درباره مانیتورینگ دیتابیس سرور
چرا دیتابیس کند شده ولی CPU سرور پایین است؟
انتظار روی قفل، اتصال آزاد یا عملیات دیسک ممکن است بدون مصرف بالای CPU رخ دهد. وضعیت Sessionها، زمان انتظار و روند تأخیر Query را بررسی کنید و از روی درصد CPU به‌تنهایی نتیجه نگیرید.
آیا فعالکردن Slow Query Log روی سرور اصلی خطر دارد؟
بسته به تنظیمات و حجم ترافیک میتواند سربار ذخیرهسازی یا خطر افشای داده ایجاد کند. پیش از تغییر، نسخه دیتابیس، مدت نگهداری، سطح دسترسی و حجم پیشبینیشده لاگ را بررسی کنید و در صورت امکان ابتدا در محیط آزمایشی بسنجید.
آیا افزایش max_connections همیشه مشکل اتصال را حل میکند؟
خیر. اگر علت، نگهداشتن طولانی اتصال یا Query کند باشد، افزایش سقف میتواند مصرف RAM و رقابت روی منابع را بیشتر کند. ابتدا زمان انتظار Connection Pool و چرخه عمر تراکنش را اندازه بگیرید.
برای MySQL و PostgreSQL یک شاخص مشترک وجود دارد؟
نرخ خطا، زمان پاسخ برنامه و تعداد اتصالها شاخصهای مفیدی در هر دو هستند؛ ولی جزئیات Lock، آمار Query و ابزار اندازهگیری در موتورهای مختلف فرق دارد. برای تشخیص دقیق از مستندات همان نسخه استفاده کنید.
آیا Avaztek Monitoring خودش Queryهای کند را اصلاح میکند؟
سامانه برای پایش و مشاهده نشانههای مرتبط با زیرساخت و دیتابیس معرفی شده است، نه اصلاح خودکار Query. بهینهسازی SQL و Schema نیازمند بررسی متخصص، آزمون عملکرد و برنامه بازگشت است.
اگر کندی دیتابیس به روند بلندمدت مصرف CPU یا دیسک مرتبط است، راهنمای ظرفیت‌سنجی سرور را بخوانید. برای تصمیم درباره حفاظت از داده هنگام تغییر Schema نیز راهنمای آزمون بازیابی بکاپ مکمل این بحث است.
نتیجه: کندی دیتابیس را با داده تشخیص دهید، نه حدس
اگر سایت کند شده، پیش از خرید CPU یا Restart دیتابیس، زمان انتظار را پیدا کنید. p95 Query، اتصالها، Lock Wait و تأخیر دیسک معمولاً تصویر دقیق‌تری از درصد مصرف سخت‌افزار می‌دهند. مانیتورینگ سرور وقتی در کنار پایش دیتابیس قرار بگیرد، راه پیدا‌کردن علت را کوتاه‌تر میکند. برای دیدن امکانات عملی پایش زیرساخت و دیتابیس، سامانه مانیتورینگ آوازتک را بررسی کنید. همچنین راهنمای پایه مانیتورینگ سرور برای آشنایی با سایر شاخص‌ها در دسترس است.
نظرات و گفت‌وگو
نظرها پس از تایید مدیر منتشر می‌شوند. پاسخ‌های رسمی مدیر با نشان مشخص نمایش داده می‌شوند.