La primavera è già passata da qualche tempo, ma il mio evidente ritardo nel percepirla ha fatto slittare in avanti dei lavori di pulizia che rimandavo da troppo tempo. Il mio profilo principale di Firefox (costantemente replicato e sotto backup) conteneva dati davvero troppo vecchi, facendo arrivare alcuni dei database SQLite dell’applicativo a occupazioni disco fuori (e di molto) dallo standard al quale si è abituati nelle nuove installazioni (o nei profili più puliti). Per questo motivo ho scelto di prendere scopa, paletta e smacchiatore per dare un po’ più di piglio energico al browser di casa Mozilla, il predefinito sulle mie macchine.
Ti spiego in poche parole (e diversi dati) ciò che ho fatto. Ti mando subito a leggere qualche riga riguardo SQLite nel caso in cui non sapessi di cosa si sta parlando, male non può certamente fare. I file incriminati e importanti sono sostanzialmente due: places.sqlite e webappsstore.sqlite. Prima di partire, una giusta cultura di base: il primo file (database, in realtà ) contiene tutta la cronologia di navigazione in base ai criteri da te impostati all’interno delle opzioni di Firefox, non contiene i Segnalibri contiene i Segnalibri nella tabella moz_bookmarks, che viene toccata durante la pulizia solo per rimuovere spazi lasciati vuoti dall’utilizzatore (qui la pagina di KB su mozillaZine). Il secondo file invece conserva i dati che generalmente si vanno a compilare nelle form dei siti web che visitiamo, si tratta di un database molto delicato che non andrebbe mai modificato manualmente e che puoi permetterti di perdere solo se non ti secca ricominciare a creare una cronistoria dei dati che dovrai inserire a mano (per esempio) durante la registrazione di un modulo, una nuova iscrizione a chissà quale forum o così via (qui la pagina KB su mozillaZine).
Sia chiaro: Firefox continuerà a funzionare sulla tua postazione anche se cancelli completamente i due file, poi però non lamentarti se vai a perdere la cronologia di navigazione o i dati precedentemente immessi nei moduli (e non solo), di sicuro ci guadagni in velocità :-)
Io ho voluto clonare il profilo e mettere alla prova un’estensione che promette di andare ad alleggerire questi due file a patto di trovare delle voci orfane, quindi eliminabili in via definitiva, ricostruendo il database e popolandolo solo con le voci effettivamente vive e vegete (vedi: vacuum SQLite). L’estensione è Places Maintenance e la puoi trovare ovviamente su AMO:
Perché proprio lei in un mare di altre estensioni dedicate alla manutenzione dei database SQLite di Firefox? Perché è sviluppata da un amico connazionale e profondo conoscitore di Firefox, Mak, Firefox Team Engineering Consultant.
A installazione terminata (non richiede riavvio, nda) ho lanciato immediatamente una scansione della situazione sul profilo clonato, questo il risultato:
Statistics Database size is 81920 KiB user_version is 32 page_size is 32768 cache_size is -2048 journal_mode is wal synchronous is 1 History can store a maximum of 104858 unique pages Table moz_places has 104024 records Table moz_historyvisits has 281408 records Table moz_inputhistory has 469 records Table moz_bookmarks has 641 records Table moz_keywords has 0 records Table sqlite_sequence has 1 records Table moz_favicons has 4080 records Table moz_annos has 2192 records Table moz_anno_attributes has 13 records Table moz_items_annos has 172 records Table sqlite_stat1 has 15 records Table moz_hosts has 6291 records Index sqlite_autoindex_moz_inputhistory_1 Index sqlite_autoindex_moz_keywords_1 Index sqlite_autoindex_moz_favicons_1 Index sqlite_autoindex_moz_anno_attributes_1 Index sqlite_autoindex_moz_hosts_1 Index moz_places_faviconindex Index moz_places_hostindex Index moz_places_visitcount Index moz_places_frecencyindex Index moz_places_lastvisitdateindex Index moz_historyvisits_placedateindex Index moz_historyvisits_fromindex Index moz_historyvisits_dateindex Index moz_bookmarks_itemindex Index moz_bookmarks_parentindex Index moz_bookmarks_itemlastmodifiedindex Index moz_places_url_uniqueindex Index moz_places_guid_uniqueindex Index moz_bookmarks_guid_uniqueindex Index moz_annos_placeattributeindex Index moz_items_annos_itemattributeindex Index moz_keywords_placepostdata_uniqueindex
Occhio a:
Database size is 81920 KiBHistory can store a maximum of 104858 unique pagesTable moz_places has 104024 recordsTable moz_historyvisits has 281408 records
Ho volutamente evidenziato i valori più importanti a livello di onerosità su database, ciò che più occupava il file SQLite era chiaramente il contenuto della mia cronologia, praticamente quasi mai resettata. Il valore massimo delle pagine uniche memorizzate nella cronolgia è fisso a 104858 poiché dettato da una configurazione di about:config, per l’esattezza si tratta di places.history.expiration.transient_current_max_pages.
Ho lanciato un’ottimizzazione senza toccare alcunché, provando a lasciare invariato il contenuto della navigazione passata e ho dato un’occhiata ai risultati:
Statistics Database size is 71680 KiB user_version is 32 page_size is 32768 cache_size is -2048 journal_mode is wal synchronous is 1 History can store a maximum of 104858 unique pages Table moz_places has 104026 records Table moz_historyvisits has 281412 records Table moz_inputhistory has 469 records Table moz_bookmarks has 641 records Table moz_keywords has 0 records Table sqlite_sequence has 1 records Table moz_favicons has 4080 records Table moz_annos has 2192 records Table moz_anno_attributes has 13 records Table moz_items_annos has 172 records Table sqlite_stat1 has 15 records Table moz_hosts has 6291 records Index sqlite_autoindex_moz_inputhistory_1 Index sqlite_autoindex_moz_keywords_1 Index sqlite_autoindex_moz_favicons_1 Index sqlite_autoindex_moz_anno_attributes_1 Index sqlite_autoindex_moz_hosts_1 Index moz_places_faviconindex Index moz_places_hostindex Index moz_places_visitcount Index moz_places_frecencyindex Index moz_places_lastvisitdateindex Index moz_historyvisits_placedateindex Index moz_historyvisits_fromindex Index moz_historyvisits_dateindex Index moz_bookmarks_itemindex Index moz_bookmarks_parentindex Index moz_bookmarks_itemlastmodifiedindex Index moz_places_url_uniqueindex Index moz_places_guid_uniqueindex Index moz_bookmarks_guid_uniqueindex Index moz_annos_placeattributeindex Index moz_items_annos_itemattributeindex Index moz_keywords_placepostdata_uniqueindex
Database size is 71680 KiBHistory can store a maximum of 104858 unique pagesTable moz_places has 104026 recordsTable moz_historyvisits has 281412 records
Un risparmio sicuramente interessante, ma sceso appena di –circa– 10 MB, ancora poco in confronto a un file che superava gli 80MB. Ho quindi scelto di mantenere esclusivamente gli ultimi 6 mesi di cronolgia di navigazione del browser, ottenendo (tramite lo stesso procedimento) un risultato nettamente più significativo:
Orphans expiration + Database cleaned up > Coherence check + The database is coherent > Vacuum Initial database size is 71680 KiB + The database has been vacuumed Final database size is 30720 KiB
Initial database size is 71680 KiBFinal database size is 30720 KiB
Un risparmio di circa 50MB rispetto al file originale, un sacrificio più che accettabile considerando che in 6 mesi ho certamente visitato siti web ai quali sono solito passare a fare un saluto, perdendo chi probabilmente non utilizzo così frequentemente (o non utilizzo più, tanto per farla più drastica). Il nuovo report fatto girare subito dopo il vacuum parla chiaro:
Statistics Database size is 30720 KiB user_version is 32 page_size is 32768 cache_size is -2048 journal_mode is wal synchronous is 1 History can store a maximum of 104858 unique pages Table moz_places has 40051 records Table moz_historyvisits has 55735 records Table moz_inputhistory has 165 records Table moz_bookmarks has 641 records Table moz_keywords has 0 records Table sqlite_sequence has 1 records Table moz_favicons has 2036 records Table moz_annos has 819 records Table moz_anno_attributes has 12 records Table moz_items_annos has 172 records Table sqlite_stat1 has 15 records Table moz_hosts has 3313 records Index sqlite_autoindex_moz_inputhistory_1 Index sqlite_autoindex_moz_keywords_1 Index sqlite_autoindex_moz_favicons_1 Index sqlite_autoindex_moz_anno_attributes_1 Index sqlite_autoindex_moz_hosts_1 Index moz_places_faviconindex Index moz_places_hostindex Index moz_places_visitcount Index moz_places_frecencyindex Index moz_places_lastvisitdateindex Index moz_historyvisits_placedateindex Index moz_historyvisits_fromindex Index moz_historyvisits_dateindex Index moz_bookmarks_itemindex Index moz_bookmarks_parentindex Index moz_bookmarks_itemlastmodifiedindex Index moz_places_url_uniqueindex Index moz_places_guid_uniqueindex Index moz_bookmarks_guid_uniqueindex Index moz_annos_placeattributeindex Index moz_items_annos_itemattributeindex Index moz_keywords_placepostdata_uniqueindex
Database size is 30720 KiBHistory can store a maximum of 104858 unique pagesTable moz_places has 40051 recordsTable moz_historyvisits has 55735 records
Partito con un places.sqlite da più di 80MB e un webappsstore.sqlite da circa 101MB, mi ritrovo con 30MB circa di database cronologico ma un webappstore.sqlite ancora particolarmente obeso.
Ho cercato altri casi simili e mi sono imbattuto su una segnalazione di BugZilla: bugzilla.mozilla.org/show_bug.cgi?id=857888. È partita da un problema relativo a Firefox sul mondo Mobile, ma pare soffrirne anche la versione PC, come confermato anche da una discussione su Reddit (r/firefox)
PSA: Large webappsstore.sqlite file in your profile will heavily affect the responsiveness of Firefox’s UI from firefox
La scelta drastica? Rinominare il database webappsstore.sqlite per non farlo più trovare a Firefox (ovviamente chiuso) il quale lo ha creato da zero una volta riaperto, ho provato così a perdere la cronologia dei moduli e delle applicazioni utilizzate fino a quel momento:
Il risultato? Ho utilizzato il profilo sul quale ho effettuato manutenzione per una settimana, ritenendolo adatto a diventare il principale perché la “perdita” non giustificava (secondo me) i rallentamenti sporadici del browser. Oggi sono fermamente convinto di aver fatto la scelta migliore, anche se fino a quando ci saranno siti web contenenti schifezze in Flash e simili, si continuerà ad avere un’occupazione importante del plugin-container.exe che permette a plugin (come quello Adobe) di girare in background, nonostante il Click-2-Play.
Occhio sempre a ciò che fai e dove metti le mani, ma mai abbandonare il tuo fido strumento di navigazione, potrebbe risentirne pesantemente la tua pazienza! ;-)
Ultimo aggiornamento: 5/7/16 10:20 Corretto dettaglio sui Segnalibri in places.sqlite (https://twitter.com/Gioxx/status/750243831132585985)
Faccio riferimento a un vecchio articolo datato 2014, nel quale vi parlavo di uno script PS1 che avevo lasciato su un Domain Controller della rete per verificare l’utilizzo di una password errata per un determinato account di dominio. Quello script mi è tornato utile ancora una volta e oggi vi propongo il suo ultimo aggiornamento, in grado di monitorare il blocco dell’account di Active Directory, con conseguente mail di allerta a 3 diversi indirizzi di posta (mio e di due colleghi, in CC).
To Punish And Enslave - © 2007-2017 