دارید دو پلن را کنار هم میگذارید: یکی ۸ هسته با فرکانس ۲.۴ گیگاهرتز، دیگری ۴ هسته با ۳.۸ گیگاهرتز. هر دو ۳۲ گیگ رم دارند. تفاوت قیمت هم کم نیست. مسئله این است که هیچکدام از این اعداد بهتنهایی نمیگوید سایت شما زیر بار سنگین چه رفتاری خواهد داشت. مشخصات سرور را باید بر اساس کاری که واقعاً روی آن اجرا میشود خواند، نه بر اساس بزرگترین عدد در جدول.
هسته در برابر فرکانس: کدام یکی بار وب را تعیین میکند
برای بار وب معمول (PHP-FPM، Node، پایگاهداده رابطهای) فرکانس تکهستهای معمولاً مهمتر از تعداد هسته است، تا جایی که تعداد هستهها از تعداد workerهای همزمان کمتر نشود. یک درخواست PHP تقریباً همیشه روی یک هسته تمام میشود؛ موازیسازی بین درخواستها اتفاق میافتد، نه داخل یک درخواست. پس اگر ۴ هسته ۳.۸ گیگاهرتز دارید و بار شما ۲۰ درخواست همزمان است، هستهها صف میبندند و فرکانس بالاتر به هر درخواست سریعتر جواب میدهد.
برعکس، اگر روی همان سرور Elasticsearch یا یک صف پردازش تصویر اجرا میکنید، داستان عوض میشود. آن بارها واقعاً چندرشتهایاند و ۱۶ هسته ۲.۴ گیگاهرتز از ۴ هسته ۳.۸ گیگاهرتز جلو میزند. اینجا اشتباه میکنند: کسی که سایت وردپرسی را روی یک ماشین ۳۲ هستهای با فرکانس پایه ۲.۰ گیگاهرتز میبرد و بعد میگوید «سرور قویتر شد ولی سایت کندتر شد». علتش این است که MySQL تکرشتهای کار میکند و آن یک رشته حالا کندتر اجرا میشود.
یک عدد عملی: اگر top را باز کنید و ببینید %Cpu(s) روی ۱۰۰ درصد است ولی load average فقط ۱.۲ است، شما مشکل فرکانس دارید نه ظرفیت. اگر load بالای ۸ روی ۴ هسته است ولی هر هسته ۴۰ درصد مصرف دارد، مشکل I/O است. تفاوت این دو حالت کل تصمیم خرید را عوض میکند و در راهنمای تشخیص علت لود بالای سرور گامبهگام باز شده است.
ECC و نسل CPU: مشخصاتی که در جدول فروش دیده نمیشوند
ECC واقعاً چه چیزی را عوض میکند
ECC خطاهای تکبیتی حافظه را تصحیح میکند و خطاهای دوبیتی را تشخیص میدهد. روی یک سرور وب معمولی، احتمال بروز چنین خطایی در طول یک سال پایین است. اما روی ماشینی که ZFS اجرا میکند یا ماهها بدون ریاستارت بالا میماند، نبود ECC یعنی یک بیت برگشته میتواند به دادهای که روی دیسک نوشته شده راه پیدا کند و checksum را هم خراب کند. اگر از ZFS یا Ceph استفاده میکنید، ECC را غیرقابلمذاکره بدانید. اگر یک VPS ساده برای سایت شرکتی است، پول اضافهای که برای ECC میدهید بهتر است صرف NVMe شود.
نسل پردازنده و آنچه در بنچمارک نمیبینید
یک Xeon نسل قدیم با ۱۶ هسته میتواند در بنچمارک چندرشتهای از یک پردازنده نسل جدید ۸ هستهای جلو بزند و در عمل کندتر باشد. دلیلش دو چیز است: IPC پایینتر، و پشتیبانی از دستورالعملهای جدیدتر مثل AVX-512 که بعضی کتابخانههای رمزنگاری و پردازش برداری از آن استفاده میکنند. برای TLS، پردازندههای جدید AES-NI بهتری دارند و همین روی تعداد handshake در ثانیه اثر مستقیم میگذارد.
روش سریع سنجش: قبل از خرید، اگر امکان تست دارید، این را اجرا کنید و عدد را با پلن فعلی مقایسه کنید.
openssl speed -evp aes-256-gcm
sysbench cpu --threads=4 --time=30 run
خروجی openssl speed عددی به شما میدهد مثل aes-256-gcm 1.2 GB/s. اگر پلن جدید این عدد را دو برابر نکرد، احتمالاً برای بار رمزنگاریشده ارزش ارتقا ندارد.
رم، دیسک و پهنای باند: سه عددی که به هم دروغ میگویند
| مشخصه | عددی که در فروشگاه میبینید | عددی که در عمل مهم است |
|---|---|---|
| رم | ۳۲ گیگابایت | رم آزاد در ساعت اوج، و نرخ swap |
| دیسک | ۵۰۰ گیگابایت SSD | IOPS تصادفی و عمق صف |
| پهنای باند | ۱۰ ترابایت ماهانه | پورت ۱Gbps در برابر ۱۰Gbps |
رم را با free -h نگاه نکنید؛ با vmstat 1 نگاه کنید. ستون si و so اگر عددی غیر از صفر نشان میدهند، شما کمبود رم دارید و هیچ مقدار تنظیم PHP-FPM این را حل نمیکند. یک سرور با ۱۶ گیگ رم و swap صفر از یک سرور ۳۲ گیگی که مدام swap میکند سریعتر است.
روی دیسک، عدد ظرفیت تقریباً بیمعنی است. آنچه بار پایگاهداده را تعیین میکند IOPS تصادفی است. یک NVMe روی PCIe 4.0 میتواند بالای ۵۰۰ هزار IOPS تصادفی ۴K بدهد؛ یک SATA SSD در همان تست زیر ۱۰۰ هزار میماند. اگر MySQL روی دیسک SATA است و iostat -x 1 نشان میدهد %util روی ۱۰۰ است در حالی که await بالای ۲۰ میلیثانیه است، گلوگاه دیسک است نه CPU. برای انتقال دادهها بین دو سرور در همین مرحله، انتقال فایل با scp و rsync سریعترین راه بدون واسطه است.
مجازی در برابر اختصاصی: کجا انتخاب اشتباه میشود
سرور اختصاصی وقتی درست است که یا به ECC و کنترل کامل هسته نیاز دارید، یا بار شما بهطور پیوسته از ظرفیت یک ماشین مجازی رد شده. اگر فقط گاهی اوج میگیرید، مجازیسازی بهتر است چون منابع را تقسیم میکند. اما یک نکته که کمتر گفته میشود: روی ماشین مجازی، «۸ هسته» یعنی ۸ vCPU که ممکن است روی ۴ هسته فیزیکی بنشینند. اگر همسایهها پرمصرف باشند، شما steal time میبینید.
با top ستون st را ببینید. اگر بالای ۵ درصد است، مشکل از کد شما نیست. این عدد را در ساعت اوج چند بار اندازه بگیرید؛ اگر پایدار بالاست، وقت تغییر پلن یا مهاجرت به سرور اختصاصی است. برای بارهایی که نوسان زیادی دارند و میخواهید منابع را بالا و پایین ببرید، سرور ابری انعطاف بیشتری میدهد و لازم نیست برای اوج سهساعته، یک سال هزینه ثابت بدهید.
اگر تازه میخواهید محیط را بالا بیاورید و هنوز مطمئن نیستید بار چقدر خواهد بود، شروع از یک هاست لینوکس و اندازهگیری واقعی مصرف، منطقیتر از خرید یک ماشین بزرگ بر اساس حدس است.
پرسشهای پرتکرار
برای یک سایت وردپرسی پرترافیک، چند هسته کافی است؟
معمولاً ۴ هسته با فرکانس بالا کافی است، به شرطی که کش درست تنظیم شده باشد. گلوگاه اکثر سایتهای وردپرسی CPU نیست؛ تعداد کوئریهای بدون ایندکس و نبود کش شیء است. قبل از ارتقا، تعداد کوئری هر صفحه را اندازه بگیرید.
اگر بعد از کشکردن کامل هنوز CPU اشباع است، آنوقت ارتقا معنی دارد. تا آن مرحله، پول بیشتری که برای هسته میدهید هدر میرود.
آیا NVMe واقعاً از SSD ساتا سریعتر است یا تبلیغاتی است؟
در بار پایگاهداده تفاوت واقعی و قابل اندازهگیری است. NVMe روی رابط PCIe کار میکند و صف عمیقتری را پشتیبانی میکند؛ همین باعث میشود در IOPS تصادفی چند برابر SATA باشد. برای یک سایت ایستا تفاوت را حس نمیکنید، برای MySQL با نوشتن زیاد تفاوت شب و روز است.
چطور بفهمم کمبود رم دارم یا کمبود CPU؟
اگر vmstat 1 در ستون si و so عدد غیرصفر نشان میدهد، مشکل رم است. اگر این دو ستون صفرند ولی load average از تعداد هستهها بیشتر است و %Cpu(s) بالای ۸۰ درصد میماند، مشکل CPU است.
حالت سوم را هم در نظر بگیرید: هر دو عدد نرمالاند ولی سایت کند است. آنوقت گلوگاه شبکه یا دیسک است و باید iostat و TTFB را جداگانه بررسی کنید.
ECC برای سرور وب لازم است؟
برای سرور وب معمولی نه، برای هر چیزی که ZFS، Ceph یا ذخیرهسازی نرمافزاری روی آن اجرا میشود بله. اگر بین رم بیشتر و رم ECC باید یکی را انتخاب کنید و بار شما فایلسرور نیست، رم بیشتر را بردارید.
قبل از هر تصمیم، یک هفته مصرف واقعی سرور فعلی را با sar یا vmstat ثبت کنید. خریدن بر اساس عدد جدول، گرانترین راه یادگیری این درس است. مستندات فنی سرورنت در پایگاه دانش برای همین اندازهگیریها نوشته شده و اگر بعد از خواندن اعداد باز هم شک داشتید، بلاگ سرورنت نمونههای واقعی بار را بررسی کرده است.