Dacă sunteți utilizator de Firefox, avem o setare care trebuie modificată. Sistemele moderne de procesare multi-core de astăzi și cantități mai mari de RAM permit utilizatorilor să deschidă mai multe file și ferestre Firefox simultan. Acest lucru poate avea un efect neintenționat pentru acele SSD-uri, deoarece datele de stocare a sesiunilor pot scrie date în mod constant în NAND. Această problemă este discutată într-un subiect al forumului STH, unde puteți urmări discuția.

Observarea problemei: Scrieri SSD grele de la Firefox

Pur întâmplător, am lansat o copie gratuită a SSDLife în două zile consecutive în care nu mi-am folosit cu adevărat stația de lucru pentru altceva decât pentru e-mail și navigare. Pentru cei dintre voi care nu sunt familiarizați cu acest instrument, acesta raportează pur și simplu durata de viață estimată pentru SSD-ul atașat și arată, de asemenea, cantitatea de date citite și scrise.

În cazul meu, SSDLife m-a anunțat că 12 GB a fost scris pe SSD într-o singură zi. Întrucât nu mi-am amintit că am descărcat fișiere uriașe în ziua precedentă sau că am vizitat site-uri noi care ar fi putut duce la scăderea multor conținuturi noi în cache, acest lucru m-a nedumerit. Am monitorizat aceste statistici în următoarele câteva săptămâni și acest comportament a rămas constant. Chiar dacă stația de lucru ar fi lăsată inactivă fără să ruleze nimic, dar câteva ferestre ale browserului, ar scrie invariabil cel puțin 10 GB pe zi către SSD.

remediați
Firefox-cu-32GB-scris-într-o-zi

Pentru a afla ce se întâmplă, am pornit Resource Monitor și am analizat utilizarea discului.

În partea de sus a listei se afla Firefox, care scria neobosit oriunde între 300K și 2MB pe secundă într-un fișier numit „recovery.js”. Cercetările au arătat că acesta este fișierul de rezervă al sesiunii Firefox, care este utilizat pentru a restabili sesiunile browserului dvs. în caz de blocare a browserului sau a sistemului de operare. Aceasta este o funcționalitate extrem de utilă. Am fost conștient de faptul că Firefox avea această caracteristică, dar habar nu aveam că informațiile despre sesiune erau atât de grele!

Cercetând problema un pic mai mult în ziua următoare, am descoperit că lucrurile sunt mai rele decât am crezut inițial și „recovery.js” nu este singurul fișier implicat. În cazul în care cineva vrea să reproducă, iată ce am făcut în această dimineață:

  • Am resetat browser.sessionstore.interval la 15000 și apoi am scăpat de toate ferestrele FF deschise în prezent.
  • Am deschis o singură fereastră cu doar Google rulând în ea, am lăsat-o așezată câteva minute, apoi am închis-o.
  • Am pornit browserul din nou și la această repornire finală fișierul recovery.js avea doar 5 KB în dimensiune, în scădere de la aproximativ 900 KB înainte.
  • Apoi, am deschis o grămadă de recenzii aleatorii pentru Samsung 850 pro și Samsung Galaxy S7 în două ferestre separate. Ați căutat pur și simplu „Samsung 850 pro review” și „samsung galaxy s7 review” și apoi am coborât lista de rezultate deschizându-le în file noi.
  • Am deschis o a treia fereastră și am creat o grămadă de file care afișează primele pagini pentru diverse site-uri de știri.
  • Am lansat Process Monitor și l-am configurat pentru a urmări fișierele recovery.js și cookie *:

  • Am fost la File-> Capture Events și l-am dezactivat. Au fost șterse toate evenimentele care se afișau în prezent.
  • M-am întors la File-> Capture Events și l-am reactivat. Am lăsat cele trei ferestre FireFox în repaus 45 de minute în timp ce foloseam în schimb Chrome.
  • Apoi am mers la Instrumente-> Rezumat fișier pentru a obține statistici generale.
  • Firefox a reușit să scrie 1,1 GB să disc cu marea majoritate a datelor care intră în fișiere cookie *.

Rețineți că recovery.js a reușit să acumuleze doar aproximativ 1,3 MB de scrisuri.

M-am întors la una dintre ferestrele Firefox și mi-am deschis cutia poștală outlook.com. Am șters toate evenimentele din Process Monitor și am reluat captura. Din nou, am lăsat toate ferestrele Firefox așezate inactiv, dar numai pentru

10 minute. De data aceasta recovery.js a fost la

1,5 MB și a durat doar aproximativ 1/4 din timp pentru a ajunge acolo. Fișierele Cookie * aveau o mulțime de date scrise, ca înainte.

În funcție de ceea ce aveți deschis în filele dvs., Firefox ar putea arunca tone de date în recovery.js, fișiere cookie * sau ambele. Rulați la 1,1 GB pentru fiecare 45 de minute, vă uitați

35 GB/zi scris pe SSD-ul dvs. dacă vă lăsați mașina în funcțiune. Și cel puțin în cazul meu, acesta nu a fost nici măcar cel mai prost exemplu de cât de multe date ar putea intra în recovery.js. În testele mele inițiale am urmărit Firefox la 2 MB/s scriind în acest fișier și firul de scriere nu a murit niciodată, apărând întotdeauna în partea de sus a listei în Resource Monitor.

Remediul ușor

După câteva săpături, am aflat că acest comportament este controlat de un parametru la care puteți accesa tastând „about: config” în bara de adrese. Acest parametru se numește: -browser.sessionstore.interval

Este setat la 15 secunde în mod implicit. În cazul meu, l-am resetat la 30 de minute mai sănătos (cel puțin pentru mine). De atunci, văd aproximativ 2 GB scrise pe disc numai când stația mea de lucru este lăsată inactivă, ceea ce se simte mult, dar este de 5 ori mai puțin decât înainte.

Concluzia este că, dacă aveți SSD-uri cu o capacitate mai mică la unele dintre mașinile dvs., vă recomandăm să verificați și să vă modificați configurația Firefox. Aceste unități pot fi evaluate pentru aproximativ 20 GB de scrieri pe zi, iar Firefox singur ar putea folosi mai mult de jumătate din acestea. Acest lucru este valabil mai ales dacă sunteți ca mine și aveți deschise în permanență mai multe ferestre de browser, fiecare cu numeroase file. Schimbarea acestui parametru poate ajuta chiar și cu HDD-urile normale. Aparatul dvs. se va simți mai repede dacă nu trebuie să scrie constant aceste informații despre sesiune. Am văzut în firul forumului STH că conținutul deschis în browser are un impact major asupra scrierilor, la fel ca și numărul de ferestre și file deschise. Dacă utilizați Firefox și un SSD cu rezistență la scriere mai scăzută, ar trebui să verificați imediat acest lucru.

Dacă vă întrebați cum se compară acest lucru cu utilizarea SSD pentru întreprinderi din lumea reală, STH a făcut un studiu cumpărând sute de SSD-uri întreprinderi/centre de date folosite de pe eBay și verificând datele SMART pentru utilizarea reală a DWPD. A se vedea: SSD-uri de întreprindere folosite: disecarea populației noastre SSD de producție

Actualizare 1: Testăm alte browsere. În prezent, în mijlocul unui test de versiune Chrome 52.0.2743.116 m. Am putut vedea un ritm de peste 24 GB/zi de scrieri pe acest aparat (vezi aici.)