وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

خطای MySQL 1040؛ اتصال‌های پایگاه داده را پیدا کنیم

تعداد اتصال‌های MySQL را با SHOW STATUS ببینید، برنامهٔ پرمصرف را پیدا کنید و بدون افزایش کورکورانهٔ max_connections مشکل را رفع کنید.

انتشار:
توسط تیم فنی نت‌آرام
۵ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله خطای MySQL 1040؛ اتصال‌های پایگاه داده را پیدا کنیم در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
پیام MySQL error 1040: Too many connections یعنی پایگاه داده به تعداد مجاز اتصال هم‌زمان رسیده و نمی‌تواند درخواست تازه‌ای را قبول کند. برای بازدیدکننده ممکن است سایت خطای اتصال به دیتابیس نشان دهد؛ برای فروشگاه، این اتفاق می‌تواند صفحهٔ پرداخت را هم موقتاً از کار بیندازد. بالا بردن عدد اتصال‌ها گاهی فقط چند دقیقه مشکل را عقب می‌اندازد. اول باید بفهمیم چه برنامه‌ای اتصال‌ها را باز نگه داشته است.

آیا واقعاً همهٔ اتصال‌ها مصرف شده‌اند؟

اگر دسترسی SQL دارید، به phpMyAdmin بروید و این دستورهای فقط خواندنی را جدا اجرا کنید:
کد / دستورSHOW GLOBAL STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections'; SHOW FULL PROCESSLIST;
Threads_connected تعداد اتصال‌های فعلی را نشان می‌دهد و max_connections سقف سرور را. اگر عدد اول به سقف دوم نزدیک است، خطا با پرشدن اتصال‌ها جور درمی‌آید. SHOW FULL PROCESSLIST فهرست اتصال‌ها، کاربر و گاهی پرس‌وجوی در حال اجرا را نشان می‌دهد. پیش از فرستادن خروجی برای دیگران، نشانی ایمیل، شناسهٔ سفارش و هر دادهٔ مشتری را پاک کنید.
در هاست اشتراکی ممکن است اجازهٔ دیدن همهٔ اتصال‌های سرور را نداشته باشید. این به معنی خرابی پنل نیست؛ فقط کاربر پایگاه دادهٔ شما مجوز مدیر سرور ندارد. زمان رخداد، نام پایگاه داده، متن خطا و اینکه سایت چه کاری انجام می‌داد را برای پشتیبانی بفرستید. دسترسی phpMyAdmin برای مدیریت جدول‌های خودتان است، نه تغییر تنظیم‌های کل سرور.

در فهرست اتصال‌ها دنبال چه بگردیم؟

اتصال‌هایی با وضعیت Sleep در حال اجرای یک دستور نیستند، اما تا وقتی بازند یک جای اتصال را نگه می‌دارند. چند مورد ممکن است طبیعی باشد؛ اما تعداد زیادِ آن‌ها، به‌خصوص اگر هر بار بعد از بازدید رشد کند، می‌تواند نشانهٔ این باشد که برنامه اتصال را پس از پایان کار آزاد نمی‌کند. اتصال‌های Query طولانی هم سرنخ‌اند: افزونه یا گزارش ممکن است پرس‌وجویی اجرا کند که بیشتر از حد معمول طول می‌کشد.
زمان ستون Time را با نوع کار مقایسه کنید؛ یک پرس‌وجوی چندثانیه‌ای در گزارش سنگین با یک پرس‌وجوی تکراری چنددقیقه‌ای یکی نیست. فقط از روی نام کاربر، یک اتصال را مقصر ندانید؛ یک کاربر ممکن است چند بخش سایت را اجرا کند. برای بررسی دقیق‌تر، زمان خطا را با لاگ وب‌سرور و برنامه تطبیق دهید. راهنمای رسمی MySQL دربارهٔ خطای Too many connections همین متغیرها و راه مشاهدهٔ پردازش‌ها را توضیح می‌دهد.

علت‌های پرتکرار را یکی‌یکی جدا کنید

در وردپرس ببینید خطا پس از روشن‌کردن افزونهٔ تازه، گزارش‌گیری، بازدید ربات یا ساعت بکاپ رخ می‌دهد یا نه. در برنامهٔ اختصاصی، سقف اتصال‌های pool هر worker را با تعداد workerها ضرب کنید. برای مثال، پنج پردازش که هرکدام تا بیست اتصال باز می‌کنند می‌توانند صد اتصال درخواست کنند. این عدد باید با سقف پایگاه داده و مصرف باقی برنامه‌ها مقایسه شود.
اگر خطا فقط هنگام گزارش سنگین یا import رخ می‌دهد، کار را در محیط کم‌ترافیک و با اندازهٔ کوچک‌تر تکرار کنید. اگر تعداد Sleep بعد از پایان کار کاهش نمی‌یابد، برنامه باید اتصال را در پایان هر درخواست آزاد کند. زیادکردن مدت نگهداری اتصال برای سایت کم‌ترافیک ممکن است جای خالی کمتری برای مشتری‌های واقعی بگذارد.

چه زمانی سقف را بالا ببریم؟

مدیر سرور می‌تواند max_connections را بالا ببرد، اما هر اتصال حافظه و منابعی مصرف می‌کند. اگر برنامه اتصال‌ها را نشت می‌دهد، سقف بیشتر فقط زمان رسیدن به خطا را طولانی‌تر می‌کند و ممکن است حافظهٔ سرور را پر کند. از مدیر پایگاه داده بخواهید همزمان بیشترین تعداد اتصال، مصرف RAM و پرس‌وجوهای کند را بررسی کند. در هاست اشتراکی، مشتری معمولاً نباید فایل پیکربندی MySQL را ویرایش کند یا سرویس را راه‌اندازی مجدد کند.
قطع اتصال‌های Sleep با KILL هم راه‌حل عمومی نیست. ممکن است آن اتصال متعلق به سبد خرید یا یک وظیفهٔ در حال انجام باشد. اگر مدیر پس از بررسی تصمیم به قطع یک اتصال گرفت، باید مطمئن شود آن درخواست قابل تکرار است و دادهٔ میانی به جا نمی‌گذارد. راه امن‌تر، اصلاح برنامه‌ای است که اتصال را باز کرده است.

بعد از اصلاح، رشد را اندازه بگیرید

پس از تنظیم pool یا اصلاح افزونه، مقدار Threads_connected را در زمان عادی و ساعت شلوغ دوباره بخوانید. انتظار داریم تعداد اتصال‌ها پس از پایان بار کاری پایین بیاید، نه اینکه دائماً بالا برود. یک فرم سایت، صفحهٔ محصول و مسیر سفارش را هم امتحان کنید. اگر خطا فقط با بار واقعی برمی‌گردد، نمودار و زمان را نگه دارید؛ یک عدد لحظه‌ای برای نتیجه‌گیری کافی نیست.
قبل از هر تغییر پایگاه داده، نسخهٔ پشتیبان تازه داشته باشید. راهنمای پشتیبان‌گیری پایگاه داده با phpMyAdmin روش ساخت نسخهٔ جدا را دارد. اگر SHOW نشان می‌دهد اتصال‌ها زیر سقف‌اند ولی پیام ادامه دارد، ممکن است برنامه به پایگاه دادهٔ دیگری وصل می‌شود یا خطای ثبت‌شده قدیمی است؛ زمان جدید بگیرید و آن را با پشتیبانی تطبیق دهید.
اتصال باز با پرس‌وجوی در حال اجرا یکی نیست. ستون Command و State کمک می‌کنند بفهمید اتصال منتظر است یا کار می‌کند؛ بااین‌حال، در هاست اشتراکی فهرست ممکن است ناقص باشد. خروجی را زمان‌دار نگه دارید و با زمان خطا مقایسه کنید. اگر اتصال‌ها در ساعت کم‌ترافیک هم دائماً به سقف نزدیک‌اند، لاگ درخواست‌ها را در همان بازه ببینید؛ retry حلقه‌ای می‌تواند تعداد اتصال‌ها را سریع بالا ببرد.
در برنامه‌هایی که connection pool دارند، سقف هر pool را در همهٔ workerها جمع کنید. اگر سه worker هرکدام تا بیست اتصال باز می‌کنند، برنامه ممکن است شصت اتصال بخواهد. با زیادشدن سرورها یا workerها، تنظیم قبلی دیگر مناسب نیست. این حساب را با مدیر برنامه و پایگاه داده انجام دهید؛ مقدار یک سایت کوچک برای فروشگاه پرترافیک نسخهٔ آماده نیست.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام