مدیریت سرور
دسته بندی:
چه میزان RAM برای سرور نیاز دارم؟
پاسخ کوتاه: برای یک وبسایت معمولی که کنترلپنل، وبسرور و یک دیتابیس روی آن اجرا میشود، ۴ گیگابایت رم نقطه شروع منطقی است؛ پروژههای سبک و بدون کنترلپنل با ۱ تا ۲ گیگابایت هم راه میافتند و فروشگاهها و سایتهای پربازدید معمولاً از ۸ گیگابایت شروع میکنند. اما عدد درست را باید از جمع مصرف واقعی اجزای روی سرور به دست آورد، نه از روی حدس.
فرمول تخمین رم سرور
تخمین اولیه چنین شکلی دارد:
سیستمعامل + کنترلپنل + وبسرور و پردازشهای PHP + دیتابیس + کش و سرویسهای جانبی + حاشیه ایمنی = رم مورد نیاز
حاشیه ایمنی را دستکم ۲۵ تا ۳۰ درصد بگیرید؛ برای اوج ترافیک، بکاپگیری و بهروزرسانی لازم است. عدد نهایی را هم به اندازه رایج بعدی (۲، ۴، ۸ یا ۱۶ گیگابایت) گرد کنید.
سهم سیستمعامل
لینوکس مینیمال و بدون رابط گرافیکی بهمراتب کممصرفتر از ویندوز سرور با Desktop Experience است. نکته مهم ۲۰۲۶: CentOS نسخههای ۶، ۷ و ۸ همگی به پایان عمر رسیدهاند و انتخاب امروزی AlmaLinux 9، Rocky Linux 9 یا نسخههای LTS اوبونتو است. بحث قدیمی «سیستمعامل ۳۲ بیتی رم کمتری میخواهد» هم موضوعیت ندارد: در معماری ۳۲ بیتی هر پردازش حداکثر تا ۴ گیگابایت فضای آدرس دارد و امروز همه توزیعهای سروری ۶۴ بیتی هستند. مرجع دقیق ویندوز سرور هم صفحه الزامات سختافزاری مایکروسافت است.
کنترلپنل، سنگینترین هزینه ثابت
کنترلپنل فقط یک رابط وب نیست؛ cPanel و Plesk معمولاً میلسرور، فیلتر هرزنامه، سرویس دیتابیس و گاهی آنتیویروس را هم نصب میکنند و همینها حافظه را میخورند، نه خود پنل. DirectAdmin و CyberPanel سبکترند و برای DirectAdmin معمولاً حدود ۱ گیگابایت رم کافی است؛ خرید لایسنس دایرکت ادمین در آنلاین سرور با نصب رایگان و کانفیگ اولیه همراه است.
نسخههای جدید cPanel هم دیگر روی CentOS 7 نصب نمیشوند و فقط AlmaLinux، Rocky Linux، CloudLinux و اوبونتو پشتیبانی میشوند؛ پیش از سفارش سرور مستندات رسمی الزامات نصب cPanel را ببینید.
وبسرور، PHP و دیتابیس: جایی که ریاضی واقعی است
بیشترین مصرف متغیر مربوط به پردازشهای PHP است: حداکثر پردازش همزمان ضرب در میانگین حافظه هر پردازش. اگر هر پردازش PHP-FPM حدود ۸۰ مگابایت بگیرد و pm.max_children روی ۳۰ باشد، سقف تقریبی PHP حدود ۲.۴ گیگابایت است. این سقف بدبینانه است، چون بخشی از حافظه (کتابخانههای مشترک و سگمنت opcache) بین پردازشها مشترک است و مصرف واقعی کمتر درمیآید. مصرف هر پردازش را اینجا ببینید:
ps -ylC php-fpm --sort:rssستون RSS بر حسب کیلوبایت است؛ برای مگابایت آن را بر ۱۰۲۴ تقسیم کنید و چون مرتبسازی صعودی است، سنگینترین پردازش آخرین سطر است.
برای دیتابیس مهمترین تنظیم innodb_buffer_pool_size است؛ روی سروری که وبسرور را هم اجرا میکند معمولاً ۲۵ تا ۵۰ درصد کل حافظه منطقی است. بزرگتر از این وبسرور را دچار کمبود میکند و کوچکتر از حجم دادههای پرکاربرد، دیتابیس را به دیسک میچسباند. اگر ترجیح میدهید این تنظیمها را به کارشناس بسپارید، روی سرور مجازی مدیریتشده ایران پیکربندی کنترلپنل و عیبیابی نرمافزارها را تیم آنلاین سرور انجام میدهد.
چرا «بازدید روزانه» واحد درستی نیست
قاعده قدیمی «به ازای هر چند هزار بازدید روزانه یک گیگابایت رم» گمراهکننده است، چون درباره همزمانی چیزی نمیگوید؛ سایتی با صد هزار بازدید روزانه و کش کامل میتواند از یک فروشگاه پنجهزار بازدیدی بدون کش رم کمتری بگیرد. معیار عملی، تعداد پردازشهای همزمان PHP در ساعت اوج است.
کش، مؤثرترین اهرم کاهش مصرف
کش صفحه (مثل fastcgi_cache در انجینایکس یا افزونههای کش وردپرس) درخواستهای رسیده به PHP و دیتابیس را بهشدت کم میکند و همین بزرگترین صرفهجویی در رم است. اما حواستان به خود سرویس کش باشد: Redis بهصورت پیشفرض سقف ندارد، چون maxmemory صفر است و میتواند تا مرز کمبود حافظه سیستم رشد کند. Memcached برعکس، همیشه با سوئیچ -m سقف دارد و پیشفرض بستهها عمداً کوچک (۶۴ مگابایت) است؛ ریسک آنجا رشد بیحد نیست، حذف مداوم داده است.
maxmemory-policy allkeys-lru هم تنها وقتی درست است که آن نمونه Redis صرفاً کش باشد؛ اگر سشن کاربران، سبد خرید ووکامرس یا صفهای زمانبندی روی همان نمونه است، این سیاست بیسروصدا همان کلیدها را هم حذف میکند و کاربر بدون هیچ خطایی از حساب بیرون میافتد. در آن حالت volatile-lru با TTL روی کلیدهای کش، یا نمونه و دیتابیس جدا برای کش را انتخاب کنید.
چطور بفهمیم رم کم آوردهایم؟
در خروجی free -h ستون available را ببینید، نه used؛ لینوکس حافظه آزاد را به کش فایل تبدیل میکند و «پر» بودن رم بهتنهایی نشانه مشکل نیست. نشانههای واقعی اینها هستند:
vmstat 1 5: اگر ستونهای si و so مدام غیرصفر باشند، سرور دائم با سوآپ جابهجا میکند. اگر خروجیfree -hنشان میدهد سوآپ صفر است، این دو ستون همیشه صفر میمانند و باید مستقیم سراغ ردپای OOM Killer بروید.- سنگینترین پردازشها:
ps aux --sort=-%mem | head -n 15 - ردپای OOM Killer:
journalctl -k | grep -i oomفقط بوت فعلی را پوشش میدهد و چون بحران حافظه معمولاً به ریاستارت ختم میشود، بوت قبلی را باjournalctl -k -b -1 | grep -i "out of memory"و کل هفته را باjournalctl --since "-7 days" | grep -i "killed process"هم ببینید. - روند بلندمدت با بسته sysstat:
sar -r -f /var/log/sa/sa15داده روز پانزدهم وsar -r -7داده هفت روز پیش را میدهد، در حالی کهsar -rخالی فقط همین امروز است؛ نگهداری پیشفرض sysstat هم محدود است و روزهای قدیمیتر ممکن است موجود نباشند.
سوآپ تور نجات است، نه جایگزین رم؛ سروری که دائم سوآپ میکند از نگاه کاربر کند است.
پس در عمل چقدر بخرم؟
اینها نقطه شروعاند و با اندازهگیری تصحیح میشوند: سایت شرکتی یا وبلاگ کمبازدید بدون کنترلپنل با ۱ تا ۲ گیگابایت؛ وردپرس با کنترلپنل و ترافیک متوسط با ۴ گیگابایت؛ فروشگاه ووکامرس یا چند سایت روی یک سرور از ۸ گیگابایت؛ دیتابیس سنگین، اپلیکیشن جاوا یا چند کانتینر داکر از ۱۶ گیگابایت به بالا. از پلن پایینتر شروع کنید و بر اساس مصرف واقعی بالا بروید؛ سرور مجازی ایران روی بستر VMware با پلنهای ۲ تا ۸ گیگابایت رم با میزبانی در دیتاسنترهای شاتل و سروش رسانه، برای همین مسیر پلکانی مناسب است.
و رم اضافه کد بد را جبران نمیکند؛ اول اندازه بگیرید، بعد ارتقا دهید.
