Beri nama pekerjaan sebelum memilih host
Gambarkan jalur permintaan: reverse proxy, proses API, database, dan layanan eksternal. Tambahkan jalur asinkron: antrean, worker, dan tujuan ekspor. Catat komponen mana yang berbagi host, siapa yang mengendalikan konkurensi, dan data mana yang harus bertahan setelah rebuild. Anda memerlukan metrik aplikasi dan beban kerja non-produksi dengan data yang representatif; panduan ini tidak mengasumsikan instance PrivacyNodes yang telah disediakan.
Untuk contoh API pelaporan, permintaan HTTP membaca pengaturan akun dan memasukkan ekspor ke antrean. Worker memindai baris dan menulis file. Respons enqueue yang cepat tidak membuktikan ekspor dapat selesai selama lalu lintas puncak. Sertakan pembersihan terjadwal dan tumpang tindih deployment dalam rencana pengujian.
Sertakan tumpang tindih dalam lembar kerja memori
Ini adalah input perencanaan hipotetis dalam MiB, bukan pengukuran atau janji tentang PrivacyNodes. Ganti dengan persyaratan aplikasi yang diamati. RSS mencakup pemetaan bersama yang resident; menjumlahkan RSS setiap proses dapat menghitung memori dua kali. Memori yang tersedia pada host lebih berguna daripada menganggap semua cache filesystem sebagai tidak tersedia secara permanen.
Referensi teknis: akuntansi memori proses Linux.
| Komponen | Anggaran | Asumsi |
|---|---|---|
| Host dan perkakas | 512 MiB | OS, proxy, telemetri |
| Dua proses API | 768 MiB | 384 masing-masing pada puncak yang diasumsikan |
| Satu worker ekspor | 512 MiB | Batch terbatas |
| Database | 1,024 MiB | Cache dan pekerjaan kueri |
| Tumpang tindih rilis | 512 MiB | Pekerjaan lama dan baru hidup berdampingan |
| Margin yang tidak dialokasikan | 512 MiB | Ketidakpastian untuk diselidiki |
| Total asumsi | 3,840 MiB | Bandingkan dengan memori host aktual |
Ini terlalu dekat dengan amplop nominal 4 GB untuk mengasumsikan kapasitas yang nyaman. Periksa memori aktual yang dilaporkan oleh host dan apakah puncak saling tumpang tindih. Kurangi konkurensi, pindahkan komponen, atau tambahkan memori; jangan hapus cadangan hanya agar tabel sesuai.
PostgreSQL work_mem adalah tunjangan per operasi, bukan batas total database. Sesi dan operasi bersamaan dapat melipatgandakan efeknya. Kontainer Docker tidak memiliki batasan CPU atau memori secara default; image bukanlah kebijakan sumber daya.
Referensi teknis: Konsumsi sumber daya PostgreSQL · Batasan sumber daya Docker.
Ukur CPU bersama usia antrean
Jalankan permintaan biasa, laporan paling lambat yang berguna, dependensi yang gagal, dan ekspor secara bersamaan. Catat persentil latensi, kesalahan, CPU host, konkurensi worker, dan usia pekerjaan tertua selama interval yang sama. Tekanan CPU dengan pertumbuhan antrean menyarankan tindakan yang berbeda dari CPU rendah dengan tunggu database yang lama.
Mulailah contoh dengan satu ekspor sedang berjalan. Jika worker menunggu penyimpanan eksternal, CPU tambahan mungkin sedikit berubah. Jika worker berulang kali menjenuhkan satu inti sementara latensi API meningkat, uji batch ekspor yang lebih kecil atau anggaran worker terpisah. Ubah satu faktor dan ulangi skenario yang sama sebelum membeli kapasitas.
Anggarkan operasi pemeliharaan berikutnya
Daftarkan file dan indeks database, unggahan, log, ekspor sementara, artefak rilis, dan ruang kosong untuk pemeliharaan. Catat pertumbuhan per minggu dan kapan cadangan Anda akan habis. Kumpulan data 20 GB ditambah salinan sementara 20 GB membutuhkan lebih dari 20 GB, bahkan ketika lalu lintas aplikasi biasa sepi.
Tetapkan rotasi log dan masa berlaku ekspor. Simpan salinan pemulihan di luar batas kegagalan host. Penyimpanan VPS tambahan memperluas alokasi kerja; salinan pada disk yang sama bukanlah cadangan independen. Uji operasi normal dan rilis yang berjalan bersamaan dengan cadangan atau ekspor.
Tulis keputusan yang dapat ditinjau kembali
Keluaran Anda adalah lembar kerja, deskripsi beban kerja, dan pemicu tinjauan: usia pekerjaan tertua yang bertambah selama pengujian representatif, ruang pemeliharaan yang menyusut, atau rilis yang tidak dapat hidup berdampingan dengan proses saat ini. Catat pengamatan daripada mengarang ambang persentase CPU universal.
Bandingkan App 2 dan Scale 4 terhadap batasan tersebut. Jika hasilnya masih mengejutkan Anda, ikuti satu permintaan lambat melalui stack. Latihan ini memperkirakan beban kerja Anda; ini tidak menetapkan tolok ukur pemasok, kapasitas lalu lintas, atau ketersediaan.
Referensi resmi
Dokumentasi telah ditinjau untuk artikel ini. Contoh adalah latihan perencanaan, bukan perintah yang diuji pada server PrivacyNodes. Periksa dokumentasi untuk versi yang terpasang.