CPU، RAM، I/O و Entry Process در هاست چیست؟

پاسخ کوتاه: منابع هاست دقیقاً چه چیزی را محدود می‌کنند؟

منابع هاست مشخص می‌کنند یک حساب میزبانی در هر لحظه چه مقدار پردازش، حافظه و عملیات ذخیره‌سازی در اختیار دارد و چند درخواست پویا را می‌تواند هم‌زمان پاسخ دهد. CPU سرعت انجام محاسبات، RAM فضای کاری پردازش‌ها، I/O نرخ خواندن و نوشتن داده، IOPS تعداد عملیات دیسک و Entry Process تعداد درخواست‌های پویای هم‌زمان واردشده به حساب را کنترل می‌کنند.

فضای دیسک بالا به‌تنهایی به معنی هاست قدرتمند نیست. ممکن است یک پلن ۵۰ گیگابایت فضا داشته باشد، اما به‌دلیل CPU، RAM یا I/O پایین در اجرای وردپرس و فروشگاه کند باشد.

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

نقشه سریع منابع هاست

منبع	چه چیزی را کنترل می‌کند؟	نشانه معمول کمبود
CPU	محاسبات PHP، افزونه‌ها، کوئری‌ها و پردازش‌های پس‌زمینه	کندی پاسخ، صف شدن پردازش یا Throttling
RAM	حافظه فعال PHP، وب‌سرور، کش و پردازش‌های حساب	خطای کمبود حافظه، توقف پردازش یا خطای 500/503
I/O	حجم داده‌ای که در هر ثانیه از دیسک خوانده یا روی آن نوشته می‌شود	کندی آپلود، بکاپ، استخراج فایل و بارگذاری داده
IOPS	تعداد عملیات کوچک خواندن و نوشتن در هر ثانیه	کندی سایت‌های دارای فایل‌های کوچک و عملیات متعدد
Entry Process	درخواست‌های پویای هم‌زمانی که وارد پردازش حساب می‌شوند	خطای 508 یا رد شدن درخواست در پیک
NPROC	تعداد کل پردازش‌ها یا Threadهای مجاز حساب	اجرا نشدن Cron، SSH یا پردازش جدید
Inode	تعداد فایل و پوشه قابل نگهداری	ناتوانی در ساخت فایل، ایمیل یا بکاپ با وجود فضای خالی

این منابع به‌صورت مستقل عمل نمی‌کنند. برای مثال، افزونه بکاپ ممکن است هم‌زمان CPU، RAM، I/O و IOPS را مصرف کند. فروشگاه نیز هنگام جست‌وجو، افزودن به سبد و ثبت سفارش علاوه بر CPU به دیتابیس و دیسک فشار وارد می‌کند. به همین دلیل تشخیص مشکل فقط با نگاه کردن به یک نمودار ممکن نیست.

CPU در هاست چیست؟

CPU دستورهای برنامه را اجرا می‌کند. هر بار که PHP یک صفحه پویا می‌سازد، وردپرس افزونه‌ای را اجرا می‌کند، دیتابیس نتیجه‌ای را آماده می‌کند یا Cron Job عملیاتی انجام می‌دهد، زمان پردازنده مصرف می‌شود. صفحات کش‌شده معمولاً CPU بسیار کمتری از صفحه‌ای نیاز دارند که در هر درخواست از ابتدا ساخته می‌شود.

عبارت ۱۰۰٪ CPU چه معنایی دارد؟

تفسیر درصد CPU به سیستم محدودکننده بستگی دارد. در سامانه‌های رایج LVE، عدد ۱۰۰٪ معمولاً معادل ظرفیت یک هسته پردازنده در نظر گرفته می‌شود؛ اما شرکت میزبان ممکن است واحد دیگری ارائه کند یا سهم پردازنده را با cgroups و سیاست زمان‌بندی متفاوت اعمال کند. بنابراین از پشتیبانی بپرسید «۱۰۰٪ در این پلن دقیقاً معادل چند هسته یا چه سهمی است؟».

چه چیزهایی CPU را بالا می‌برند؟

افزونه‌ها و قالب‌های سنگین یا دارای حلقه و کوئری ناکارآمد.
نبود Page Cache و اجرای کامل PHP برای هر بازدید.
ربات‌های مخرب، اسکن‌ها و درخواست‌های تکراری به صفحات پویا.
WP-Cron پرتکرار، ساخت تصویر، ایمپورت محصول و تولید گزارش.
جست‌وجوی پیچیده، فیلتر محصول و کوئری‌های بدون ایندکس مناسب.
ارسال ایمیل انبوه یا Queueهایی که بدون کنترل هم‌زمانی اجرا می‌شوند.

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

RAM در هاست چیست؟

RAM فضای کاری موقت پردازش‌هاست. PHP هنگام اجرای کد، MariaDB برای پردازش داده، Redis برای نگهداری Object Cache و ابزارهایی مانند Composer یا WP-CLI برای عملیات خود از حافظه استفاده می‌کنند. با پایان پردازش، بخش زیادی از حافظه آزاد می‌شود؛ اما چند پردازش هم‌زمان می‌توانند مصرف را به‌سرعت جمع کنند.

پلنی با ۱ گیگابایت RAM الزاماً اجازه نمی‌دهد یک پردازش PHP تمام آن را مصرف کند. ممکن است محدودیت حافظه کل حساب، محدودیت هر پردازش و مقدار memory_limit در PHP هم‌زمان وجود داشته باشند. کوچک‌ترین محدودیت مؤثر می‌تواند اجرای درخواست را متوقف کند.

نشانه‌های کمبود RAM

پیام Allowed memory size exhausted در PHP.
خطای 500 یا 503 هنگام ویرایش، ایمپورت یا تهیه بکاپ.
توقف ناگهانی WP-CLI، Composer یا اسکریپت‌های طولانی.
کشته شدن پردازش به‌دلیل عبور از سقف حافظه حساب.
کندی شدید هنگام افزایش تعداد درخواست‌های هم‌زمان.

حافظه بیشتر زمانی مفید است که برنامه واقعاً به آن نیاز داشته باشد. افزایش بی‌دلیل memory_limit می‌تواند اجازه دهد یک افزونه معیوب حافظه بیشتری مصرف کند و کل حساب را زودتر به سقف برساند. مقدار مناسب باید بر اساس نوع عملیات، تعداد پردازش‌های هم‌زمان و گزارش مصرف تعیین شود.

تفاوت RAM هاست با PHP memory_limit

محدودیت	دامنه اثر	مثال
RAM حساب	مجموع حافظه پردازش‌های تحت حساب	تمام پردازش‌های PHP، Cron و ابزارهای کاربر روی هم
PHP memory_limit	حد حافظه یک اجرای PHP	یک درخواست وردپرس یا یک عملیات ایمپورت
محدودیت وب‌سرور/Handler	حافظه Process یا Worker مربوط به PHP	سقف نرم یا سخت LSPHP در LiteSpeed

فرض کنید RAM کل حساب ۲ گیگابایت و memory_limit هر پردازش ۵۱۲ مگابایت باشد. چهار پردازش سنگین می‌توانند در شرایط خاص بخش بزرگی از RAM حساب را مصرف کنند. در مقابل، اگر RAM حساب ۲ گیگابایت باشد اما memory_limit روی ۱۲۸ مگابایت قرار گیرد، یک عملیات که به ۲۰۰ مگابایت نیاز دارد پیش از رسیدن حساب به سقف متوقف می‌شود.

بنابراین در تیکت پشتیبانی فقط نگویید «RAM پلن چقدر است؟». مقدار حافظه کل، محدودیت هر پردازش PHP و امکان تغییر آن را جداگانه بپرسید.

I/O در هاست چیست؟

I/O یا Input/Output سرعت انتقال داده میان پردازش و فضای ذخیره‌سازی را نشان می‌دهد و معمولاً با مگابایت بر ثانیه بیان می‌شود. خواندن فایل‌های وردپرس، نوشتن Session، استخراج ZIP، ساخت بکاپ، آپلود، تولید Thumbnail و خواندن فایل‌های لاگ همگی I/O مصرف می‌کنند.

محدودیت I/O پایین ممکن است CPU و RAM آزاد داشته باشد، اما سایت همچنان کند بماند؛ زیرا پردازش برای دریافت داده از دیسک منتظر است. این وضعیت در بکاپ، اسکن بدافزار، ایمپورت محصول و سایت‌هایی با فایل‌های فراوان بیشتر دیده می‌شود.

I/O با سرعت اسمی SSD یا NVMe یکی نیست

نوع دیسک ظرفیت زیرساخت را مشخص می‌کند، ولی سهم قابل استفاده هر حساب را سیاست میزبان تعیین می‌کند. وجود NVMe به‌تنهایی تضمین نمی‌کند که پلن شما I/O نامحدود یا بسیار بالا داشته باشد. از طرف دیگر، عدد I/O بالا روی سروری با تراکم یا صف ذخیره‌سازی نامناسب نیز لزوماً تجربه مطلوبی ایجاد نمی‌کند.

IOPS چیست و چه فرقی با I/O دارد؟

I/O حجم داده در ثانیه را اندازه می‌گیرد، اما IOPS تعداد عملیات خواندن و نوشتن در ثانیه است. انتقال یک فایل بزرگ ممکن است I/O زیادی مصرف کند و تعداد عملیات کمی داشته باشد؛ در مقابل، خواندن هزاران فایل کوچک یا ایجاد فایل‌های Session می‌تواند IOPS را بالا ببرد، حتی اگر حجم کل داده زیاد نباشد.

سناریو	منبع حساس‌تر	توضیح
دانلود یا کپی فایل حجیم	I/O	حجم زیادی از داده به‌صورت پیوسته منتقل می‌شود.
لود هزاران فایل کوچک	IOPS	تعداد عملیات بیشتر از حجم هر عملیات اهمیت دارد.
استخراج آرشیو بزرگ	I/O و IOPS	هم داده زیاد و هم ساخت فایل‌های متعدد درگیر است.
بکاپ کامل حساب	CPU، I/O و IOPS	فشرده‌سازی و خواندن فایل‌ها هم‌زمان انجام می‌شود.

Entry Process چیست؟

Entry Process یا EP در سیستم‌هایی که این شاخص را ارائه می‌کنند، تعداد درخواست‌های پویای هم‌زمانی است که وارد محیط پردازشی حساب شده‌اند. این عدد با تعداد بازدیدکنندگان آنلاین، تعداد تب‌های باز یا تعداد کل درخواست‌های HTTP برابر نیست. یک کاربر می‌تواند چند درخواست ایجاد کند و بسیاری از فایل‌های استاتیک یا پاسخ‌های کش‌شده ممکن است مسیر متفاوتی داشته باشند.

EP=20 به این معنی نیست که سایت فقط ۲۰ بازدیدکننده را تحمل می‌کند. مدت اجرای درخواست مهم است: اگر هر درخواست سریع تمام شود، تعداد زیادی کاربر می‌توانند در طول یک دقیقه سرویس بگیرند؛ اما درخواست‌های کند، ظرفیت هم‌زمان را برای مدت بیشتری اشغال می‌کنند.

چه چیزهایی Entry Process را اشغال می‌کنند؟

صفحات PHP بدون کش یا با کوئری‌های کند.
درخواست‌های AJAX، REST API و admin-ajax.php.
سبد خرید، پرداخت، حساب کاربری و سایر صفحات شخصی‌سازی‌شده.
ربات‌هایی که چند URL پویا را هم‌زمان فراخوانی می‌کنند.
درخواست‌هایی که منتظر API خارجی، دیتابیس یا دیسک می‌مانند.

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

NPROC یا تعداد پردازش چیست؟

NPROC سقف تعداد Process و در برخی پیاده‌سازی‌ها Threadهای فعال تحت حساب را مشخص می‌کند. پردازش‌های PHP، Cron Job، SSH، WP-CLI، Composer و ابزارهای پس‌زمینه می‌توانند در این شمارش نقش داشته باشند. EP فقط ورودی‌های وب را توصیف می‌کند، اما NPROC دامنه گسترده‌تری دارد.

اگر NPROC پر شود، حتی با آزاد بودن CPU ممکن است پردازش جدید ساخته نشود. نتیجه می‌تواند اجرا نشدن Cron، خطای fork failed، مشکل در SSH یا پاسخ ندادن درخواست جدید باشد. پردازش‌های گیرکرده و Cronهای هم‌پوشان از علت‌های رایج مصرف غیرعادی این منبع هستند.

Inode، فضای دیسک و پهنای باند

فضای دیسک حجم کل داده را محدود می‌کند، اما Inode تعداد فایل و پوشه را. یک حساب ممکن است فقط چند گیگابایت مصرف داشته باشد ولی به‌دلیل میلیون‌ها فایل کش، ایمیل یا Session به سقف Inode برسد. در این حالت ساخت فایل جدید، دریافت ایمیل، آپدیت وردپرس یا تهیه بکاپ با مشکل روبه‌رو می‌شود.

پهنای باند نیز حجم انتقال داده در یک دوره، معمولاً ماهانه، است و با I/O فرق دارد. I/O سرعت کار با دیسک داخل سرور را محدود می‌کند؛ پهنای باند میزان داده خروجی و ورودی شبکه را. برای سایت دانلود یا تصاویر حجیم، هر دو معیار اهمیت دارند.

کش‌های منقضی، Sessionها و Thumbnailهای بلااستفاده را دوره‌ای پاک‌سازی کنید.
صندوق‌های ایمیل و پوشه Spam را در محاسبه Inode فراموش نکنید.
بکاپ را داخل همان حساب به‌صورت دائمی نگه ندارید؛ هم فضا و هم Inode مصرف می‌کند.
تعداد فایل را همراه با حجم دیسک در پنل پایش کنید.

گلوگاه چگونه بین منابع جابه‌جا می‌شود؟

سرعت سایت به ضعیف‌ترین حلقه زنجیره وابسته است. افزایش RAM مشکل I/O پایین را حل نمی‌کند و CPU بیشتر نمی‌تواند درخواست‌هایی را که منتظر API خارجی هستند سریع کند. حتی کش نیز همه صفحات را پوشش نمی‌دهد؛ سبد خرید، ورود، مدیریت و API معمولاً به پردازش پویا نیاز دارند.

مشاهده	احتمال‌های اصلی	بررسی بعدی
TTFB بالا فقط روی صفحات پویا	CPU، دیتابیس، EP یا کد کند	APM، لاگ Slow Query و زمان اجرای PHP
بکاپ و استخراج بسیار کند	I/O، IOPS یا CPU	نمودار مصرف در زمان عملیات
خطا هنگام ایمپورت	RAM، PHP memory_limit یا Timeout	لاگ PHP و محدودیت هر پردازش
خطا فقط در پیک ترافیک	EP، NPROC، CPU یا Worker	Faultها و تعداد درخواست هم‌زمان
ناتوانی در ساخت فایل با فضای خالی	Inode یا مجوز فایل	تعداد فایل و Error Log

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

خیر. ظرفیت به نوع سایت، کش، افزونه‌ها، کاربران هم‌زمان، عملیات پس‌زمینه و کیفیت کد وابسته است. دو سایت با روزانه ده هزار بازدید می‌توانند مصرف کاملاً متفاوتی داشته باشند؛ یکی محتوای کش‌شده ارائه می‌دهد و دیگری برای هر کاربر جست‌وجو، سبد خرید و درخواست API اجرا می‌کند.

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

راهنمای نسبی بر اساس نوع پروژه

نوع سایت	منابع حساس‌تر	چرا؟
سایت شرکتی کش‌شده	پایداری، I/O مناسب و RAM پایه	بیشتر صفحات قابل کش هستند و پردازش پویا محدود است.
وبلاگ پرترافیک	CPU، EP و کش صفحه	پیک بازدید و ربات‌ها می‌توانند درخواست هم‌زمان ایجاد کنند.
وردپرس با صفحه‌ساز	RAM و CPU	ویرایش و تولید صفحه می‌تواند حافظه و پردازش بیشتری بخواهد.
فروشگاه ووکامرس	CPU، RAM، EP، دیتابیس و I/O	سبد خرید و حساب کاربری قابل کش کامل نیستند.
سایت فایل و دانلود	فضا، پهنای باند، I/O و Inode	انتقال فایل و تعداد داده‌ها نقش اصلی دارند.

چطور مصرف و Fault منابع را بخوانیم؟

نمودار Usage مقدار مصرف را نشان می‌دهد و Fault ثبت می‌کند که چند بار حساب به محدودیت رسیده است. میانگین پایین ممکن است پیک کوتاه اما مهم را پنهان کند؛ بنابراین بازه زمانی مشکل را با نمودار مقایسه کنید. زمان ثبت سفارش، انتشار کمپین، اجرای بکاپ و Cronهای سنگین را یادداشت کنید تا الگوی مصرف مشخص شود.

زمان دقیق کندی یا خطا را ثبت کنید.
CPU، RAM، I/O، EP و NPROC را در همان بازه بررسی کنید.
Fault هر منبع را از مصرف عادی جدا کنید.
Error Log، لاگ PHP و در صورت دسترسی Slow Query را تطبیق دهید.
عملیات هم‌زمان مانند بکاپ، اسکن، Cron یا ایمپورت را بررسی کنید.
پس از اصلاح، همان سناریو را دوباره تست و نتیجه را مقایسه کنید.

یک Fault منفرد در زمان عملیات مدیریتی الزاماً نیاز به ارتقا ندارد. Fault مکرر در بازدید عادی، خطای کاربر یا افت فروش نشانه‌ای است که باید جدی بررسی شود.

نمایش منابع در cPanel و تفاوت زیرساخت‌ها

cPanel خود کنترل‌پنل مدیریت حساب است و روش محدودسازی منابع می‌تواند توسط اجزای دیگری انجام شود. در سرورهای CloudLinux، بخش Resource Usage معمولاً CPU، Memory و Entry Process را نمایش می‌دهد. در معماری‌های دیگر ممکن است محدودیت‌ها با cgroups، کانتینر وب‌سرور یا ابزار اختصاصی شرکت میزبان اعمال و از پنل دیگری گزارش شوند.

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

۱۲ سؤال درباره منابع که قبل از خرید باید بپرسید

CPU پلن با چه واحدی اعلام شده و ۱۰۰٪ معادل چیست؟
RAM کل حساب چقدر است و محدودیت هر پردازش PHP چقدر است؟
مقدار memory_limit قابل تغییر است؟ سقف مجاز آن چیست؟
I/O با چه واحدی و در چه بازه‌ای محدود می‌شود؟
سقف IOPS چقدر است و آیا Burst کوتاه‌مدت وجود دارد؟
Entry Process و NPROC هرکدام چقدرند و دقیقاً چه چیزی را می‌شمارند؟
سقف Inode و نحوه مشاهده تعداد فایل چیست؟
در صورت رسیدن به محدودیت، درخواست کند می‌شود یا خطا برمی‌گردد؟
آیا Faultها و نمودار مصرف برای کاربر قابل مشاهده‌اند؟
ارتقای منابع در همان حساب و بدون تغییر DNS انجام می‌شود؟
وب‌سرور، PHP Handler و سیستم کش سرویس چیست؟
آیا پشتیبانی در تحلیل مصرف غیرعادی و تشخیص افزونه یا Cron معیوب کمک می‌کند؟

پاسخ دقیق به این سؤال‌ها ارزش بیشتری از عبارت‌های کلی مانند «منابع بالا» یا «هاست پرقدرت» دارد. برای مقایسه عملی‌تر، راهنمای خرید هاست اشتراکی ایران را نیز مطالعه کنید.

اشتباه‌های رایج در مقایسه منابع هاست

مقایسه فقط بر اساس فضا: فضای بیشتر لزوماً CPU، RAM یا I/O بیشتر ایجاد نمی‌کند.
یکی دانستن EP با تعداد کاربر: زمان پردازش و کش روی ظرفیت واقعی اثر مستقیم دارند.
یکی دانستن RAM با memory_limit: این دو محدودیت دامنه متفاوتی دارند.
اعتماد به نام NVMe بدون سهم حساب: نوع دیسک و محدودیت I/O باید جداگانه بررسی شوند.
نادیده گرفتن Fault: متوسط مصرف بدون تعداد برخورد با سقف تصویر ناقصی می‌دهد.
ارتقای فوری بدون عیب‌یابی: کد یا Cron معیوب می‌تواند پلن قوی‌تر را نیز پر کند.
تست فقط در حالت لاگ‌اوت: پنل مدیریت، سبد خرید و API الگوی مصرف متفاوتی دارند.
خرید ظرفیت بسیار بزرگ از ابتدا: منابع بلااستفاده به‌تنهایی سرعت سایت را افزایش نمی‌دهند.

جمع‌بندی: منابع را به‌صورت یک سیستم ببینید

CPU سرعت محاسبه، RAM فضای کاری، I/O حجم انتقال دیسک، IOPS تعداد عملیات، EP هم‌زمانی درخواست‌های پویا و NPROC تعداد پردازش‌ها را کنترل می‌کنند. Inode، فضای دیسک و پهنای باند نیز محدودیت‌های جداگانه‌ای هستند. انتخاب درست زمانی انجام می‌شود که همه این عددها با نوع سایت و رفتار واقعی آن سنجیده شوند.

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

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