مصرف بالای CPU و load average بالا
load average را باید با تعداد هستهها مقایسه کرد؛ روی سرور ۴ هستهای، عدد ۴ یعنی ظرفیت کامل. اگر load بالاست اما CPU بیکار است، فرایندها معمولاً منتظر دیسکاند و ارتقای CPU در این حالت کمکی نمیکند.
بهینهسازی سرور وقتی نتیجه میدهد که گلوگاه واقعی پیدا شده باشد، پیش از آنکه هزینه ارتقای CPU یا رم پرداخت شود. این گزارش را ابزار خودکار تولید نمیکند: کارشناس کانفیگ سرور دادههای عملکرد سرور شما را بررسی میکند و گزارشی رایگان از علت کندی و اقدامات بهینهسازی سرور به ترتیب اولویت تحویل میدهد.
load average را باید با تعداد هستهها مقایسه کرد؛ روی سرور ۴ هستهای، عدد ۴ یعنی ظرفیت کامل. اگر load بالاست اما CPU بیکار است، فرایندها معمولاً منتظر دیسکاند و ارتقای CPU در این حالت کمکی نمیکند.
لینوکس رم خالی را برای کش فایلها استفاده میکند، پس «پر بودن رم» در خروجی free لزوماً مشکل نیست. نشانه واقعی، فعالیت مداوم swap و فرایندهایی است که OOM Killer متوقف کرده؛ مثلاً MySQL که بیدلیل ریاستارت میشود.
خطای 502 یا 503 همراه با پیام server reached pm.max_children در لاگ PHP-FPM یعنی درخواستها پشت صف ماندهاند. بالا بردن این عدد بدون رم کافی، سرور را به swap میکشاند و کندی را بدتر میکند.
گزارش مکتوب است و برای هر بخش میگوید چه دیدیم، چه معنایی دارد و چه کاری پیشنهاد میکنیم. جدول زیر ساختار گزارش را با یافتههای رایج نشان میدهد؛ یافتههای واقعی به سرور شما بستگی دارد.
| بخش | چه چیزی بررسی میشود | نمونه یافته | نمونه پیشنهاد |
|---|---|---|---|
| پردازنده | load average نسبت به هستهها، steal time در سرور مجازی و فرایندهای پرمصرف | steal time بالا در ساعات شلوغ | پیگیری با ارائهدهنده یا تغییر میزبان، پیش از خرید پلن بزرگتر |
| حافظه و swap | رم در دسترس، فعالیت swap و رویدادهای OOM | متوقف شدن MySQL توسط OOM Killer | تنظیم سهم رم PHP و buffer pool دیتابیس |
| دیسک | iowait، زمان پاسخ دیسک با iostat، فضای آزاد و inode | پر شدن دیسک با لاگ و بکاپهای قدیمی | چرخش لاگ و انتقال بکاپ به فضای جداگانه |
| وبسرور و PHP | تنظیمات LiteSpeed، Nginx یا Apache، PHP-FPM، OPcache و زمان پاسخ اولیه (TTFB) | OPcache غیرفعال یا با حافظه ناکافی | تنظیم OPcache و کش آبجکت Redis |
| دیتابیس | slow query log، اتصالهای همزمان و innodb_buffer_pool_size | کوئری بدون ایندکس در جستوجوی محصولات | افزودن ایندکس یا بازنویسی کوئری |
| ترافیک مزاحم | درخواست رباتها و تلاشهای brute-force که منابع را مصرف میکنند | هزاران درخواست به xmlrpc.php یا wp-login.php | محدودسازی نرخ درخواست و مسدودسازی در فایروال |
تست سرعت سرور با ابزارهایی مثل speedtest فقط پهنای باند اینترنت سرور را میسنجد. برای بهینه سازی سرور مجازی یا اختصاصی باید زمان پاسخ برنامه و مصرف منابع را اندازه گرفت و این گزارش همینها را بررسی میکند.
بهینهسازی سرور یعنی از سختافزاری که دارید کار بیشتری بگیرید. روی بیشتر سرورهای وب، کندی از یک گلوگاه مشخص میآید: دیسکی که دیر جواب میدهد، رمی که به swap رسیده، PHP-FPMی که درخواستها را در صف نگه داشته یا کوئریای که ایندکس ندارد. تا این گلوگاه پیدا نشود، تغییر تنظیمات یا خرید پلن بزرگتر معمولاً اثر کمی دارد. گزارش رایگان هم لایهها را به همان ترتیبی بررسی میکند که در این راهنما آمده است.
داده را در ساعتی بگیرید که سرور کند است. خروجی uptime، free -m، iostat -x و df -h در ساعت اوج چیزهایی را نشان میدهد که همان دستورها در نیمهشب نشان نمیدهند. اگر ابزار پایش دارید، نمودار چند روز اخیر CPU، رم و دیسک از یک نمونه لحظهای مفیدتر است، چون الگوی تکرار را هم نشان میدهد؛ مثلاً کندیای که هر شب با شروع بکاپ آغاز میشود.
زمان تغییرهای اخیر را هم یادداشت کنید: نصب افزونه، کمپین تبلیغاتی، ارتقای نسخه PHP یا مهاجرت. بعد از پیدا شدن گلوگاه، تغییرها را یکییکی اعمال کنید و اثر هر کدام را دوباره اندازه بگیرید. اگر چند تنظیم همزمان عوض شود، معلوم نمیشود کدام اثر داشته و کدام کندی تازهای ساخته است.
load average را بر تعداد هستهها تقسیم کنید. اگر نتیجه بالاتر از ۱ است و CPU هم مشغول است، کمبود پردازنده واقعی است؛ اگر load و iowait هر دو بالا هستند، فرایندها منتظر دیسکاند و iostat -x زمان پاسخ دیسک را نشان میدهد. در سرور مجازی به steal time هم نگاه کنید، چون عدد بالای آن یعنی میزبان فیزیکی شلوغ است و تنظیمات داخل سرور شما آن را درست نمیکند.
در خروجی free ستون available مهمتر از free است، چون لینوکس رم بیکار را برای کش فایلها به کار میگیرد و هنگام نیاز آزادش میکند. نشانه کمبود رم، فعالیت مداوم swap در ستونهای si و so خروجی vmstat و پیام OOM Killer در dmesg است. پر شدن inode هم با df -i پیدا میشود؛ ممکن است دیسک فضای خالی داشته باشد، ولی میلیونها فایل کش یا سشن اجازه ساخت فایل تازه را ندهند.
pm.max_children تعیین میکند PHP-FPM حداکثر چند فرایند همزمان اجرا کند. عدد مناسب از تقسیم رمی که برای PHP کنار گذاشتهاید بر مصرف رم هر فرایند به دست میآید؛ کپی کردن این عدد از سروری با رم متفاوت یا منابع را هدر میدهد یا سرور را به swap میکشاند. OPcache کد کامپایلشده PHP را در حافظه نگه میدارد و اگر غیرفعال باشد یا حافظه کافی نداشته باشد، کد در درخواستها دوباره کامپایل میشود. برای وردپرس، کش آبجکت Redis تعداد کوئریهای تکراری به دیتابیس را کم میکند.
در دیتابیس، innodb_buffer_pool_size تعیین میکند چه مقدار از داده و ایندکسها در رم بماند و slow query log کوئریهایی را که از زمان مجاز طولانیتر اجرا میشوند فهرست میکند. رم سرور را بین دیتابیس، PHP-FPM و کش تقسیم کنید، چون اگر هر کدام جداگانه روی حداکثر تنظیم شود، مجموعشان از رم سرور بیشتر میشود. درخواست رباتها و تلاشهای brute-force روی xmlrpc.php یا wp-login.php هم منابع را مصرف میکنند و محدودسازی نرخ درخواست این بار را کم میکند. رفع فوری کندی یا کرش دیتابیس در بهینهسازی دیتابیس سرور انجام میشود.
ارتقا وقتی منطقی است که گلوگاه پیدا شده و با تنظیم برطرف نمیشود: CPU در ساعت اوج واقعاً مشغول است، رم بعد از تقسیم درست باز هم کم است یا دیسک با بار معمولی کند پاسخ میدهد. در این حالت گزارش مشخص میکند کدام منبع و به چه اندازه کم است تا هزینه صرف منبعی نشود که گلوگاه نیست. اگر steal time بالاست، پیش از خرید پلن بزرگتر موضوع را با ارائهدهنده پیگیری کنید یا میزبان را عوض کنید.
تست سرعت اینترنت سرور، مثل speedtest، در این تصمیم کمکی نمیکند، چون فقط پهنای باند را میسنجد. سرور ممکن است پهنای باند خوبی داشته باشد و باز هم بهخاطر دیسک، رم یا دیتابیس صفحهها را دیر تحویل دهد. زمان پاسخ اولیه (TTFB) و مصرف منابع در ساعت اوج معیار بهتری هستند.
گزارش رایگان است و اجرای پیشنهادها را میتوانید خودتان انجام دهید. اگر بخواهید تغییرات را به تیم کانفیگ سرور بسپارید، این کار خدمت پولی جداگانهای است که هزینهاش پیش از شروع اعلام میشود، و نگهداری مستمر سرور در مدیریت سرور لینوکس انجام میشود. برای اینکه کندی بعدی را پیش از شکایت کاربران ببینید، پایش منابع را فعال کنید؛ مانیتورینگ رایگان سرور یکی از گزینههاست.
برای گزارش اولیه رمز root یا کنترلپنل نفرستید. پیش از ارسال لاگها، ایمیل و اطلاعات مشتریان را از آنها حذف کنید.
نوع سرور، سیستمعامل، کنترلپنل، وبسرور و نشانه کندی را بنویسید؛ مثلاً «از ساعت ۲۰ تا ۲۳ سایت کند میشود» یا «بعد از نصب یک افزونه CPU پر شد».
خروجی چند دستور فقطخواندنی مثل uptime، free -m، iostat -x و df -h و بخشهایی از لاگها را با راهنمای ما میفرستید، یا اگر بخواهید دسترسی محدود و موقت میدهید. بهتر است داده در ساعت اوج گرفته شود.
دادهها لایهبهلایه بررسی میشوند: سختافزار و مجازیسازی، سیستمعامل، وبسرور و PHP، و دیتابیس. هدف پیدا کردن اولین گلوگاه است و پیشنهادها به همان گلوگاه مربوطاند.
گزارش مکتوب با اقدامات اولویتبندیشده و برآورد اثر هر اقدام تحویل میگیرید. اجرای آن را خودتان انجام میدهید یا بهصورت خدمت پولی به تیم کانفیگ سرور میسپارید.
درخواست فرم ندارد و یک پیام در تلگرام کافی است. هرچه نشانهها و زمان کندی دقیقتر باشند، تحلیل زودتر به علت اصلی میرسد.
تعداد هسته، رم و نوع دیسک؛ سرور مجازی یا اختصاصی بودن و نام ارائهدهنده.
سیستمعامل، کنترلپنل، وبسرور، نسخه PHP و دیتابیس و تعداد تقریبی سایتها.
پیامهای خطا، ساعات اوج و تغییرات اخیر مثل نصب افزونه، کمپین تبلیغاتی یا ارتقای نسخه.
برای گزارش اولیه به رمز root یا کنترلپنل نیازی نیست. پیش از ارسال لاگها، ایمیل و اطلاعات مشتریان را حذف کنید؛ دادههای شما فقط برای تهیه همین گزارش استفاده میشود.
بهینهسازی سرور یعنی تنظیم سیستمعامل، وبسرور، PHP و دیتابیس تا از منابع موجود بیشترین کار گرفته شود. شروع آن اندازهگیری است؛ تا گلوگاه مشخص نشود، هر تغییری ممکن است بیاثر یا حتی مضر باشد.
در سرورهای وب، رایجترین علتها کوئریهای کند دیتابیس، کمبود رم و استفاده از swap، دیسک کند یا پرشده و تنظیم نبودن تعداد فرایندهای PHP است. در سرور مجازی، steal time بالا هم نشان میدهد سرور میزبان شلوغ است و مشکل از تنظیمات شما نیست.
load average را بر تعداد هستهها تقسیم کنید. نتیجه نزدیک ۱ یعنی ظرفیت کامل و بالاتر از آن یعنی صف انتظار. در لینوکس، فرایندهایی که منتظر دیسکاند هم در load شمرده میشوند؛ پس load بالا همیشه به معنی کمبود CPU نیست.
اول بهینهسازی. در بسیاری از سرورها کندی از یک کوئری بدون ایندکس یا تنظیم اشتباه PHP-FPM است و ارتقا فقط هزینه را بیشتر میکند. اگر گزارش نشان دهد منابع واقعاً کم است، ارتقا را با عدد مشخص پیشنهاد میکنیم.
بله. گزارش اولیه رایگان است و تعهدی برای خرید خدمت ایجاد نمیکند. اجرای تغییرات روی سرور، اگر بخواهید به ما بسپارید، خدمت جداگانهای است که هزینه آن پیش از شروع اعلام میشود.
برای گزارش رایگان نه؛ خروجی دستورات فقطخواندنی و لاگها معمولاً کافی است. اگر اجرای تغییرات را بسپارید، دسترسی لازم با روشی امن و موقت هماهنگ میشود و پس از پایان کار قابل حذف است.
خیر. تستهایی مثل speedtest فقط سرعت اتصال اینترنت سرور را اندازه میگیرند. سرور ممکن است پهنای باند خوبی داشته باشد و باز هم بهخاطر دیسک، رم یا دیتابیس، صفحهها را چند ثانیه دیر تحویل دهد.
مشخصات سرور و نشانههای کندی را در تلگرام بفرستید تا کارشناس کانفیگ سرور دادهها را بررسی کند و گزارش رایگان عملکرد و پیشنهادهای رفع کندی سرور را برای شما آماده کند.