Cardano Node 11.2.1 riduce l'uso di memoria durante gli snapshot del ledger
La versione preliminare offre anche agli operatori di stake pool un'opzione di archiviazione su disco da testare sulle macchine che producono blocchi.
By SongMarketCap
Updated:
Intersect ha pubblicato Cardano Node 11.2.1 il 10 novembre come versione preliminare di manutenzione per la serie 11.2. Le note di rilascio descrivono una correzione per i picchi temporanei di memoria quando il nodo salva gli snapshot del ledger. Riportano anche che la configurazione LSM basata su disco ha soddisfatto i requisiti prestazionali di Ouroboros Praos per la produzione dei blocchi.
Gli snapshot del ledger usano meno memoria
Un nodo Cardano salva periodicamente su disco una copia dello stato del ledger così da poter riprendere da quel punto dopo un riavvio. In precedenza, la scrittura di uno snapshot poteva aumentare temporaneamente l'uso di memoria di circa la dimensione dello snapshot stesso. Secondo le note di rilascio, la 11.2.1 elimina quel picco. Il database della chain inoltre smette di mantenere in memoria lo stato iniziale del ledger, il che può risparmiare diverse centinaia di MiB sulle reti con ampi insiemi iniziali di output di transazione non spesi o deleghe.
La versione modifica anche il momento in cui vengono scritti gli snapshot. Durante la sincronizzazione iniziale, il nodo scrive gli snapshot non appena vengono richiesti. Applica un ritardo casuale dopo aver raggiunto la punta della chain. Su mainnet e Preprod, il ritardo massimo scende da sei ore a una.
Intersect aveva in precedenza identificato una regressione della memoria nella serie 11.1.x e delineato un piano per riportarne l'uso più vicino ai livelli della 11.0. La correzione agli snapshot affronta una specifica fonte di picco di memoria durante una scrittura su disco. La quantità risparmiata durante tale operazione dipende dalla dimensione dello snapshot.
Cosa significa l'archiviazione basata su disco per gli stake pool
Il design UTxO-HD di Cardano consente a un nodo di mantenere su disco parte dei dati degli output di transazione non spesi. Le note di rilascio riportano che il backend di archiviazione LSM ha soddisfatto i requisiti prestazionali di Ouroboros Praos, il protocollo che Cardano usa per produrre blocchi. La tabella hardware indica 24 GB di RAM per la configurazione in memoria e 8 GB per la configurazione basata su disco, con il valore minimo più basso ancora in fase di convalida.
Per un operatore di stake pool, la questione pratica è se il nodo possa usare meno RAM rispettando al contempo le scadenze del protocollo per la produzione dei blocchi. Spostare parte dello stato del ledger su disco rende le prestazioni dell'archiviazione parte di quel calcolo. Un relay può aiutare un operatore a valutare la configurazione, mentre un test sull'hardware destinato alla produzione dei blocchi può mostrare come si comporta sotto quel carico di lavoro. Intersect raccomanda di testare la configurazione LSM prima di distribuirla su un nodo che produce blocchi.
[NEWSBREAK]
Cosa cambia per gli operatori che passano dalla 11.1.x
La serie 11.2 introduce un formato con versionamento per i file di configurazione di rete pubblicati. Le configurazioni piatte esistenti funzionano ancora con la 11.2 e possono essere convertite con cardano-node config migrate. I nodi precedenti alla 11.2 non possono leggere i nuovi file pubblicati.
Wallet, explorer e servizi API affrontano una modifica di compatibilità separata quando si connettono a un nodo della serie 11.2. La serie rimuove le versioni dalla 16 alla 22 del protocollo node to client, insieme alle query che dipendevano esclusivamente da tali versioni.