Numiți munca înainte de a alege gazda
Desenați calea cererii: proxy invers, proces API, bază de date și servicii externe. Adăugați calea asincronă: coadă, worker și destinație de export. Înregistrați ce componente partajează gazda, cine controlează concurența și ce date trebuie să supraviețuiască unei reconstrucții. Aveți nevoie de metrici ale aplicației și un volum de lucru non-producție cu date reprezentative; acest ghid nu presupune o instanță PrivacyNodes provisionată.
Pentru un API de raportare ilustrativ, o cerere HTTP citește setările contului și pune în coadă un export. Workerul scanează rânduri și scrie un fișier. Un răspuns rapid de punere în coadă nu dovedește că exportul se poate finaliza în timpul traficului de vârf. Includeți curățarea programată și suprapunerea implementării în planul de test.
Includeți suprapunerea în foaia de lucru pentru memorie
Acestea sunt intrări ipotetice de planificare în MiB, nu măsurători sau promisiuni despre PrivacyNodes. Înlocuiți-le cu cerințele observate ale aplicației. RSS include mapări partajate rezidente; adunarea RSS a fiecărui proces poate dubla memoria. Memoria disponibilă a gazdei este mai utilă decât tratarea întregului cache de sistem de fișiere ca permanent indisponibil.
Referință tehnică: Contabilizarea memoriei procesului Linux.
| Componentă | Buget | Ipoteză |
|---|---|---|
| Gazdă și unelte | 512 MiB | SO, proxy, telemetrie |
| Două procese API | 768 MiB | 384 fiecare la vârf presupus |
| Un worker de export | 512 MiB | Loturi limitate |
| Bază de date | 1,024 MiB | Cache și operațiuni de interogare |
| Suprapunere de versiuni | 512 MiB | Lucrul vechi și cel nou coexistă |
| Marjă nealocată | 512 MiB | Incertitudine de investigat |
| Ipoteză totală | 3,840 MiB | Comparați cu memoria reală a gazdei |
Acest lucru este prea aproape de un plic nominal de 4 GB pentru a presupune capacitate confortabilă. Verificați memoria reală raportată de gazdă și dacă vârfurile se suprapun. Reduceți concurența, mutați o componentă sau adăugați memorie; nu eliminați rezerva doar pentru a face tabelul să se potrivească.
PostgreSQL work_mem este o alocație per operațiune, nu o limită totală a bazei de date. Sesiunile și operațiunile concurente pot multiplica efectul. Containerele Docker nu au constrângeri CPU sau memorie implicit; o imagine nu este o politică de resurse.
Referință tehnică: Consumul de resurse PostgreSQL · Constrângeri de resurse Docker.
Măsurați CPU împreună cu vechimea cozii
Testați o cerere obișnuită, cel mai lent raport util, o dependență eșuată și un export împreună. Înregistrați percentilele de latență, erorile, CPU-ul gazdei, concurența workerului și vechimea celui mai vechi job în același interval. Presiunea CPU cu creșterea cozii sugerează o acțiune diferită de CPU scăzut cu o așteptare lungă a bazei de date.
Începeți exemplul cu un export în curs. Dacă workerul așteaptă stocarea externă, CPU suplimentar poate schimba puțin. Dacă satură repetat un nucleu în timp ce latența API crește, testați un lot de export mai mic sau un buget separat pentru worker. Schimbați un singur factor și repetați același scenariu înainte de a cumpăra capacitate.
Bugetați următoarea operațiune de mentenanță
Enumerați fișierele și indexurile bazei de date, încărcările, jurnalele, exporturile temporare, artefactele de versiune și spațiul liber pentru mentenanță. Înregistrați creșterea pe săptămână și când rezerva dvs. ar fi epuizată. Un set de date 20 GB plus o copie temporară 20 GB necesită mai mult de 20 GB, chiar și când traficul obișnuit al aplicației este redus.
Atribuiți rotația jurnalelor și expirarea exporturilor. Păstrați copiile de recuperare în afara limitelor de eșec ale gazdei. Stocarea suplimentară VPS extinde alocarea de lucru; o copie pe același disc nu este o copie de siguranță independentă. Testați atât operarea normală, cât și o versiune care rulează alături de o copie de siguranță sau un export.
Scrieți o decizie care poate fi revizuită
Rezultatul dvs. este o foaie de lucru, o descriere a volumului de lucru și un declanșator de revizuire: vechimea în creștere a celui mai vechi job în timpul testului reprezentativ, spațiu de mentenanță în scădere sau o versiune care nu poate coexista cu procesele curente. Înregistrați observații în loc să inventați un prag universal de procent CPU.
Comparați App 2 și Scale 4 cu aceste constrângeri. Dacă rezultatul încă vă surprinde, urmați o cerere lentă prin stivă. Acest exercițiu estimează volumul dvs. de lucru; nu stabilește un benchmark de furnizor, capacitate de trafic sau disponibilitate.
Referințe oficiale
Documentația a fost revizuită pentru acest articol. Exemplele sunt exerciții de planificare, nu comenzi testate pe un server PrivacyNodes. Verificați documentația pentru versiunea instalată.