Firefox їсть ваш SSD - ось як це виправити

Якщо ви користуєтеся Firefox, ми повинні змінити налаштування. Сучасні багатоядерні процесорні системи та більша кількість оперативної пам’яті дозволяють користувачам одночасно відкривати кілька вкладок та вікон Firefox. Це може мати ненавмисний ефект для цих твердотільних накопичувачів, оскільки дані сховища сеансів можуть постійно записувати дані в NAND. Це питання обговорюється у темі форуму STH, де ви можете стежити за обговоренням.

Спостереження за проблемою: Важкі SSD-записи з Firefox

Цілком випадково я випустив безкоштовну копію SSDLife два дні поспіль, коли я насправді не використовував свою робочу станцію ні для чого іншого, крім електронної пошти та перегляду. Для тих, хто не знайомий з цим інструментом, він просто повідомляє приблизний термін служби вкладеного твердотільного накопичувача, а також відображає обсяг прочитаних та записаних даних.

У моєму випадку SSDLife повідомив мене про це 12 Гб було записано на SSD за один день. Оскільки я не пам’ятав, як за попередній день завантажував величезні файли чи відвідував будь-які нові сайти, які могли призвести до того, що багато нового вмісту було кешовано, це мене спантеличило. Я спостерігав за цією статистикою протягом наступних кількох тижнів, і така поведінка залишалася незмінною. Навіть якби робоча станція залишалася простою, на ній не працювало нічого, крім кількох вікон браузера, вона незмінно писала б принаймні 10 Гб на день на SSD.

їсть
firefox-with-32gb-написано-за-один день

Щоб з’ясувати, що відбувається, я запустив Resource Monitor і подивився використання диска.

У самому верху списку знаходився Firefox, який невтомно писав десь від 300 КБ до 2 МБ у секунду у файл, який називається «recovery.js». Дослідження показало, що це файл резервної копії сеансу Firefox, який використовується для відновлення сеансів браузера у випадку аварії браузера або ОС. Це надзвичайно корисна функціональність. Мені було відомо про те, що Firefox має цю функцію, але я навіть не здогадувався, що інформація про сеанси є такою важкою!

Досліджуючи проблему трохи більше протягом наступного дня, я виявив, що справи йдуть гірше, ніж я спочатку думав, і “recovery.js” - не єдиний задіяний файл. Якщо хтось хоче скопіювати, ось що я зробив сьогодні вранці:

  • Я скинув інтервал browser.sessionstore.interval до 15000, а потім позбувся всіх моїх відкритих на даний момент вікон FF.
  • Я відкрив одне вікно, в якому працював лише Google, залишив його пару хвилин, а потім закрив.
  • Я знову запустив браузер, і після останнього перезапуску файл recovery.js був розміром лише 5 КБ, ніж приблизно 900 КБ раніше.
  • Потім я відкрив купу випадкових оглядів для Samsung 850 pro та Samsung Galaxy S7 у двох окремих вікнах. Просто шукайте "огляд samsung 850 pro" та "огляд samsung galaxy s7", а потім спустилися вниз до списку результатів, відкривши їх у нових вкладках.
  • Я відкрив 3-е вікно і створив купу вкладок, що відображають перші сторінки для різних сайтів новин.
  • Я запустив Process Monitor і налаштував його для відстеження recovery.js та файлів cookie *:

  • Я перейшов у Файл-> Захопити події та вимкнув його. Видалено всі події, які зараз відображались.
  • Я повернувся до Файл-> Захопити події та знову ввімкнув його. Залишив три вікна FireFox без роботи 45 хвилин, поки я використовував Chrome.
  • Потім я перейшов до Інструменти-> Підсумок файлу, щоб отримати загальну статистику.
  • Firefox встиг написати 1,1 Гб на диск із переважною більшістю даних, що надходять у файли cookie *.

Зверніть увагу, що recovery.js зумів накопичити лише близько 1,3 МБ записів.

Я повернувся до одного з вікон Firefox і відкрив свою поштову скриньку outlook.com. Видалено всі події в Process Monitor і знову розпочато зйомку. Знову ж таки, я залишив усі вікна Firefox без роботи, але лише для

10 хвилин. Цього разу recovery.js був о

1,5 Мб, і до нього пішло лише приблизно 1/4 частини часу. У файлах cookie * було записано купу даних, як і раніше.

Залежно від того, що у вас відкрито на ваших вкладках, Firefox може скидати тонни даних у recovery.js, файли cookie * або в обидва. Ви працюєте на обсязі 1,1 ГБ кожні 45 хвилин

35 ГБ/день записується на ваш твердотільний диск, якщо ви залишаєте машину запущеною. І принаймні в моєму випадку це був навіть не найгірший приклад того, скільки даних може йти в recovery.js. У моїх початкових тестах я працював у Firefox зі швидкістю 2 МБ/с для запису в цей файл, і потік написання ніколи не забивався, завжди відображаючись у верхній частині списку в Resource Monitor.

Легке виправлення

Покопавшись, я з’ясував, що цією поведінкою керує параметр, до якого ви можете отримати доступ, ввівши “about: config” в адресному рядку. Цей параметр називається: -browser.sessionstore.interval

За замовчуванням встановлено значення 15 секунд. У моєму випадку я скидаю його на більш здоровий (принаймні для мене) 30 хвилин. З тих пір я бачу близько 2 Гб записаних на диск лише тоді, коли моя робоча станція не працює, що все ще здається багато, але в 5 разів менше, ніж раніше.

Підсумок полягає в тому, що якщо у вас є твердотільні накопичувачі нижчого рівня на деяких машинах, ви можете перевірити та налаштувати конфігурацію Firefox. Ці накопичувачі можуть розраховувати приблизно на 20 Гб записів на день, і лише Firefox може використовувати більше половини цього. Це особливо актуально, якщо ви схожі на мене і у вас постійно відкрито кілька вікон браузера, кожна з численними вкладками. Зміна цього параметра може навіть допомогти на звичайних жорстких дисках. Ваша машина почуватиметься швидше, якщо їй не доведеться постійно писати цю інформацію про сеанс. У темі форуму STH ми бачили, що вміст, відкритий у браузері, має великий вплив на записи, як і кількість відкритих вікон та вкладок. Якщо ви використовуєте Firefox і твердотільний накопичувач із меншою витривалістю, вам слід негайно перевірити це.

Якщо вам цікаво, як це порівняно з реальним використанням корпоративних твердотільних накопичувачів, компанія STH провела дослідження, купуючи сотні використовуваних твердотільних накопичувачів для підприємств/центрів обробки даних з ebay та перевіряючи дані SMART на реальне використання DWPD. Див

Оновлення 1: Ми тестуємо інші браузери. На даний момент посеред тестування версії Chrome 52.0.2743.116 м. На цій машині ми змогли побачити швидкість запису понад 24 Гб/день (див. Тут.)