محتوای آموزشی وبلاگ نت‌آرام
در روز فروش ویژه، فهرست محصول یا ثبت سفارش دیر باز می‌شود. پایگاه داده یکی از بخش‌های درگیر است، اما کندی صفحه به‌تنهایی ثابت نمی‌کند مشکل از آنجاست. سرور PHP، دیسک یا سرویس پرداخت هم ممکن است وقت بگیرند. با ثبت زمان و تطبیق گزارش‌ها می‌توانیم علت را محدودتر کنیم.
یک درخواست مشخص انتخاب کنید
نوع عمل، نشانی صفحه، ساعت، مدت تقریبی و نتیجه را یادداشت کنید؛ مثلاً «نمایش یک دسته محصول ساعت ۱۱ حدود ۱۲ ثانیه طول کشید». از اجرای سفارش‌های پرداخت واقعی تکراری برای آزمایش خودداری کنید. اگر مشتری پرداخت کرده اما نتیجه نامعلوم است، ابتدا وضعیت تراکنش را با درگاه تطبیق دهید.
گزارش برنامه و دیتابیس را تطبیق دهید
از مدیر سرویس بخواهید زمان پاسخ برنامه، مصرف منابع و در صورت دسترسی، گزارش پرس‌وجوهای کند را در همان بازه بررسی کند. در MySQL، slow query log می‌تواند بعضی دستورهایی را که از آستانه تعیین‌شده دیرتر اجرا شده‌اند ثبت کند؛ این گزارش باید از قبل درست پیکربندی شده باشد و شامل همه علت‌های کندی نیست.
در گزارش، مدت اجرای پرس‌وجو و تعداد سطرهای بررسی‌شده سرنخ هستند. یک پرس‌وجوی سریع که هزار بار تکرار می‌شود هم ممکن است در مجموع اثر مهمی داشته باشد. ارتباط زمانی و مسیر فراخوانی را با توسعه‌دهنده بررسی کنید؛ یک خط جداگانه را بدون زمینه علت قطعی ندانید.
اگر مدیر پایگاه داده هستید و اجازه خواندن تنظیمات را دارید، داخل نشست MySQL این فرمان‌ها فقط وضعیت ثبت گزارش و محل آن را نشان می‌دهند:
کد / دستورSHOW GLOBAL VARIABLES LIKE 'slow_query_log';
SHOW GLOBAL VARIABLES LIKE 'slow_query_log_file';
SHOW GLOBAL VARIABLES LIKE 'long_query_time';
اگر مقدار
slow_query_log برابر OFF است، از این گزارش نمی‌توانید درباره گذشته نتیجه بگیرید. اگر ON است، مسئول سرور باید با توجه به تنظیم خروجی گزارش، داده همان زمان را در مسیر امن بخواند؛ نام فایل همیشه به معنی نوشتن گزارش در فایل نیست، چون مقصد خروجی می‌تواند متفاوت باشد. روشن‌کردن گزارش و تغییر آستانه روی سرور شلوغ به برنامه نگهداری و توجه به اطلاعات حساس نیاز دارد. در هاست اشتراکی، ممکن است اجرای این فرمان‌ها یا خواندن گزارش در دسترس شما نباشد؛ همان زمان و نشانی را به میزبان بدهید.برای مثال، اگر جست‌وجوی محصول از ساعت ۱۰:۳۰ تا ۱۰:۳۵ کند بوده، از مسئول فنی بخواهید فراوانی و مدت پرس‌وجوهای همان بازه را با یک روز عادی مقایسه کند. مشخص کنید مشکل برای همه جست‌وجوهاست یا فقط عبارتی با نتیجه زیاد؛ این تفاوت کمک می‌کند آزمون بعدی روی همان مسیر انجام شود.
اطلاعات مشتری را محفوظ نگه دارید
دستورهای ثبت‌شده در گزارش ممکن است داده سفارش یا اطلاعات شخصی داشته باشند. فایل کامل را در فضای عمومی قرار ندهید؛ نمونه لازم را با حذف داده حساس برای فرد مجاز بفرستید. از پاک‌کردن جدول‌ها یا اجرای دستور تعمیر و حذف بر اساس یک مقاله عمومی بپرهیزید.
اصلاح را در نسخه آزمایشی بسنجید
اگر توسعه‌دهنده افزونه یا قالب، پرس‌وجوی خاصی را علت دانست، راه‌حل ممکن است اصلاح کد، شاخص مناسب یا کاهش درخواست‌های تکراری باشد. هر تغییر پایگاه داده به نسخه پشتیبان قابل بازیابی، شناخت نسخه موتور و آزمون نیاز دارد. تنظیم دلخواه حافظه یا حذف ایندکس بدون اندازه‌گیری می‌تواند وضعیت را بدتر کند.
پس از اصلاح، همان صفحه و سناریو را با داده آزمایشی و بار قابل مقایسه دوباره بسنجید. اگر محدودیت منابع واقعی باقی است، هاست پربازدید را در کنار اصلاح نرم‌افزار بررسی کنید. توضیح فنی گزارش را در مستندات MySQL ببینید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
دامنه شرکت به نام چه کسی ثبت شده است؟
۸ آبان ۱۴۰۵مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام