حافظه را برای سیستم‌عامل، سرویس‌های پایدار و همزمانی واقع‌گرایانه با حاشیه اطمینان انتخاب کنید. CPU را پس از اندازه‌گیری اینکه کدام وظایف مشغول هستند، آیا موازی اجرا می‌شوند و کاربران واقعاً چه تأخیرهایی را تجربه می‌کنند انتخاب کنید.
کار عادی و کار پرترافیک را جداگانه توصیف کنید
تعداد بازدیدکننده به‌تنهایی یک ورودی ضعیف برای تعیین ابعاد است. یک درخواست ممکن است یک فایل نهان‌شده را ارائه دهد در حالی که دیگری یک گزارش تولید می‌کند یا از جداول زیادی پرس‌وجو می‌کند. کارگران وب، پایگاه داده، حافظه نهان، مصرف‌کنندگان صف و وظایف نگهداری را که VPS را به اشتراک می‌گذارند فهرست کنید. همزمانی عادی و پرترافیک‌ترین عملیات مورد انتظار را توصیف کنید. خروجی‌های زمان‌بندی‌شده، به‌روزرسانی‌های بسته و استقرارها را شامل کنید، نه اینکه آن‌ها را به‌عنوان فعالیت پس‌زمینه نامرئی در نظر بگیرید.
برای یک پروژه موجود، یک دوره نمونه شامل یک پنجره پرترافیک جمع‌آوری کنید. زمان‌های پاسخ و خطاها را در کنار مصرف منابع ثبت کنید. برای یک پروژه جدید، یک آزمایش کوچک با شکل درخواست‌ها و اندازه‌های داده واقع‌گرایانه ایجاد کنید. تخمین اولیه شما ناقص خواهد بود؛ هدف مفید یک نقطه شروع مستند است که می‌توانید آن را با رفتار اندازه‌گیری‌شده پس از تحویل مقایسه کنید.
بودجه حافظه را قبل از افزودن فرایندها بسازید
تقاضای حافظه از سیستم، سرویس‌های پایدار برنامه، مصرف هر کارگر و عملیات موقت ناشی می‌شود. ضرب ردپای یک کارگر در همزمانی برنامه‌ریزی‌شده یک ابزار برنامه‌ریزی تقریبی است، نه یک تضمین، زیرا حافظه مشترک و حافظه‌های نهان مجموع را پیچیده می‌کنند. فرایندهای واقعی را تحت بار مشاهده کنید. فضای کافی بگذارید تا یک وظیفه نگهداری برنامه را مجبور به رقابت برای هر صفحه باقی‌مانده نکند.
تنظیمات پایگاه داده می‌توانند مصرف حافظه را به‌طور غیرمنتظره چند برابر کنند. PostgreSQL مستند می‌کند که work_mem برای عملیات پرس‌وجو اعمال می‌شود، و چندین عملیات یا نشست می‌توانند همزمان اجرا شوند. بنابراین یک تنظیم که در انزوا متعادل به نظر می‌رسد می‌تواند اثر سیستمی بزرگ‌تری داشته باشد. راهنمای خود پایگاه داده خود را بخوانید، همزمانی واقع‌گرایانه را آزمایش کنید و از اختصاص دادن هر گیگابایت تبلیغ‌شده به یک حافظه نهان واحد خودداری کنید.
مصرف CPU را از موازی‌سازی مفید متمایز کنید
تعداد پردازنده به شما می‌گوید چند منبع اجرا به مهمان ارائه می‌شود، نه اینکه نرم‌افزار شما چقدر کارآمد می‌تواند از آن‌ها استفاده کند. یک رشته مشغول ممکن است یک برنامه را محدود کند در حالی که هسته‌های دیگر بی‌صدا می‌مانند. افزودن کارگران می‌تواند به درخواست‌های مستقل کمک کند، اما می‌تواند رقابت پایگاه داده و تقاضای حافظه را نیز افزایش دهد. مدل همزمانی برنامه را قبل از فرض اینکه دو برابر تعداد هسته دو برابر توان عبوری تولید می‌کند بررسی کنید.
KVM ماشین‌های مجازی را با سخت‌افزار مجازی خودشان فراهم می‌کند. این کار هر برچسب vCPU را به یک محک یکسان در میان میزبان‌ها و نسل‌های پردازنده تبدیل نمی‌کند. مدل CPU فهرست‌شده و شرایط تخصیص را در جایی که موجود است مقایسه کنید، سپس سرویس را با بار کاری خودتان ارزیابی کنید. از نتیجه‌گیری خرید بر اساس یک امتیاز مصنوعی کوتاه که شبیه برنامه نیست خودداری کنید.
به دنبال فشار و انتظار باشید، نه فقط میانگین‌ها
یک سیستم می‌تواند کند به نظر برسد بدون اینکه درصد CPU میانگین بالایی را حفظ کند. فرایندها ممکن است روی ذخیره‌سازی، بازیابی حافظه یا سرویس دیگری منتظر بمانند. اطلاعات توقف فشار هسته Linux اطلاعات توقف CPU، حافظه و I/O را در سیستم‌های پشتیبانی‌شده افشا می‌کند. این سیگنال‌ها می‌توانند به شناسایی رقابت منابع در کنار معیارهای مصرف عادی و زمان‌بندی برنامه کمک کنند.
معیارها را با هم بخوانید. فشار حافظه پایدار، جابه‌جایی، تخصیص‌های ناموفق و درخواست‌های کند به مداخله‌ای متفاوت از یک کارگر محاسباتی مشغول واحد اشاره دارند. انتظارهای ذخیره‌سازی ممکن است تغییرات پرس‌وجو یا یک مشخصات دیسک متفاوت را توجیه کنند. یک تأخیر API خارجی با افزودن RAM محلی ترمیم نمی‌شود. محدودیت مشاهده‌شده را توضیح دهید قبل از انتخاب اینکه کدام منبع را افزایش دهید.
| رفتار مشاهده‌شده | سؤالی که باید بررسی شود | گام بعدی ممکن |
|---|---|---|
| یک رشته مشغول، هسته‌های آزاد بی‌صدا | آیا این کار می‌تواند موازی اجرا شود؟ | وظیفه را بهبود دهید یا طراحی کارگر را تغییر دهید |
| فشار حافظه در طول یک گزارش | چند عملیات همپوشانی دارند؟ | همزمانی را محدود کنید یا حاشیه اطمینان آزمایش‌شده اضافه کنید |
| درخواست‌های کند با انتظارهای I/O | کدام خواندن‌ها یا نوشتن‌ها به تأخیر می‌افتند؟ | پرس‌وجوها و رفتار ذخیره‌سازی را بررسی کنید |
| CPU و حافظه کم، درخواست‌ها کند | آیا یک وابستگی پاسخ‌ها را به تأخیر می‌اندازد؟ | فراخوانی‌های پایین‌دست را اندازه‌گیری کنید |
یک مثال برنامه‌ریزی با فرضیات صریح
یک برنامه کوچک با دو کارگر وب، یک پایگاه داده و یک مصرف‌کننده صف را تصور کنید. تیم آن سرویس‌ها را در طول درخواست‌های عادی و یک وظیفه تولید گزارش اندازه‌گیری می‌کند. متوجه می‌شود که اجازه دادن به چهار گزارش همزمان تقاضای حافظه را به‌شدت افزایش می‌دهد در حالی که ترافیک عادی را به تأخیر می‌اندازد. به‌جای خرید فوری بزرگ‌ترین طرح، همزمانی گزارش را محدود می‌کند و نتیجه را دوباره اندازه‌گیری می‌کند.
اگر بار کاری تنظیم‌شده همچنان به حافظه بیشتری نیاز دارد، ارتقا اکنون به یک نیاز مشاهده‌شده پاسخ می‌دهد. اگر صف همچنان محدود به CPU باقی می‌ماند و کارهای مستقل می‌توانند همزمان اجرا شوند، منابع اجرای بیشتر ممکن است مناسب باشند. این‌ها تصمیم‌های نمونه هستند، نه ارقام عملکرد برای طرح‌های SwissOctet. اندازه‌گیری‌ها و محدودیت‌های خود را همراه با پیکربندی انتخاب‌شده نگه دارید.
یک مسیر روشن برای اندازه‌گیری بعدی بگذارید
نشانه‌هایی را تعریف کنید که بررسی را فعال می‌کنند: بدتر شدن زمان پاسخ، فشار مکرر حافظه، صف‌های در حال رشد یا تغییر بار کاری. پایش را به‌قدری سبک نگه دارید که خودش به گلوگاه جدیدی تبدیل نشود. پس از افزودن یک قابلیت یا مجموعه‌داده بزرگ، ارزیابی را دوباره انجام دهید و از ارتقاهای مکرر بپرهیزید، در حالی که مشکل واقعی یک فرایند بی‌کران یا یک پرس‌وجوی کند است.
خانواده‌های VPS در SwissOctet مشخصات CPU و حافظه و گزینه‌های منابع منتخب را ارائه می‌دهند. پیکربندی نهایی را پس از افزودن موارد اضافی، از جمله دوره صورت‌حساب و مجموع، بخوانید. ترتیبات ارتقا را پیش از تکیه بر آن‌ها با اپراتور فعال تأیید کنید. اندازه مفید VPS اندازه‌ای است که بار کاری اندازه‌گیری‌شده را با فضای اضافی معقول و گام بعدی قابل‌فهم اجرا کند.
چک‌لیست عملی شما.
- فهرست‌برداری از سرویس‌ها و کارهای نگهداری.
- اندازه‌گیری همزمانی در دوره عادی و دوره اوج.
- بودجه‌بندی حافظه پایدار و موقت.
- بررسی کنید که آیا کار CPU می‌تواند به‌صورت موازی اجرا شود.
- مقایسه فشار، بهره‌برداری و زمان‌بندی‌های برنامه.
- تعریف زمان بازبینی پیکربندی.
جزئیاتی که اهمیت دارند.
آیا باید یک VPS را بر اساس بازدیدکنندگان ماهانه اندازه‌بندی کنم؟+
تعداد بازدیدکننده را به‌عنوان زمینه در نظر بگیرید، سپس پیچیدگی درخواست، همزمانی، حجم داده و کارهای پس‌زمینه را اندازه‌گیری کنید. تعداد بازدیدکننده یکسان می‌تواند بارهای متفاوتی ایجاد کند.
آیا RAM بیشتر همیشه سرویس را سریع‌تر می‌کند؟+
خیر. زمانی کمک می‌کند که حافظه محدودیت باشد یا کش‌سازی مفیدی را ممکن کند، اما هر تأخیر CPU، ذخیره‌سازی یا وابستگی خارجی را برطرف نمی‌کند.
آیا دو برابر شدن تعداد vCPU عملکرد را دو برابر می‌کند؟+
خیر. موازی‌سازی، ویژگی‌های پردازنده، رقابت و طراحی برنامه تعیین می‌کنند که چه مقدار ظرفیت اضافی مفید است.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- کرنل Linux: اطلاعات توقف فشار docs.kernel.org
- PostgreSQL: مصرف منابع www.postgresql.org
- پروژه KVM: ماشین مجازی کرنل www.linux-kvm.org
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.