هاست نامحدود؛ چرا سایتم با بازدید کم قطع می‌شود؟
نامحدود بودن فضای هاست یا ترافیک، به معنی نامحدود بودن توان اجرای سایت نیست. این راهنما کمک می‌کند علت کندی و قطعی را پیدا کنید و پیش از هزینه برای ارتقا، بدانید دقیقاً چه چیزی باید تغییر کند.
هاست نامحدود خریده‌اید، هنوز بیشتر فضای آن خالی است و بازدید سایت هم چندان زیاد نیست؛ اما درست وقتی مشتری می‌خواهد محصولی ببیند یا سفارش بدهد، سایت کند می‌شود یا خطا میدهد. پشتیبانی می‌گوید «مصرف منابع شما بالاست» و شما می‌پرسید: پس آن نامحدود بودن دقیقاً چه معنایی داشت؟
پاسخ کوتاه این است: فضای نگهداری فایل، حجم انتقال اطلاعات و توان اجرای سایت سه چیز متفاوت‌اند. ممکن است یکی از آن‌ها در سرویس شما سقف مشخصی نداشته باشد، اما دیگری خیلی زود پر شود. برای پیدا کردن علت قطعی، باید بدانید محدودیت مربوط به کدام بخش است؛ تعداد بازدید و فضای خالی به‌تنهایی پاسخ را مشخص نمی‌کنند.
هاست نامحدود دقیقاً چه چیزی را نامحدود می‌کند؟
واژه «نامحدود» را باید کنار همان قابلیتی بخوانید که فروشنده معرفی کرده است. اگر در جدول سرویس نوشته شده «ترافیک نامحدود»، نمی‌توان نتیجه گرفت که پردازنده، حافظه و تعداد درخواستهای قابل پردازش هم نامحدود هستند.
حتی درباره همان قابلیت نیز باید شرایط استفاده را بخوانید. ممکن است استفاده عادی یک وب‌سایت مجاز باشد، اما نگهداری آرشیو شخصی، توزیع فایل‌های حجیم یا استفاده به‌عنوان فضای پشتیبان محدود شده باشد. پاسخ دقیق را قرارداد و شرایط همان سرویس مشخص می‌کند، نه برداشت ما از یک عبارت تبلیغاتی.
| عبارت در صفحه خرید | معمولاً درباره چه چیزی صحبت می‌کند؟ | چه چیزی را تضمین نمی‌کند؟ |
|---|---|---|
| فضای نامحدود | ظرفیت نگهداری فایل، مطابق شرایط سرویس | تعداد نامحدود فایل یا توان پردازش نامحدود |
| ترافیک نامحدود | حجم تبادل داده، مطابق شرایط استفاده | سرعت نامحدود یا پاسخ‌گویی به هر میزان مراجعه |
| تعداد سایت نامحدود | تعداد دامنه یا سایت قابل افزودن | منابع جداگانه برای تک‌تک سایت‌ها |
| ایمیل نامحدود | اغلب تعداد حساب‌های قابل ساخت | ارسال نامحدود پیام یا فضای نامحدود هر صندوق |
پیش از خرید، بپرسید هر ویژگی دقیقاً چگونه محاسبه می‌شود. اگر چند سایت روی یک حساب قرار می‌گیرند، روشن کنید آیا منابع پردازشی را با هم مصرف می‌کنند یا هرکدام سهم مستقل دارند. این تفاوت برای کسی که فروشگاه و سایت شرکتی را کنار هم میزبانی می‌کند، از تعداد دامنه‌های مجاز مهم‌تر است.
چرا فضای خالی هاست جلوی کندی سایت را نمی‌گیرد؟
یک فروشگاه واقعی را تصور کنید که انبار بزرگی دارد، اما فقط یک نفر پشت صندوق آن کار می‌کند. خالی بودن قفسه‌های انبار کمکی به کوتاه شدن صف پرداخت نمی‌کند. در سایت هم فضای دیسک محل نگهداری اطلاعات است؛ پردازنده و حافظه کار اجرای درخواست‌ها را انجام می‌دهند.
مثلاً تصویر محصول باید جایی ذخیره شود، اما محاسبه تخفیف، جست‌وجوی کالا و ثبت سفارش به پردازش نیاز دارند. ممکن است تصاویر شما فضای کمی گرفته باشند، ولی یک عملیات سنگین هنگام خرید، منابع حساب را درگیر کند. بنابراین جمله «هنوز نصف هاستم خالی است» برای رد کردن مشکل منابع کافی نیست.
محدودیت‌هایی که باید در مشخصات سرویس پیدا کنید
لازم نیست مدیر سرور باشید. کافی است معنای چند مورد را بدانید تا موقع خرید یا گفت‌وگو با پشتیبانی، سؤال دقیق‌تری بپرسید. نام و نحوه اجرای این محدودیت‌ها ممکن است میان سرویس‌ها متفاوت باشد.
پردازنده و حافظه؛ توان انجام کارهای سایت
CPU یا پردازنده، دستورهای برنامه را اجرا می‌کند. RAM یا حافظه موقت، اطلاعات مورد نیاز هنگام اجرا را نگه می‌دارد. کمبود سهم پردازنده می‌تواند اجرای کارها را طولانی کند؛ محدودیت حافظه هم ممکن است باعث ناتمام ماندن بعضی عملیات شود.
هنگام مقایسه، بپرسید عدد اعلام‌شده سقف مجاز مصرف است یا منبع تضمین‌شده. عبارت «پردازنده قدرتمند» مشخص نمی‌کند چه سهمی از آن در اختیار حساب شما قرار می‌گیرد.
سرعت دیسک و تعداد عملیات آن
I/O به حجم خواندن و نوشتن روی دیسک در واحد زمان مربوط است؛ IOPS تعداد این عملیات را اندازه می‌گیرد. بنابراین فقط دیدن نام SSD یا NVMe کافی نیست. محدودیت اعمال‌شده روی حساب نیز در سرعت کار با فایل‌ها نقش دارد.
پردازش‌های هم‌زمان
EP یا Entry Processes یکی از محدودیت‌های ورود پردازش به محیط حساب در CloudLinux است؛ نرم‌افزاری که برای مدیریت منابع هاست اشتراکی استفاده می‌شود. عدد EP را نباید مساوی تعداد کاربران آنلاین دانست؛ نحوه محاسبه آن به وب‌سرور و تنظیمات نیز وابسته است.
برای جزئیات فنی این موارد می‌توانید مستندات رسمی محدودیت‌های CloudLinux را ببینید. هنگام خرید، مشخصات سرویس خودتان را ملاک قرار دهید؛ اعداد نمونه در یک راهنمای فنی، تعهد شرکت میزبان شما نیستند.
تعداد فایل‌ها؛ محدودیتی جدا از حجم
Inode در بحث هاست، شاخصی برای شمار فایل‌ها و پوشه‌هاست. تعداد زیادی فایل کوچک می‌تواند سقف مجاز را پر کند، درحالی‌که هنوز فضای ذخیره‌سازی باقی مانده است. در این وضعیت ممکن است ساخت فایل تازه یا آپلود با مشکل روبه‌رو شود.
از پشتیبانی بخواهید پوشه‌های پرمصرف را معرفی کند. فایل‌های موقت، نسخه‌های آزمایشی قدیمی و خروجی افزونه‌ها را بررسی کنید، اما هر پوشه ناآشنایی را حذف نکنید. همچنین بپرسید ایمیل و نسخه‌های پشتیبان در سهم حساب شما محاسبه می‌شوند یا جداگانه نگهداری می‌شوند؛ این موضوع بین سرویس‌ها یکسان نیست.
نکته: برای ارتقا، نام منبع محدودشده را بدانید. اگر مشکل از توان پردازش باشد، خرید بسته‌ای که فقط فضای بیشتری دارد ممکن است هیچ تغییری در قطعی ایجاد نکند.
چرا سایت کم‌بازدید هم منابع زیادی مصرف می‌کند؟
آمار بازدید می‌گوید چند نفر به سایت آمده‌اند؛ اما به‌تنهایی نشان نمی‌دهد سرور برای پاسخ دادن چقدر کار کرده است. یک صفحه معرفی ساده و یک جست‌وجوی پیچیده در فروشگاه، بار یکسانی ایجاد نمی‌کنند.
کارهای پشت‌صحنه هم سهم دارند
گرفتن نسخه پشتیبان، پردازش تصاویر یا اجرای کارهای زمانبندیشده می‌تواند با مراجعه کاربران هم‌زمان شود. در این حالت، حتی بدون افزایش محسوس بازدید، مصرف بالا می‌رود. اگر کندی تقریباً در ساعت مشخصی تکرار می‌شود، زمان اجرای این کارها را بررسی کنید.
یک قابلیت معیوب ممکن است گران تمام شود
تعداد افزونه‌ها به‌تنهایی معیار مناسبی نیست. ممکن است یک افزونه یا کد نامناسب، با چند درخواست فشار زیادی ایجاد کند. اگر مشکل بعد از تغییر قالب یا افزودن قابلیتی شروع شده، همان تغییر سرنخ مهمی است؛ البته برای نتیجه‌گیری باید اثر آن را جداگانه بررسی کرد.
همه درخواست‌ها از طرف مشتری نیستند
خزنده‌ها و درخواستهای خودکار هم به سایت مراجعه می‌کنند. پس آمار ابزار بازدیدسنج را با گزارش درخواستهای سرور یکی ندانید. از پشتیبانی بخواهید مشخص کند کدام نشانی‌ها بیشتر فراخوانی شده‌اند و آیا الگوی غیرعادی وجود دارد.
برای نمونه، یک فروشگاه فرضی را در نظر بگیرید که صفحه اصلی آن سریع باز می‌شود، اما هنگام فیلتر کردن محصولات مکث طولانی دارد. در چنین وضعیتی، آزمودن همان فیلتر و بررسی گزارش مربوط به آن، مفیدتر از چند بار باز کردن صفحه اصلی است. هدف این است که مشکل را به یک رفتار مشخص وصل کنید.
آیا هر خطای سایت نشانه کمبود منابع است؟
خیر. در محیط Apache و CloudLinux، خطای 508 با رسیدن به سقف EP ارتباط دارد؛ محدودیت CPU یا I/O بیشتر می‌تواند به کندی منجر شود و محدودیت حافظه یا تعداد پردازش‌ها ممکن است خطاهای 500 یا 503 ایجاد کند. بااین‌حال، به‌خصوص خطاهای 500 و 503 علت‌های دیگری هم دارند؛ تشخیص فقط از روی شماره خطا کافی نیست.
از طرف دیگر، اگر مرورگر اصلاً نشانی سایت را پیدا نمی‌کند یا اخطار گواهی امنیتی نشان میدهد، مسیر بررسی متفاوت است. دامنه، DNS و گواهی امنیتی را باید بررسی کرد؛ افزایش منابع هاست پاسخ خودکار همه انواع قطعی نیست. DNS سامانه‌ای است که نام دامنه را به نشانی مقصد مرتبط می‌کند.
پیش از ارسال درخواست پشتیبانی، متن دقیق خطا را ثبت کنید. عبارت «سایت بالا نمی‌آید» ممکن است چند مشکل کاملاً متفاوت را توصیف کند و بررسی را طولانی‌تر کند.
روش بررسی قطعی، پیش از خرید سرویس گران‌تر
برای بررسی هاست نامحدود، از حدس زدن شروع نکنید. چند نشانه روشن جمع کنید تا بتوانید بفهمید اصلاح سایت لازم است، ارتقای سرویس یا پیگیری مشکلی دیگر.
۱. زمان و شرایط اختلال را یادداشت کنید
بنویسید مشکل در چه ساعت و با کدام منطقه زمانی رخ داده، کدام صفحه درگیر بوده و چه کاری انجام می‌داده‌اید. مشخص کنید فقط پنل مدیریت کند بوده یا صفحات عمومی هم مشکل داشته‌اند. تصویر خطا را نگه دارید و اگر اختلال کوتاه بوده، مدت تقریبی آن را ثبت کنید.
۲. گزارش همان بازه را ببینید
اگر میزبان این قابلیت را فعال کرده باشد، در cPanel بخش Resource Usage برای مشاهده مصرف منابع وجود دارد. گزارش زمان اختلال را بررسی کنید؛ طبیعی بودن وضعیت فعلی، ثابت نمی‌کند که چند ساعت قبل محدودیتی رخ نداده است.
اگر گزارش برایتان روشن نیست، تصویرش را برای پشتیبانی بفرستید. بخواهید نام منبع، سقف مجاز و زمان برخورد به محدودیت را مشخص کنند، نه اینکه صرفاً بگویند «مصرف زیاد است».
۳. از پشتیبانی یک پاسخ قابل پیگیری بخواهید
در درخواست خود این اطلاعات را بیاورید: «سایت در بازه مشخص، هنگام انجام این کار خطا داده است. لطفاً اعلام کنید کدام منبع به سقف رسیده، چه پردازش یا نشانی‌ای عامل مصرف بوده و آیا مشکل دیگری در سرور وجود داشته است.»
اگر پیشنهاد ارتقا مطرح شد، بپرسید بسته جدید دقیقاً کدام محدودیت را افزایش میدهد. همچنین درخواست کنید بررسی کنند آیا در همان بازه، اختلال عمومی سرور یا شبکه گزارش شده است. رسیدن حساب به سقف مصرف و بروز مشکل در زیرساخت میزبان، دو موضوع متفاوت‌اند.
۴. هر بار یک تغییر بدهید
اگر هم‌زمان چند افزونه را حذف کنید، تنظیمات را عوض کنید و سرویس را ارتقا دهید، معلوم نمی‌شود کدام اقدام مؤثر بوده است. تغییرها را جداگانه انجام دهید و نتیجه را در شرایط تا حد امکان مشابه بسنجید. برای تغییرهای حساس فروشگاه، نسخه پشتیبان و محیط آزمایشی در نظر بگیرید.
۵. همان بخش خراب‌شده را دوباره آزمایش کنید
اگر مشکل در ثبت سفارش بوده، صرفاً باز شدن صفحه اصلی کافی نیست. مسیر خرید را دوباره بررسی کنید و مصرف همان بازه را ببینید. معیار موفقیت را از ابتدا مشخص کنید: انجام کامل عملیات، رفع خطا و تکرار نشدن محدودیت در استفاده مشابه.
اول سایت را اصلاح کنیم یا هاست را ارتقا بدهیم؟
این تصمیم به علت مصرف بستگی دارد. ارتقا می‌تواند برای رشد واقعی سایت لازم باشد، اما بهتر است بدانید بابت چه چیزی هزینه می‌کنید. در مقابل، اصرار بر نگه داشتن سرویسی که دیگر متناسب با نیاز فروشگاه نیست هم تصمیم مناسبی نخواهد بود.
| وضعیت مشاهده‌شده | اقدام منطقی بعدی |
|---|---|
| مشکل بلافاصله پس از یک تغییر شروع شده | بررسی همان تغییر و مقایسه نتیجه پیش و پس از اصلاح |
| فشار فقط هنگام پشتیبان‌گیری رخ میدهد | بررسی روش و زمان اجرای پشتیبان‌گیری |
| درخواستهای غیرعادی عامل مصرف هستند | بررسی منشأ درخواست‌ها و تنظیم کنترل دسترسی مناسب |
| مصرف ضروری سایت مرتب به سقف می‌رسد | مقایسه بسته‌ای با منابع بیشتر در همان بخش |
| گزارش مصرف طبیعی است، اما اختلال ادامه دارد | بررسی برنامه، شبکه و وضعیت زیرساخت میزبان |
کش نیز می‌تواند بخشی از پردازش تکراری را کم کند. کش یعنی نگهداری خروجی آماده برای استفاده دوباره، تا لازم نباشد هر درخواست از ابتدا پردازش شود. بااین‌حال، فعال کردن یک افزونه کش به‌تنهایی تضمین رفع مشکل نیست؛ باید دید کدام صفحات از آن استفاده می‌کنند.
در فروشگاه، صفحات شخصی هر مشتری به تنظیمات دقیق‌تری نیاز دارند. مطابق راهنمای رسمی کش در ووکامرس، سبد خرید، تسویه‌حساب و حساب کاربری باید از کش صفحه کنار گذاشته شوند. بنابراین ظرفیت سایت را فقط با سرعت صفحه اصلی قضاوت نکنید.
برای مقایسه گزینه‌ها و آشنایی بیشتر با مدیریت سرویس، مطالب بخش راهنمای هاست سی‌پنل را ببینید. اگر هم موضوع شما ترکیبی از مشکلات سایت و میزبانی است، پرسش‌های عمومی‌تر در صفحه سوالات متداول آمده‌اند.
پیش از خرید چه سؤال‌هایی بپرسیم؟
وقتی هاست نامحدود را با یک بسته دارای ظرفیت مشخص مقایسه می‌کنید، فقط به فضای دیسک نگاه نکنید. سرویسی با فضای کمتر اما منابع روشن و متناسب، ممکن است برای کار شما انتخاب بهتری باشد. برای تصمیم، پاسخ این پرسش‌ها را کتبی بگیرید:
- سقف پردازنده، حافظه و تعداد فایل‌ها چقدر است؟
- محدودیت سرعت دیسک و پردازش هم‌زمان چگونه اعمال می‌شود؟
- منابع اعلام‌شده برای کل حساب هستند یا هر سایت سهم جداگانه دارد؟
- کدام نوع استفاده زیر عنوان نامحدود مجاز نیست؟
- هنگام رسیدن به سقف، سرویس کند می‌شود، خطا میدهد یا تعلیق می‌شود؟
- آیا گزارش مصرف گذشته و علت محدود شدن حساب در اختیار من قرار می‌گیرد؟
- ارتقا چه منابعی را افزایش میدهد و آیا به جابه‌جایی نیاز دارد؟
- شرایط پشتیبان‌گیری و بازیابی چیست و مسئولیت نگهداری نسخه مستقل با چه کسی است؟
به پاسخ‌های مبهمی مثل «برای سایت معمولی کافی است» اکتفا نکنید. نوع سایت، قابلیت‌های اصلی و برنامه رشدتان را توضیح دهید و درباره همان شرایط پاسخ بخواهید. یک فروشگاه با جست‌وجو و سفارش‌گیری، نیازهای متفاوتی از یک سایت معرفی خدمات دارد.
برای تصمیم امروز، ابتدا زمان قطعی را کنار گزارش مصرف بگذارید. اگر منبع مشخصی محدود شده، علت مصرف و تفاوت بسته بعدی را بررسی کنید؛ اگر چنین نشانه‌ای وجود ندارد، بررسی را به مسیر درست ببرید. خرید آگاهانه از جایی شروع می‌شود که بدانید مشکل چیست و تغییر پیشنهادی چگونه قرار است آن را برطرف کند.
سوالات متداول
آیا هاست نامحدود واقعاً بدون محدودیت است؟
خیر؛ این عبارت معمولاً به یک ویژگی مشخص، مانند فضا یا ترافیک، با شرایط تعیین‌شده اشاره دارد. منابع پردازشی و تعداد فایل‌ها میتوانند سقف جداگانه داشته باشند.
چرا سایت با بازدید کم خطای محدودیت منابع میدهد؟
بازدید کاربران تنها عامل مصرف نیست؛ کارهای زمانبندیشده، درخواستهای خودکار یا یک قابلیت معیوب هم میتوانند فشار ایجاد کنند. علت دقیق را باید در گزارش زمان اختلال پیدا کرد.
آیا خرید فضای بیشتر، خطای 508 را برطرف می‌کند؟
اگر مشکل مربوط به محدودیت EP در محیط Apache و CloudLinux باشد، افزایش فضای دیسک به‌تنهایی آن را برطرف نمی‌کند. باید علت درگیر ماندن پردازش‌ها و سقف همین منبع بررسی شود.
آیا با تعویض هاست، مشکل کندی حتماً رفع می‌شود؟
خیر؛ اگر علت اصلی در کد یا تنظیمات سایت باشد، ممکن است مشکل به میزبان جدید هم منتقل شود. تعویض زمانی تصمیم روشن‌تری است که محدودیت سرویس فعلی یا مشکل زیرساخت آن مشخص شده باشد.
برای فروشگاه اینترنتی حتماً باید سرور مجازی بگیریم؟
خیر؛ انتخاب به نیاز واقعی فروشگاه، منابع سرویس و کیفیت مدیریت آن بستگی دارد. پیش از مهاجرت، هزینه و مسئولیت نگهداری سرور مجازی را هم در مقایسه وارد کنید.
آیا عدد کاربران آنلاین همان تعداد پردازش هم‌زمان است؟
خیر؛ کاربری که مشغول خواندن صفحه است الزاماً در همان لحظه پردازشی روی سرور ندارد. از عدد EP نمی‌توان مستقیماً تعداد کاربران قابل پشتیبانی را به دست آورد.
