Firebird 2.0 garbage collector
Il motore conosce ogni versione dei record prodotta da istruzioni update/delete e può rimuoverle non appena la più vecchia transazione snapshot (OST) lo consente. Questo elimina la necessità di rileggere le pagine con queste versioni su richiesta dell’utente (ad esempio SELECT COUNT(*) FROM table) ed evita situazioni in cui queste versioni non vengono mai lette (ovviamente lo sweep ha sempre rimosso tutte le versioni di record inutilizzate). Inoltre, c’è un’alta probabilità che le pagine necessarie risiedano ancora nella cache del buffer, riducendo così le operazioni di I/O su disco aggiuntive.
Tra la notifica al garbage collector della pagina con versioni inutilizzate e il momento in cui il garbage collector leggerà questa pagina, una nuova transazione può aggiornare il record e il garbage collector non può ripulire questo record se il numero della nuova transazione è superiore all’OST o è ancora attiva. In questo caso, il motore notifica nuovamente il garbage collector con il numero di questa pagina e quest’ultimo ripulirà la spazzatura in un momento successivo (il vecchio garbage collector “dimenticherà” questa pagina finché l’utente non la leggerà di nuovo).
Sono ora possibili sia la garbage collection cooperativa che quella in background. Per gestirla, è stato introdotto il nuovo parametro di configurazione “GCPolicy”. Può essere impostato su:
-
a) cooperative - la garbage collection viene eseguita solo in modalità cooperativa, come prima di IB6. Ogni richiesta utente è responsabile della rimozione delle versioni di record inutilizzate. È così che funzionava il motore prima di IB6. Questa è l’unica opzione per la modalità Classic Server. Il motore non tiene traccia delle versioni prodotte da istruzioni update e delete
-
b) background - la garbage collection viene eseguita solo dal thread in background, come in IB6 e versioni successive. Nessuna richiesta utente rimuove le versioni di record inutilizzate. Invece, la richiesta utente notifica al thread dedicato del garbage collector il numero di pagina in cui viene rilevata una versione di record inutilizzata. Il motore ricorda anche i numeri di pagina in cui l’istruzione update/delete ha creato versioni precedenti.
-
c) combined - vengono eseguite sia la garbage collection in background che quella cooperativa.
Il valore predefinito è “combined” per SuperServer. ClassicServer ignora questo parametro e funziona sempre in modalità “cooperative”.