Pilih memori untuk sistem operasi, layanan persisten, dan konkurensi realistis dengan ruang cadangan. Pilih CPU setelah mengukur tugas mana yang sibuk, apakah tugas tersebut berjalan paralel, dan penundaan apa yang benar-benar dialami pengguna.
Jelaskan pekerjaan normal dan pekerjaan sibuk secara terpisah
Jumlah pengunjung saja merupakan masukan penentuan ukuran yang lemah. Satu permintaan dapat melayani file yang di-cache sementara permintaan lain menghasilkan laporan atau melakukan kueri ke banyak tabel. Daftarkan web worker, database, cache, konsumen antrean, dan tugas pemeliharaan yang akan berbagi VPS. Jelaskan konkurensi normal dan operasi tersibuk yang diperkirakan. Sertakan ekspor terjadwal, pembaruan paket, dan penerapan alih-alih memperlakukannya sebagai aktivitas latar belakang yang tidak terlihat.
Untuk proyek yang sudah ada, kumpulkan periode representatif yang mencakup jendela sibuk. Catat waktu respons dan kesalahan bersama penggunaan sumber daya. Untuk proyek baru, buat pengujian kecil dengan bentuk permintaan dan ukuran data yang realistis. Perkiraan awal Anda tidak akan sempurna; tujuan yang berguna adalah titik awal terdokumentasi yang dapat Anda bandingkan dengan perilaku terukur setelah pengiriman.
Bangun anggaran memori sebelum menambahkan proses
Kebutuhan memori berasal dari sistem, layanan aplikasi persisten, penggunaan per worker, dan operasi sementara. Mengalikan jejak seorang worker dengan konkurensi yang direncanakan adalah alat perencanaan kasar, bukan jaminan, karena memori bersama dan cache menyulitkan totalnya. Amati proses sebenarnya di bawah beban. Sisakan cukup ruang agar tugas pemeliharaan tidak memaksa aplikasi bersaing untuk setiap halaman yang tersisa.
Pengaturan database dapat melipatgandakan penggunaan memori secara tak terduga. PostgreSQL mendokumentasikan bahwa work_mem berlaku untuk operasi kueri, dan beberapa operasi atau sesi dapat berjalan bersamaan. Oleh karena itu, pengaturan yang terlihat sederhana secara terpisah dapat memiliki efek sistem yang lebih besar. Baca panduan database Anda sendiri, uji konkurensi realistis, dan hindari mengalokasikan setiap gigabyte yang diiklankan ke satu cache.
Bedakan pemanfaatan CPU dari paralelisme yang berguna
Jumlah prosesor memberi tahu Anda berapa banyak sumber daya eksekusi yang disajikan kepada guest, bukan seberapa efisien perangkat lunak Anda dapat menggunakannya. Satu thread yang sibuk dapat membatasi aplikasi sementara core lain tetap menganggur. Menambahkan worker dapat membantu permintaan independen, tetapi juga dapat meningkatkan persaingan database dan kebutuhan memori. Periksa model konkurensi aplikasi sebelum mengasumsikan bahwa dua kali jumlah core menghasilkan dua kali throughput.
KVM menyediakan mesin virtual dengan perangkat keras virtualnya sendiri. Ini tidak mengubah setiap label vCPU menjadi tolok ukur yang identik di seluruh host dan generasi prosesor. Bandingkan model CPU yang tercantum dan ketentuan alokasi jika tersedia, lalu evaluasi layanan dengan beban kerja Anda sendiri. Hindari menarik kesimpulan pembelian dari skor sintetis singkat yang tidak menyerupai aplikasi.
Cari tekanan dan penantian, bukan hanya rata-rata
Sistem dapat terasa lambat tanpa mempertahankan persentase CPU rata-rata yang tinggi. Proses mungkin menunggu penyimpanan, reklamasi memori, atau layanan lain. Pressure Stall Information pada kernel Linux mengekspos informasi stall CPU, memori, dan I/O pada sistem yang didukung. Sinyal ini dapat membantu mengidentifikasi persaingan sumber daya bersama metrik utilisasi normal dan waktu aplikasi.
Baca metrik secara bersamaan. Tekanan memori yang berkelanjutan, swapping, alokasi yang gagal, dan permintaan lambat mengarah pada intervensi yang berbeda dari satu worker komputasi yang sibuk. Penantian penyimpanan mungkin membenarkan perubahan kueri atau profil disk yang berbeda. Penundaan API eksternal tidak akan diperbaiki dengan menambahkan RAM lokal. Jelaskan kendala yang diamati sebelum memilih sumber daya mana yang akan ditingkatkan.
| Perilaku yang diamati | Pertanyaan untuk diselidiki | Langkah berikutnya yang mungkin |
|---|---|---|
| Satu thread sibuk, core cadangan menganggur | Dapatkah pekerjaan ini berjalan paralel? | Tingkatkan tugas atau ubah desain worker |
| Tekanan memori selama laporan | Berapa banyak operasi yang tumpang tindih? | Batasi konkurensi atau tambahkan ruang cadangan yang teruji |
| Permintaan lambat dengan penantian I/O | Baca atau tulis mana yang tertunda? | Periksa kueri dan perilaku penyimpanan |
| CPU dan memori rendah, permintaan lambat | Apakah dependensi menunda respons? | Ukur panggilan hilir |
Contoh perencanaan dengan asumsi yang eksplisit
Bayangkan aplikasi kecil dengan dua web worker, sebuah database, dan satu konsumen antrean. Tim mengukur layanan tersebut selama permintaan biasa dan tugas pembuatan laporan. Tim menemukan bahwa mengizinkan empat laporan sekaligus meningkatkan kebutuhan memori secara tajam sekaligus menunda lalu lintas normal. Alih-alih langsung membeli paket terbesar, tim membatasi konkurensi laporan dan mengukur hasilnya lagi.
Jika beban kerja yang disesuaikan masih membutuhkan lebih banyak memori, peningkatan versi kini menjawab kebutuhan yang teramati. Jika antrean tetap terikat pada CPU dan pekerjaan independen dapat berjalan bersamaan, lebih banyak sumber daya eksekusi mungkin sesuai. Ini adalah contoh keputusan, bukan angka kinerja untuk paket SwissOctet. Simpan pengukuran dan kendala Anda sendiri bersama konfigurasi yang dipilih.
Sisakan jalur yang jelas untuk pengukuran berikutnya
Tentukan tanda-tanda yang akan memicu peninjauan: penurunan waktu respons, tekanan memori berulang, antrean yang bertambah, atau beban kerja yang berubah. Jaga pemantauan cukup ringan agar tidak menjadi hambatan baru. Tinjau kembali setelah menambahkan fitur atau kumpulan data besar, dan hindari peningkatan berulang ketika masalah sebenarnya adalah proses tanpa batas atau kueri yang lambat.
Keluarga VPS milik SwissOctet mengekspos spesifikasi CPU dan memori serta opsi sumber daya tertentu. Baca konfigurasi akhir setelah menambahkan ekstra, termasuk periode penagihan dan totalnya. Konfirmasi pengaturan peningkatan dengan operator langsung sebelum mengandalkannya. Ukuran VPS yang berguna adalah ukuran yang menjalankan beban kerja terukur dengan ruang cadangan yang wajar dan langkah berikutnya yang dapat dipahami.
Daftar periksa praktis Anda.
- Inventarisasi layanan dan pekerjaan pemeliharaan.
- Ukur konkurensi normal dan periode sibuk.
- Anggarkan memori persisten dan sementara.
- Periksa apakah pekerjaan CPU dapat berjalan paralel.
- Bandingkan tekanan, utilisasi, dan waktu aplikasi.
- Tentukan kapan harus meninjau konfigurasi.
Detail yang penting.
Haruskah saya menentukan ukuran VPS berdasarkan pengunjung bulanan?+
Gunakan jumlah pengunjung sebagai konteks, lalu ukur kompleksitas permintaan, konkurensi, ukuran data, dan pekerjaan latar belakang. Jumlah pengunjung yang sama dapat menciptakan beban yang berbeda.
Apakah lebih banyak RAM selalu membuat layanan lebih cepat?+
Tidak. Ini membantu ketika memori menjadi kendala atau memungkinkan caching yang berguna, tetapi tidak menyelesaikan setiap penundaan CPU, penyimpanan, atau dependensi eksternal.
Apakah dua kali jumlah vCPU menggandakan kinerja?+
Tidak. Paralelisme, karakteristik prosesor, persaingan, dan desain aplikasi menentukan seberapa besar kapasitas tambahan yang berguna.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- Kernel Linux: Pressure Stall Information docs.kernel.org
- PostgreSQL: Konsumsi Sumber Daya www.postgresql.org
- Proyek KVM: Kernel Virtual Machine www.linux-kvm.org
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.