Sesuaikan ukuran dengan aplikasi yang benar-benar Anda jalankan.

Sebelum Anda mengukur

Gunakan mesin pengujian Linux yang Anda kendalikan, dengan aplikasi dan data representatif Anda. Perintah di bawah memeriksa sumber daya; perintah tersebut tidak menyetel kernel atau menghapus file. Anda memerlukan procps dan GNU coreutils, serta izin untuk memeriksa direktori aplikasi yang dipilih. Ganti /srv/my-app dengan jalur sebenarnya. Jika aplikasi belum berjalan di mana pun, gunakan lingkungan pengembangan atau staging-nya untuk membuat perkiraan awal, lalu tinjau kembali perkiraan itu pada sistem yang dituju.

Catat apa yang berbagi VPS: sistem operasi, proxy, API, database, worker dan pemantauan. Catat apakah build aset berjalan di sana, apakah cadangan dikompresi secara lokal, dan apakah tugas terjadwal dapat tumpang tindih dengan deployment. Proses aplikasi yang tenang dapat hidup berdampingan dengan proses rilis yang mahal.

Baca memori yang tersedia dan identifikasi prosesnya

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m melaporkan mebibyte. Fokus pada available, perkiraan memori yang dapat mendukung pekerjaan baru tanpa swapping; free saja mengecualikan memori reclaimable yang berguna. Cache karena itu bukan, dengan sendirinya, alasan untuk membeli lebih banyak RAM. Lihat definisi bidang free.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

Nilai RSS proses di atas kira-kira sesuai dengan 384, 180 dan 32 MiB. Nilai tersebut membantu menemukan penggunaan memori, tetapi menjumlahkan setiap nilai RSS bukan total mesin yang tepat: halaman bersama dapat dihitung lebih dari sekali dan beberapa biaya kernel berada di luar angka proses. Hindari mencetak argumen perintah atau lingkungan saat mengumpulkan laporan, karena mungkin berisi rahasia. manual ps menjelaskan bidang dan perilaku snapshot-nya.

Ubah pengamatan menjadi lembar kerja

Alokasi berikut mengilustrasikan API kecil dengan database lokal dan satu worker. Ini adalah nilai perencanaan yang dibuat-buat, bukan tolok ukur atau persyaratan minimum untuk kerangka kerja tertentu. Ganti dengan pengukuran Anda, dan catat alokasi mana yang dapat memuncak pada saat yang sama.

Lembar kerja ini sudah melebihi anggaran 1,024 MiB. Lingkungan pengujian 2,048 MiB akan menyisakan 676 MiB terhadap alokasi ini, tetapi hasil yang berguna adalah apakah pekerjaan representatif nyata cocok sementara aplikasi tetap responsif. Jika alokasi deployment mendominasi, membangun artefak di tempat lain mungkin merupakan perubahan yang lebih baik daripada memperbesar server permanen. Pertahankan asumsi di samping total.

Pantau CPU dan swap selama pekerjaan berguna

vmstat 1 10

Jalankan ini selama batch permintaan representatif, sebuah pekerjaan dan rilis. Abaikan baris pertama saat menafsirkan interval terbaru: itu merangkum aktivitas sejak boot. Baris berikutnya menjelaskan interval pengambilan sampel. Pekerjaan runnable yang persisten di r, waktu idle rendah di id dan permintaan lambat bersama-sama membenarkan penyelidikan tekanan CPU. Berulang si/so aktivitas menunjukkan swapping; swap yang dialokasikan saja tidak membuktikan tekanan saat ini. wa dan st memerlukan konteks daripada peningkatan CPU otomatis. Bidang-bidang ini didefinisikan dalam vmstat.

Catat waktu respons pada aplikasi juga. API eksternal atau kueri database yang lambat dapat membuat permintaan menunggu sementara CPU sebagian besar menganggur. Ulangi beban kerja yang sama setelah satu perubahan, sehingga Anda tahu perubahan mana yang membantu. Pengujian beban harus menargetkan hanya sistem yang Anda kendalikan, dengan laju dan kondisi berhenti yang menghindari mengganggu pengguna lain.

Anggarkan pertumbuhan disk dan transfer secara terpisah

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df menjelaskan filesystem yang berisi jalur, termasuk ruang yang dibagikan dengan direktori lain; df -i memeriksa penggunaan inode jika didukung. Sejumlah besar file kecil dapat menghabiskan inode sebelum kapasitas byte. du memperkirakan pohon yang dipilih, tergantung pada izin akses. Ini pertanyaan yang berbeda, jadi totalnya tidak harus cocok. Lihat df dan du.

Daftar database saat ini, unggahan, log, artefak aplikasi dan ruang staging cadangan lokal apa pun. Tambahkan ruang yang diperlukan untuk rilis bersama rilis sebelumnya, lalu perkirakan pertumbuhan selama interval tinjauan berikutnya. Misalnya, 100 MiB unggahan baru setiap hari menambah sekitar 3,000 MiB selama 30 hari sebelum replika atau cadangan. Beri label GB desimal dan GiB biner secara konsisten saat membandingkan hasil dengan katalog.

Untuk transfer, respons 20 kB ilustratif yang dikirim 50,000 kali adalah sekitar 1 GB muatan respons. Tambahkan unggahan, file statis, overhead protokol dan lalu lintas cadangan. Aritmetika itu memperkirakan volume, bukan throughput atau pengguna simultan. Konfirmasikan bagaimana layanan menghitung lalu lintas dan menangani kelebihannya.

Pilih tindakan berikutnya dan periksa

• Memori tersedia rendah selama puncak normal: periksa konsumen utama dan uji anggaran memori yang lebih besar.
• Permintaan lambat dengan tekanan CPU berkelanjutan: profil jalur sibuk, lalu bandingkan perubahan CPU menggunakan beban kerja yang sama.
• Penggunaan disk bertambah: identifikasi direktori yang bertanggung jawab dan kebijakan retensi sebelum menghapus apa pun.
• Sumber daya tampak nyaman tetapi aplikasi lambat: selidiki dependensi, kueri dan jalur permintaan.

Simpan lembar kerja dengan deskripsi beban kerja, waktu sampel, unit dan tanggal tinjauan berikutnya. Periksa kembali setelah rilis besar, pertumbuhan data atau worker tambahan. Pilih konfigurasi dari pengamatan tersebut; tidak ada nama paket yang menjamin kapasitas permintaan. Lanjutkan dengan membaca peringatan memori dan disk atau skenario sumber daya API pertama.