ابزارهای رایگان · گزارش عملکرد سرور

بهینه سازی سرور با گزارش رایگان عملکرد

بهینه‌سازی سرور وقتی نتیجه می‌دهد که گلوگاه واقعی پیدا شده باشد، پیش از آنکه هزینه ارتقای CPU یا رم پرداخت شود. این گزارش را ابزار خودکار تولید نمی‌کند: کارشناس کانفیگ سرور داده‌های عملکرد سرور شما را بررسی می‌کند و گزارشی رایگان از علت کندی و اقدامات بهینه‌سازی سرور به ترتیب اولویت تحویل می‌دهد.

Linux · cPanel · DirectAdmin LiteSpeed · Nginx · Apache · PHP-FPM MySQL/MariaDB · Redis
چه زمانی به این گزارش نیاز دارید؟

علت کند شدن سرور: نشانه‌هایی که اغلب اشتباه خوانده می‌شوند

مصرف بالای CPU و load average بالا

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 یا مهاجرت. بعد از پیدا شدن گلوگاه، تغییرها را یکی‌یکی اعمال کنید و اثر هر کدام را دوباره اندازه بگیرید. اگر چند تنظیم هم‌زمان عوض شود، معلوم نمی‌شود کدام اثر داشته و کدام کندی تازه‌ای ساخته است.

خواندن نشانه‌های CPU، رم و دیسک

load average را بر تعداد هسته‌ها تقسیم کنید. اگر نتیجه بالاتر از ۱ است و CPU هم مشغول است، کمبود پردازنده واقعی است؛ اگر load و iowait هر دو بالا هستند، فرایندها منتظر دیسک‌اند و iostat -x زمان پاسخ دیسک را نشان می‌دهد. در سرور مجازی به steal time هم نگاه کنید، چون عدد بالای آن یعنی میزبان فیزیکی شلوغ است و تنظیمات داخل سرور شما آن را درست نمی‌کند.

در خروجی free ستون available مهم‌تر از free است، چون لینوکس رم بیکار را برای کش فایل‌ها به کار می‌گیرد و هنگام نیاز آزادش می‌کند. نشانه کمبود رم، فعالیت مداوم swap در ستون‌های si و so خروجی vmstat و پیام OOM Killer در dmesg است. پر شدن inode هم با df -i پیدا می‌شود؛ ممکن است دیسک فضای خالی داشته باشد، ولی میلیون‌ها فایل کش یا سشن اجازه ساخت فایل تازه را ندهند.

وب‌سرور، PHP-FPM و دیتابیس

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، و دیتابیس. هدف پیدا کردن اولین گلوگاه است و پیشنهادها به همان گلوگاه مربوط‌اند.

تحویل گزارش و پیشنهاد

گزارش مکتوب با اقدامات اولویت‌بندی‌شده و برآورد اثر هر اقدام تحویل می‌گیرید. اجرای آن را خودتان انجام می‌دهید یا به‌صورت خدمت پولی به تیم کانفیگ سرور می‌سپارید.

درخواست گزارش رایگان

برای درخواست گزارش چه اطلاعاتی بفرستید؟

درخواست فرم ندارد و یک پیام در تلگرام کافی است. هرچه نشانه‌ها و زمان کندی دقیق‌تر باشند، تحلیل زودتر به علت اصلی می‌رسد.

01

مشخصات سرور

تعداد هسته، رم و نوع دیسک؛ سرور مجازی یا اختصاصی بودن و نام ارائه‌دهنده.

02

نرم‌افزارهای روی سرور

سیستم‌عامل، کنترل‌پنل، وب‌سرور، نسخه PHP و دیتابیس و تعداد تقریبی سایت‌ها.

03

نشانه و زمان کندی

پیام‌های خطا، ساعات اوج و تغییرات اخیر مثل نصب افزونه، کمپین تبلیغاتی یا ارتقای نسخه.

04

حریم خصوصی: رمز عبور نفرستید

برای گزارش اولیه به رمز root یا کنترل‌پنل نیازی نیست. پیش از ارسال لاگ‌ها، ایمیل و اطلاعات مشتریان را حذف کنید؛ داده‌های شما فقط برای تهیه همین گزارش استفاده می‌شود.

محدوده گزارش رایگان و اجرای پولی بهینه‌سازی

شامل این خدمت

  • بررسی داده‌های CPU، رم، swap، دیسک و شبکه
  • مرور تنظیمات وب‌سرور، PHP-FPM و OPcache
  • مرور تنظیمات اصلی دیتابیس و کوئری‌های کند
  • تعیین اولین گلوگاه و فهرست اقدامات به ترتیب اثر
  • نظر صریح درباره اینکه ارتقای منابع لازم است یا نه

خارج از این خدمت

سوالات متداول

پرسش‌های رایج درباره بهینه‌سازی و افزایش سرعت سرور

بهینه سازی سرور چیست و از کجا شروع می‌شود؟

بهینه‌سازی سرور یعنی تنظیم سیستم‌عامل، وب‌سرور، PHP و دیتابیس تا از منابع موجود بیشترین کار گرفته شود. شروع آن اندازه‌گیری است؛ تا گلوگاه مشخص نشود، هر تغییری ممکن است بی‌اثر یا حتی مضر باشد.

رایج‌ترین علت کند شدن سرور چیست؟

در سرورهای وب، رایج‌ترین علت‌ها کوئری‌های کند دیتابیس، کمبود رم و استفاده از swap، دیسک کند یا پرشده و تنظیم نبودن تعداد فرایندهای PHP است. در سرور مجازی، steal time بالا هم نشان می‌دهد سرور میزبان شلوغ است و مشکل از تنظیمات شما نیست.

load average چند باشد زیاد است؟

load average را بر تعداد هسته‌ها تقسیم کنید. نتیجه نزدیک ۱ یعنی ظرفیت کامل و بالاتر از آن یعنی صف انتظار. در لینوکس، فرایندهایی که منتظر دیسک‌اند هم در load شمرده می‌شوند؛ پس load بالا همیشه به معنی کمبود CPU نیست.

برای افزایش سرعت سرور مجازی، بهینه‌سازی بهتر است یا ارتقای منابع؟

اول بهینه‌سازی. در بسیاری از سرورها کندی از یک کوئری بدون ایندکس یا تنظیم اشتباه PHP-FPM است و ارتقا فقط هزینه را بیشتر می‌کند. اگر گزارش نشان دهد منابع واقعاً کم است، ارتقا را با عدد مشخص پیشنهاد می‌کنیم.

آیا گزارش عملکرد سرور واقعاً رایگان است؟

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

برای بهینه سازی سرور لینوکس باید دسترسی root بدهم؟

برای گزارش رایگان نه؛ خروجی دستورات فقط‌خواندنی و لاگ‌ها معمولاً کافی است. اگر اجرای تغییرات را بسپارید، دسترسی لازم با روشی امن و موقت هماهنگ می‌شود و پس از پایان کار قابل حذف است.

آیا تست سرعت سرور همان بررسی عملکرد است؟

خیر. تست‌هایی مثل speedtest فقط سرعت اتصال اینترنت سرور را اندازه می‌گیرند. سرور ممکن است پهنای باند خوبی داشته باشد و باز هم به‌خاطر دیسک، رم یا دیتابیس، صفحه‌ها را چند ثانیه دیر تحویل دهد.

پیش از ارتقای سرور، گلوگاه واقعی را پیدا کنید

مشخصات سرور و نشانه‌های کندی را در تلگرام بفرستید تا کارشناس کانفیگ سرور داده‌ها را بررسی کند و گزارش رایگان عملکرد و پیشنهادهای رفع کندی سرور را برای شما آماده کند.