Best practice per Amazon DocumentDB

Scopri le best practice per lavorare con Amazon DocumentDB (con compatibilità con MongoDB). Questa sezione viene continuamente aggiornata man mano che vengono identificate nuove best practice.

Linee guida operative di base

Di seguito sono riportate le linee guida operative di base che tutti dovrebbero seguire quando lavorano con Amazon DocumentDB. L'accordo sul livello di servizio di Amazon DocumentDB richiede il rispetto di queste linee guida.

• Implementa un cluster composto da due o più istanze Amazon DocumentDB in AWS due zone di disponibilità. Per i carichi di lavoro di produzione, consigliamo di implementare un cluster composto da tre o più istanze di Amazon DocumentDB in tre zone di disponibilità.

• Utilizza il servizio nei limiti indicati. Per ulteriori informazioni, consulta Quote e limiti di Amazon DocumentDB.

• Monitora l'utilizzo della memoria, della CPU, delle connessioni e dello storage. Per aiutarti a mantenere le prestazioni e la disponibilità del sistema, configura Amazon in CloudWatch modo che ti avvisi quando i modelli di utilizzo cambiano o quando ti avvicini alla capacità della tua implementazione.

• Incrementa la capacità delle istanze quando stai per raggiungere i limiti della capacità di storage. È necessario eseguire il provisioning delle istanze con risorse di calcolo sufficienti (ad esempio, RAM, CPU) per soddisfare aumenti imprevisti della domanda da parte delle applicazioni.

• Imposta il periodo di retention dei backup per allineare l'obiettivo del punto di ripristino.

• Prova il failover per il cluster per capire quanto tempo impiega il processo per il tuo caso d'uso. Per ulteriori informazioni, consulta Failover di Amazon DocumentDB.

• Connettiti al tuo cluster Amazon DocumentDB con l'endpoint del cluster (vediEndpoint Amazon DocumentDB) e in modalità set di repliche (vediConnessione ad Amazon DocumentDB come set di repliche) per ridurre al minimo l'impatto di un failover sulla tua applicazione.

• Scegli un’impostazione di preferenza di lettura del driver che massimizza il dimensionamento della lettura nel rispetto dei requisiti di coerenza di lettura dell'applicazione. La preferenza di lettura secondaryPreferred consente la lettura delle repliche e libera l'istanza primaria per eseguire ulteriori operazioni. Per ulteriori informazioni, consulta Opzioni per le preferenze di lettura.

• Progetta la tua applicazione per essere resiliente in caso di errori della rete e del database. Usa il meccanismo di errore del driver per distinguere tra errori temporanei ed errori persistenti. Ripeti gli errori temporanei utilizzando un meccanismo di backoff esponenziale quando appropriato. Assicurati che l'applicazione consideri la coerenza dei dati quando implementa una logica di ripetizione.

• Attiva la protezione dell'eliminazione dei cluster per tutti i cluster di produzione o per qualsiasi cluster contenente dati importanti. Prima di eliminare un cluster Amazon DocumentDB, scatta uno snapshot finale. Se stai distribuendo risorse con AWS CloudFormation, abilita la protezione dalla terminazione. Per ulteriori informazioni, consulta Protezione da cessazione ed eliminazione.

• Quando si crea un cluster Amazon DocumentDB, --engine-version è un parametro opzionale che utilizza per impostazione predefinita l'ultima versione principale del motore. L'attuale versione principale del motore è la 4.0.0. Quando vengono rilasciate nuove versioni principali del motore, la versione predefinita del motore per --engine-version verrà aggiornata in modo da riflettere l'ultima versione principale del motore. Di conseguenza, per i carichi di lavoro di produzione, e in particolare quelli che dipendono da script, automazione o AWS CloudFormation modelli, ti consigliamo di specificare esplicitamente --engine-version nella versione principale desiderata.

Dimensione delle istanze

Uno degli aspetti più critici della scelta della dimensione dell'istanza in Amazon DocumentDB è la quantità di RAM per la cache. Amazon DocumentDB riserva un terzo della RAM per i propri servizi, il che significa che solo due terzi della RAM dell'istanza sono disponibili per la cache. Pertanto, è una best practice di Amazon DocumentDB scegliere un tipo di istanza con RAM sufficiente per contenere il set di lavoro (ad esempio, dati e indici) in memoria. L’uso di istanze di dimensioni adeguate contribuirà a ottimizzare le prestazioni complessive e, potenzialmente, ridurre al minimo i costi di I/O. Puoi utilizzare il calcolatore di dimensionamento di terze parti di Amazon DocumentDB per stimare la dimensione dell'istanza per un particolare carico di lavoro.

Per determinare se il set di lavoro dell'applicazione si adatta alla memoria, monitora l'BufferCacheHitRatioutilizzo di Amazon CloudWatch per ogni istanza in un cluster sotto carico.

La BufferCacheHitRatio CloudWatch metrica misura la percentuale di dati e indici serviti dalla cache di memoria di un'istanza (rispetto al volume di archiviazione). In generale, il valore di BufferCacheHitRatio dovrebbe essere il più alto possibile, poiché la lettura dei dati dalla memoria del working set è più veloce e più conveniente rispetto alla lettura dal volume di archiviazione. Anche se è consigliabile mantenere il valore BufferCacheHitRatio il più vicino possibile al 100%, il miglior valore ottenibile dipenderà dai modelli di accesso e dai requisiti di prestazione dell'applicazione. Per mantenere il massimo valore BufferCacheHitRatio possibile , si consiglia di eseguire il provisioning delle istanze del cluster con una sufficiente quantità di RAM per poter adattare gli indici e i working set di dati in memoria.

Se i tuoi indici non si adattano alla memoria, vedrai un valore inferiore BufferCacheHitRatio. La lettura continua dal disco comporta costi di I/O aggiuntivi e non è performante come la lettura dalla memoria. Se il rapporto BufferCacheHitRatio è inferiore al previsto, aumentare la dimensione dell'istanza del cluster per fornire più RAM per adattare i dati del working set in memoria. Se il ridimensionamento della classe di istanza si traduce in un aumento drastico di BufferCacheHitRatio, il set di lavoro dell'applicazione non si adattava alla memoria. Continua con l'incremento fino a quando il valore di BufferCacheHitRatio non aumenta più drasticamente dopo un'operazione di dimensionamento. Per ulteriori informazioni sul monitoraggio dei parametri di un'istanza, consulta Parametri di Amazon DocumentDB.

A seconda del carico di lavoro e dei requisiti di latenza, potrebbe essere accettabile che l'applicazione abbia valori BufferCacheHitRatio più elevati durante l'utilizzo della fase costante, ma abbia periodicamente delle riduzioni dei valori BufferCacheHitRatio quando le query analitiche che devono eseguire la scansione di un'intera raccolta vengono eseguite su un'istanza. Questi riduzioni periodiche del valore BufferCacheHitRatio possono manifestarsi come latenza più elevata per le query successive che devono ripopolare i dati del working set dal volume di archiviazione nella cache del buffer. Si consiglia di testare i carichi di lavoro in un ambiente di pre-produzione con un carico di lavoro di produzione rappresentativo al fine di comprendere le caratteristiche delle prestazioni e il valore BufferCacheHitRatio prima di distribuire il carico di lavoro in produzione.

BufferCacheHitRatio è un parametro specifici dell'istanza, pertanto istanze diverse all'interno dello stesso cluster possono avere valori BufferCacheHitRatio diversi a seconda della modalità di distribuzione delle letture tra le istanze primarie e di replica. Se il carico di lavoro operativo non è in grado di gestire gli aumenti periodici della latenza dal ripopolamento della cache del working set dopo l'esecuzione di query analitiche, ti consigliamo di provare a isolare la cache del buffer del carico di lavoro normale da quella delle query analitiche. Puoi ottenere il completo isolamento di BufferCacheHitRatio indirizzando le query operative all'istanza primaria e le query analitiche solo alle istanze di replica. Puoi inoltre ottenere l'isolamento parziale indirizzando le query analitiche a un'istanza di replica specifica, con la consapevolezza che una percentuale di query regolari verrà eseguita anche su tale replica e potrebbe potenzialmente essere influenzata.

I valori appropriati di BufferCacheHitRatio dipendono dal caso d'uso e dai requisiti dell'applicazione. Non esiste un valore migliore o un valore minimo per questo parametro; solo tu puoi decidere se il compromesso rappresentato da un valore temporaneamente inferiore di BufferCacheHitRatio è accettabile dal punto di vista dei costi e delle prestazioni.

Utilizzo degli indici

Creazione degli indici

Quando si importano dati in Amazon DocumentDB, è necessario creare gli indici prima di importare set di dati di grandi dimensioni. Puoi utilizzare Amazon DocumentDB Index Tool per estrarre indici da un'istanza o una mongodump directory di MongoDB in esecuzione e creare tali indici in un cluster Amazon DocumentDB. Per ulteriori informazioni sulle migrazioni, consulta Migrazione ad Amazon DocumentDB.

Selettività dell'indice

Si consiglia di limitare la creazione di indici ai campi in cui il numero di valori duplicati è inferiore all'1% del numero totale di documenti nella raccolta. Ad esempio, se la raccolta contiene 100.000 documenti, creare solo indici nei campi in cui lo stesso valore si verifica al massimo 1000 volte.

La scelta di un indice con un numero elevato di valori univoci (ad esempio, un’elevata cardinalità) garantisce che le operazioni di filtro restituiscano un numero ridotto di documenti, ottenendo così buone prestazioni durante le scansioni degli indici. Un esempio di indice ad elevata cardinalità è un indice univoco, che garantisce che i predicati di uguaglianza restituiscano al massimo un singolo documento. Esempi di bassa cardinalità includono un indice su un campo booleano e un indice nel giorno della settimana. A causa delle scarse prestazioni, è improbabile che gli indici a bassa cardinalità vengano scelti dall'ottimizzatore delle query del database. Allo stesso tempo, indici a bassa cardinalità continuano a consumare risorse come spazio su disco e I/O. Come regola generale, occorre indicare indici su campi in cui la frequenza tipica del valore è l'1% della dimensione totale della raccolta.

Inoltre, è consigliabile creare solo indici su campi comunemente utilizzati come un filtro e cercare regolarmente indici inutilizzati. Per ulteriori informazioni, consulta In che modo posso analizzare l'utilizzo degli indici e identificare gli indici non utilizzati?.

Impatto degli indici sulla scrittura dei dati

Sebbene gli indici possano migliorare le prestazioni delle query evitando la necessità di eseguire la scansione di tutti i documenti di una raccolta, questo miglioramento comporta un compromesso. Per ogni indice di una raccolta, ogni volta che un documento viene inserito, aggiornato o eliminato, il database deve aggiornare la raccolta e scrivere i campi in ciascuno degli indici per la raccolta. Ad esempio, se una raccolta dispone di nove indici, il database deve eseguire dieci scritture prima di riconoscere l'operazione al client. Pertanto, ogni indice aggiuntivo comporta latenza di scrittura aggiuntiva, I/O e aumento dello spazio di storage utilizzato complessivamente.

Le istanze del cluster devono essere dimensionate in modo appropriato per mantenere tutta la memoria del set di lavoro. Ciò evita la necessità di leggere continuamente le pagine degli indici dal volume di archiviazione, il che influisce negativamente sulle prestazioni e genera costi di I/O più elevati. Per ulteriori informazioni, consulta Dimensione delle istanze.

Per ottenere prestazioni ottimali, ridurre al minimo il numero di indici nelle raccolte, aggiungendo solo gli indici necessari per migliorare le prestazioni per le query comuni. Mentre i carichi di lavoro variano, una buona linea guida consiste nel mantenere il numero di indici per raccolta a cinque o meno.

Identificazione degli indici mancanti

Identificare gli indici mancanti è una best practice che consigliamo di eseguire regolarmente. Per ulteriori informazioni, consulta Come posso identificare gli indici mancanti?.

Identificazione degli indici non utilizzati

Identificare e rimuovere gli indici non utilizzati è una best practice che si consiglia di eseguire regolarmente. Per ulteriori informazioni, consulta In che modo posso analizzare l'utilizzo degli indici e identificare gli indici non utilizzati?.

Best practice di sicurezza

Per le best practice di sicurezza, è necessario utilizzare account AWS Identity and Access Management (IAM) per controllare l'accesso alle operazioni API di Amazon DocumentDB, in particolare le operazioni che creano, modificano o eliminano risorse Amazon DocumentDB. Tali risorse includono i cluster, i gruppi di sicurezza e i gruppi di parametri. È inoltre necessario utilizzare IAM per controllare le azioni che eseguono azioni amministrative comuni, come il backup e il ripristino dei cluster. Quando crei ruoli IAM, utilizza il principio del privilegio minimo.

• Applica privilegi minimi con il controllo accessi basato sui ruoli.

• Assegna un account IAM individuale a ogni persona che gestisce le risorse di Amazon DocumentDB. Non utilizzare l'utente Account AWS root per gestire le risorse di Amazon DocumentDB. Crea un utente IAM per tutti, incluso te stesso.

• Concedi a ciascun utente IAM il set minimo di autorizzazioni necessarie per svolgere i propri compiti.

• Utilizza gruppi IAM per gestire in modo efficace le autorizzazioni per più utenti. Per ulteriori informazioni su IAM, consulta la Guida per l'utente di IAM. Per informazioni sulle best practice IAM consulta Best Practice di IAM.

• Ruota periodicamente le credenziali IAM.

• Configura AWS Secrets Manager per ruotare automaticamente i segreti per Amazon DocumentDB. Per ulteriori informazioni, consulta Rotating Your AWS Secrets Manager Secrets e Rotating Secrets for Amazon DocumentDB nella Secrets AWS Manager User Guide.

• Concedi a ogni utente di Amazon DocumentDB il set minimo di autorizzazioni necessarie per svolgere le proprie mansioni. Per ulteriori informazioni, consulta Accesso al database tramite il controllo degli accessi basato sui ruoli.

• Usa Transport Layer Security (TLS) per crittografare i dati in transito e AWS KMS per crittografare i dati inattivi.

Ottimizzazione dei costi

Le seguenti best practice possono aiutarti a gestire e ridurre al minimo i costi quando usi Amazon DocumentDB. Per informazioni sui prezzi, consulta le domande frequenti sui prezzi di Amazon DocumentDB (con compatibilità con MongoDB) e Amazon DocumentDB (con compatibilità con MongoDB).

• Crea avvisi di fatturazione in corrispondenza delle soglie al 50% e 75% della fattura mensile attesa. Per ulteriori informazioni sulla creazione di avvisi di fatturazione, consulta Creazione di un allarme di fatturazione.

• L'architettura di Amazon DocumentDB separa storage ed elaborazione, quindi anche un cluster a istanza singola è estremamente durevole. Il volume di storage del cluster replica i dati in sei modi su tre zone di disponibilità, garantendo una durabilità estremamente elevata indipendentemente dal numero di istanze nel cluster. Un tipico cluster di produzione dispone di tre o più istanze per fornire la disponibilità elevata. Tuttavia, puoi ottimizzare i costi utilizzando un cluster di sviluppo a istanza singola quando non è richiesta la disponibilità elevata.

• Per scenari di sviluppo e di test, arresta un cluster quando non è più necessario e avvialo quando lo sviluppo riprende. Per ulteriori informazioni, consulta Arresto e avvio di un cluster Amazon DocumentDB.

• Sia TTL sia i flussi di modifica incorrono in I/O quando i dati vengono scritti, letti ed eliminati. Se queste funzionalità sono state abilitate ma non vengono utilizzate nell'applicazione, la disattivazione delle funzionalità può contribuire a ridurre i costi.

Utilizzo di parametri per identificare problemi a livello di prestazioni

Per identificare i problemi di prestazioni causati da risorse insufficienti e altri colli di bottiglia comuni, puoi monitorare i parametri disponibili per il tuo cluster Amazon DocumentDB.

Visualizzazione dei parametri relativi alle prestazioni

Monitora regolarmente i parametri relativi alle prestazione per osservare i valori medi, massimi e minimi per vari intervalli di tempo. Ciò ti consente di identificare quando le prestazioni subiscono un calo. Puoi anche impostare CloudWatch allarmi Amazon per determinate soglie metriche in modo da essere avvisato se vengono raggiunte.

Per risolvere i problemi relativi alle prestazioni, è importante comprendere le prestazioni di base del sistema. Quando configuri un nuovo cluster e lo esegui con un carico di lavoro tipico, acquisisci il valore medio, massimo e minimo di tutti i parametri relativi alle prestazioni a intervalli diversi (ad esempio, un'ora, 24 ore, una settimana, due settimane). Ciò ti permette di avere un quadro dei valori normali. Ciò aiuta anche a effettuare confronti delle attività durante le ore di punta e non di punta. Puoi quindi utilizzare queste informazioni per identificare quando le prestazioni scendono al di sotto dei livelli standard.

Puoi visualizzare le metriche delle prestazioni utilizzando o. AWS Management Console AWS CLI Per ulteriori informazioni, consulta Visualizzazione CloudWatch Dati.

Impostazione di una sveglia CloudWatch

Per impostare un CloudWatch allarme, consulta Using Amazon CloudWatch Alarms nella Amazon CloudWatch User Guide.

Valutazione dei parametri relativi alle prestazioni

Un'istanza ha diverse categorie di parametri. La modalità di determinazione dei valori accettabili dipende dal parametro.

CPU

• Utilizzo della CPU: la percentuale della capacità di elaborazione del computer utilizzata.

Memoria

• Memoria liberabile: quanta RAM è disponibile sull'istanza.

• Utilizzo dello swap: quanto spazio di swap viene utilizzato dall'istanza, in megabyte.

Operazioni di input/output

• IOPS in lettura, IOPS in scrittura: il numero medio di operazioni di lettura o scrittura su disco al secondo.

• Latenza di lettura, latenza di scrittura: il tempo medio per un'operazione di lettura o scrittura in millisecondi.

• Throughput di lettura, velocità effettiva di scrittura: il numero medio di megabyte letti o scritti su disco al secondo.

• Profondità della coda del disco: il numero di operazioni di I/O in attesa di essere scritte o lette dal disco.

Traffico di rete

• Throughput di ricezione in rete, throughput di trasmissione in rete: la velocità del traffico di rete da e verso l'istanza, espressa in megabyte al secondo.

Connessioni database

• Connessioni DB: il numero di sessioni client connesse all'istanza.

In generale, i valori accettabili per i parametri relativi alle prestazioni dipendono dalla baseline e dall'attività dell'applicazione. Indagare le variazioni della baseline coerenti o che rappresentano dei trend.

Di seguito sono riportati alcuni suggerimenti su tipi di parametri specifici:

• Consumo elevato di CPU: potrebbero essere appropriati valori elevati per il consumo di CPU, a condizione che siano in linea con gli obiettivi dell'applicazione (ad esempio velocità effettiva o concorrenza) e siano previsti. Se il consumo della CPU supera costantemente l'80%, valuta la possibilità di aumentare le dimensioni delle istanze.

• Elevato consumo di RAM: se la FreeableMemory metrica scende spesso al di sotto del 10% della memoria totale dell'istanza, prendi in considerazione la possibilità di aumentare le istanze. Per ulteriori informazioni su cosa succede quando l'istanza di DocumentDB subisce un'elevata pressione della memoria, consulta Amazon DocumentDB Resource Governance.

• Utilizzo dello swap: questa metrica dovrebbe rimanere pari o prossima allo zero. Se l'utilizzo di swap è significativo, valuta la possibilità di aumentare le dimensioni delle istanze.

• Traffico di rete: per quanto riguarda il traffico di rete, contatta l'amministratore di sistema per capire qual è il throughput previsto per la rete di dominio e la connessione Internet. Indaga il traffico di rete se il throughput è costantemente al di sotto del valore previsto.

• Connessioni al database: valuta la possibilità di limitare le connessioni al database se riscontri un numero elevato di connessioni utente e una riduzione delle prestazioni dell'istanza e dei tempi di risposta. Il numero ideale di connessioni utente per l'istanza dipende dalla classe di istanza e dalla complessità delle operazioni eseguite. In caso di problemi con i parametri relativi alle prestazioni, per migliorare la situazione puoi provare a ottimizzare le query più utilizzate e costose per verificare se ciò riduce la pressione sulle risorse di sistema.

Se le tue query vengono ottimizzate e il problema persiste, valuta la possibilità di aggiornare la classe di istanza di Amazon DocumentDB a una classe con più risorse (CPU, RAM, spazio su disco, larghezza di banda di rete, capacità di I/O) correlate al problema riscontrato.

Ottimizzazione di query

Uno dei modi migliori per migliorare le prestazioni di un cluster consiste nell'ottimizzare le query più comuni e a uso più intensivo di risorse per renderle meno costose da eseguire.

Puoi utilizzare il profiler (vedi Profilazione delle operazioni di Amazon DocumentDB) per registrare il tempo di esecuzione e i dettagli delle operazioni eseguite nel cluster. Il profiler è utile per monitorare le operazioni più lente sul cluster per aiutare a migliorare le prestazioni delle singole query e le prestazioni complessive del cluster.

Puoi inoltre utilizzare il comando explain per informazioni su come analizzare un piano di query per una determinata query. Utilizza queste informazioni per modificare una query o una raccolta sottostante in modo da migliorare le prestazioni della query (ad esempio, aggiungendo un indice).

Carichi di lavoro di serie temporali e TTL

L'eliminazione del documento risultante dalla scadenza dell'indice TTL è un processo di best effort. L'eliminazione dei documenti entro un termine specifico non è garantita. Fattori come la dimensione dell'istanza, l'utilizzo delle risorse dell'istanza, la dimensione del documento, il throughput complessivo, il numero di indici e il fatto che gli indici e il working set si adattino o meno nella memoria possono influenzare i tempi di eliminazione dei documenti scaduti dal processo TTL.

Quando il monitor TTL elimina i documenti, ogni eliminazione comporta costi di IO incrementando l'importo in fattura. Se la velocità effettiva e la velocità di eliminazione TTL aumentano, dovresti aspettarti una fattura più elevata a causa dell'aumento dell'utilizzo di I/O. Tuttavia, se non crei un indice TTL per eliminare i documenti, ma li segmenti in raccolte in base al tempo e li elimini semplicemente quando non sono più necessari, non dovrai sostenere alcun costo di I/O. Questo può essere molto più conveniente rispetto all'utilizzo di un indice TTL.

Per i carichi di lavoro delle serie temporali, è possibile considerare la creazione di raccolte in sequenza anziché di un indice TTL, poiché le raccolte in sequenza possono rappresentare un modo più performante per eliminare i dati e ridurre l'utilizzo di I/O. Se si dispone di raccolte di grandi dimensioni (in particolare di raccolte superiori a 1 TB) o costi di eliminazione TTL rappresentano un problema, si consiglia di ripartire i documenti in raccolte in base al tempo e di eliminare le raccolte quando i documenti non sono più necessari. Puoi creare una raccolta al giorno o alla settimana, a seconda della frequenza di inserimento dei dati. Anche se i requisiti variano a seconda dell'applicazione, una buona regola generale è quella di avere raccolte più piccole piuttosto che alcune raccolte di grandi dimensioni. L'eliminazione di queste raccolte non comporta costi di IO e può risultare significativamente più conveniente rispetto all'utilizzo di un indice TTL.

Migrazioni

Come best practice, durante la migrazione dei dati su Amazon DocumentDB, consigliamo di creare gli indici in Amazon DocumentDB prima di migrare i dati. Creando per primi gli indici, si riduce il tempo complessivo e si aumenta la velocità della migrazione. A tale scopo, puoi utilizzare Amazon DocumentDB Index Tool. Per ulteriori informazioni sulle migrazioni, consulta la guida alla migrazione di Amazon DocumentDB.

Consigliamo inoltre, prima di migrare il database di produzione, di testare completamente l'applicazione su Amazon DocumentDB, prendendo in considerazione funzionalità, prestazioni, operazioni e costi.

Utilizzo di gruppi di parametri di cluster

È consigliabile provare le modifiche apportate al gruppo di parametri di cluster su un cluster di test prima di applicarle ai cluster di produzione. Per ulteriori informazioni sul backup di un cluster, consulta Backup e ripristino in Amazon DocumentDB.

Query di pipeline di aggregazione

Quando crei una query di pipeline di aggregazione con più fasi e valuti solo un sottoinsieme dei dati nella query, utilizza la fase $match come prima fase o all'inizio della pipeline. Utilizzando prima $match ridurrai il numero di fasi successive dei documenti all'interno della query di pipeline di aggregazione che sarà necessario elaborare, migliorando così le prestazioni della query.

batchInsert e batchUpdate

Quando si esegue una frequenza elevata di batchUpdate operazioni simultanee batchInsert e/o e la quantità di FreeableMemory (CloudWatch Metric) scende a zero sull'istanza principale, è possibile ridurre la concomitanza dell'inserimento in batch o del carico di lavoro di aggiornamento oppure, se non è possibile ridurre la concorrenza del carico di lavoro, aumentare la dimensione dell'istanza per aumentare la quantità diFreeableMemory.