# Dimensionare VPS CPU e memoria da un carico di lavoro reale | SwissOctet Insights https://swissoctet.com/it/insights/size-vps-cpu-and-memory/ SwissOctet / Approfondimenti / Cloud e VPS Cloud e VPS Applicato · 6 min di lettura Dimensiona CPU e memoria del VPS da un carico reale Costruisci un budget di memoria, ispeziona la contesa e separa un singolo thread occupato dal lavoro che può usare più core virtuali. Di SwissOctet Editorial Salva guida Copia link IN QUESTA PAGINA 01 Descrivere separatamente il lavoro normale e quello di punta 02 Costruire il budget di memoria prima di aggiungere processi 03 Distinguere l'utilizzo di CPU dal parallelismo utile 04 Cercare pressione e attese, non solo le medie 05 Un esempio di pianificazione con ipotesi esplicite 06 Lasciare un percorso chiaro per la misurazione successiva La tua checklist pratica Fonti e approfondimenti Torna alla libreria LA RISPOSTA DIRETTA Scegliere la memoria per il sistema operativo, i servizi persistenti e una concorrenza realistica con margine. Scegliere CPU dopo aver misurato quali attività sono occupate, se vengono eseguite in parallelo e quali ritardi gli utenti percepiscono effettivamente. 01 Descrivere separatamente il lavoro normale e quello di punta Il solo numero di visitatori è un input debole per il dimensionamento. Una richiesta può servire un file in cache mentre un'altra genera un report o interroga molte tabelle. Elencare i web worker, il database, la cache, i consumatori di code e le attività di manutenzione che condivideranno VPS. Descrivere la concorrenza normale e l'operazione più intensa prevista. Includere esportazioni pianificate, aggiornamenti dei pacchetti e deployment invece di trattarli come attività di background invisibili. Per un progetto esistente, raccogliere un periodo rappresentativo che includa una finestra di punta. Registrare tempi di risposta ed errori insieme all'utilizzo delle risorse. Per un nuovo progetto, creare un piccolo test con forme di richiesta e dimensioni dei dati realistiche. La stima iniziale sarà imperfetta; l'obiettivo utile è un punto di partenza documentato che si possa confrontare con il comportamento misurato dopo la consegna. 02 Costruire il budget di memoria prima di aggiungere processi La domanda di memoria deriva dal sistema, dai servizi applicativi persistenti, dall'utilizzo per worker e dalle operazioni temporanee. Moltiplicare l'impronta di un worker per una concorrenza pianificata è uno strumento di pianificazione approssimativo, non una garanzia, perché memoria condivisa e cache complicano il totale. Osservare i processi effettivi sotto carico. Lasciare spazio sufficiente affinché un'attività di manutenzione non costringa l'applicazione a competere per ogni pagina rimanente. Le impostazioni del database possono moltiplicare l'uso di memoria in modo imprevisto. PostgreSQL documenta che work_mem si applica alle operazioni di query, e diverse operazioni o sessioni possono essere eseguite contemporaneamente. Un'impostazione che sembra modesta isolatamente può quindi avere un effetto maggiore sul sistema. Leggere le linee guida del proprio database, testare una concorrenza realistica ed evitare di assegnare ogni gigabyte pubblicizzato a una singola cache. 03 Distinguere l'utilizzo di CPU dal parallelismo utile Un conteggio di processori indica quante risorse di esecuzione vengono presentate al guest, non quanto efficientemente il software possa usarle. Un thread occupato può limitare un'applicazione mentre altri core rimangono inattivi. Aggiungere worker può aiutare richieste indipendenti, ma può anche aumentare la contesa sul database e la domanda di memoria. Verificare il modello di concorrenza dell'applicazione prima di presumere che il doppio dei core produca il doppio del throughput. KVM fornisce alle macchine virtuali un proprio hardware virtuale. Non trasforma ogni etichetta vCPU in un benchmark identico tra host e generazioni di processori. Confrontare il modello CPU dichiarato e i termini di allocazione dove disponibili, poi valutare il servizio con il proprio carico di lavoro. Evitare di trarre una conclusione di acquisto da un breve punteggio sintetico che non assomiglia all'applicazione. 04 Cercare pressione e attese, non solo le medie Un sistema può sembrare lento senza mantenere un'elevata percentuale media di CPU. I processi possono attendere storage, recupero di memoria o un altro servizio. Le Pressure Stall Information del kernel Linux espongono informazioni di stallo per CPU, memoria e I/O sui sistemi supportati. Questi segnali possono aiutare a identificare la contesa delle risorse insieme alle normali metriche di utilizzo e ai tempi applicativi. Leggere le metriche insieme. Pressione sulla memoria sostenuta, swapping, allocazioni fallite e richieste lente indicano un intervento diverso da un singolo worker di calcolo occupato. Le attese di storage possono giustificare modifiche alle query o un profilo disco diverso. Un ritardo API esterno non verrà riparato aggiungendo RAM locale. Spiegare il vincolo osservato prima di scegliere quale risorsa aumentare. Comportamento osservato Domanda da indagare Possibile passo successivo Un thread occupato, core liberi inattivi Questo lavoro può essere eseguito in parallelo? Migliorare l'attività o cambiare il design dei worker Pressione sulla memoria durante un report Quante operazioni si sovrappongono? Limitare la concorrenza o aggiungere margine testato Richieste lente con attese di I/O Quali letture o scritture sono ritardate? Ispezionare query e comportamento dello storage CPU e memoria bassi, richieste lente Una dipendenza sta ritardando le risposte? Misurare le chiamate downstream 05 Un esempio di pianificazione con ipotesi esplicite Immaginare una piccola applicazione con due web worker, un database e un consumatore di coda. Il team misura quei servizi durante richieste ordinarie e un'attività di generazione di report. Scopre che consentire quattro report contemporaneamente aumenta bruscamente la domanda di memoria mentre ritarda il traffico normale. Invece di acquistare immediatamente il piano più grande, limita la concorrenza dei report e misura di nuovo il risultato. Se il carico di lavoro adattato necessita ancora di più memoria, l'upgrade ora risponde a un requisito osservato. Se la coda rimane limitata da CPU e i job indipendenti possono essere eseguiti in parallelo, più risorse di esecuzione possono essere appropriate. Queste sono decisioni di esempio, non cifre di prestazioni per i piani SwissOctet. Conservare le proprie misurazioni e i propri vincoli insieme alla configurazione scelta. 06 Lasciare un percorso chiaro per la misurazione successiva Definisci i segnali che attiveranno una revisione: deterioramento del tempo di risposta, pressione ripetuta sulla memoria, code in crescita o un carico di lavoro modificato. Mantieni il monitoraggio abbastanza leggero da non diventare un nuovo collo di bottiglia. Rivaluta dopo aver aggiunto una funzionalità o un dataset importante, ed evita aggiornamenti ripetuti quando il vero problema è un processo senza limiti o una query lenta. Le famiglie VPS di SwissOctet espongono specifiche di CPU e memoria e opzioni di risorse selezionate. Leggi la configurazione finale dopo aver aggiunto gli extra, incluso il periodo di fatturazione e il totale. Conferma gli accordi di aggiornamento con l'operatore attivo prima di farvi affidamento. Una dimensione utile di VPS è quella che esegue il carico di lavoro misurato con un margine ragionevole e un passo successivo comprensibile. TRASFORMALO IN AZIONE La tua checklist pratica. ✓ Inventaria i servizi e il lavoro di manutenzione. ✓ Misura la concorrenza in condizioni normali e nei periodi di picco. ✓ Pianifica la memoria persistente e temporanea. ✓ Verifica se il lavoro di CPU può essere eseguito in parallelo. ✓ Confronta pressione, utilizzo e tempi dell'applicazione. ✓ Definisci quando rivedere la configurazione. Scarica la checklist DOMANDE COMUNI I dettagli che contano. Dovrei dimensionare un VPS in base ai visitatori mensili? + Usa il numero di visitatori come contesto, poi misura la complessità delle richieste, la concorrenza, la dimensione dei dati e il lavoro in background. Numeri di visitatori uguali possono creare carichi diversi. Più RAM rende sempre un servizio più veloce? + No. Aiuta quando la memoria è un vincolo o consente un caching utile, ma non risolve ogni ritardo di CPU, di archiviazione o di dipendenze esterne. Il doppio dei vCPU raddoppia le prestazioni? + No. Il parallelismo, le caratteristiche del processore, la contesa e il design dell'applicazione determinano quanta capacità aggiuntiva è utile. RIFERIMENTI PRIMARI Vai alla fonte. Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione. Kernel Linux: Pressure Stall Information docs.kernel.org PostgreSQL: Consumo di risorse www.postgresql.org Progetto KVM: Kernel Virtual Machine www.linux-kvm.org Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente. COLLEGA LE CONOSCENZE Infrastruttura correlata. Vector VPS Svizzera Pulse NVMe Svizzera DeskLink RDP Svizzera MANTIENI IL FILO Le tue prossime note sul campo. Esplora tutte le guide NOTA SUL CAMPO / 01 + Cloud e VPS Fondamenta Come scegliere un VPS senza tirare a indovinare Trasforma un'idea applicativa in un budget di risorse utile, poi confronta insieme CPU, memoria, storage e trasferimento. 4 min di lettura Leggi la guida NOTA SUL CAMPO / 02 + Dedicati e GPU Fondamenta VPS o dedicato: scegli il confine che fa per te Comprendi cosa cambia una macchina fisica, cosa non cambia e quando diventa un passo utile per il tuo carico di lavoro. 4 min di lettura Leggi la guida NOTA SUL CAMPO / 03 + Storage e ripristino Fondamenta Quando NVMe fa la differenza per la tua applicazione Distingui capacità, latenza e throughput in modo che un'etichetta di storage più veloce risponda a un problema applicativo reale. 4 min di lettura Leggi la guida