Комментарии 166
Я давно это заметил, но решение увидел другое — кэш браузера сделал на RAM-диске. Хотя статья очень полезная, спасибо.
А при выключении ваша информация сбрасывается куда-то или безвозвратно теряется?
Я сделал с Chrome точно так же. При выключении кэш стирается, но на скорость работы браузера это особенно не влияет.
Есть программные реализации RAM-дисков, которые сохраняют образ диска в файл и восстанавливают после перезапуска.
Нет ничего страшного в безвозвратной потере кэша. Но, насколько я понимаю, в статье речь о данных, записываемых в папку профиля, а её-то хранить на RAM-диске затруднительно.
Храню весь профиль на RAM-диске, проблем нет.
При выключении или перезагрузке компьютера у вас сохраняется на SSD весь RAM-диск или только реально изменившиеся файлы?
Если UPS есть. А если нету, то обидно потерять историю за целый день.
Да и собственно, такими объемами SSD не убить за обозримый промежуток времени. Жало, конечно. Ведь это бессмысленные многократные перезаписывания из пустого в порожнее. Но это не те объемы, из-за которых стоит беспокоиться и пихать конфиги в рам-диск.
Тут бы разрабов FF куда-нибудь макнуть на пару минут, чтобы немного освежили мозги и поняли, что за 10 лет пора бы заняться не маловажной задачей оптимизации работы с диском. Кеш у них тоже левой задней спроектирован :(
Но я им уже несколько раз писал о недостатках и по английски, и по русски, и не только я, полагаю…
Да и собственно, такими объемами SSD не убить за обозримый промежуток времени. Жало, конечно. Ведь это бессмысленные многократные перезаписывания из пустого в порожнее. Но это не те объемы, из-за которых стоит беспокоиться и пихать конфиги в рам-диск.
Тут бы разрабов FF куда-нибудь макнуть на пару минут, чтобы немного освежили мозги и поняли, что за 10 лет пора бы заняться не маловажной задачей оптимизации работы с диском. Кеш у них тоже левой задней спроектирован :(
Но я им уже несколько раз писал о недостатках и по английски, и по русски, и не только я, полагаю…
Сбрасывается в образ RAMDiskImage.img, а при включении информация из образа снова загружается в RAM-диск. Программа QSoft RAMDrive Enterprise.
А при неожиданном отключении питания, и если до этого система пол года не перегружалась а бесперебойник подвёл по причине сдохшего аккумулятора?
На домашнем компе у меня нет необходимости не перезагружаться полгода.
Помоему тут что-то не то… многие наоборот многое отдали бы за ОТСУТСТВИЕ необходимости перезагружаться. В современной системе так и есть, перезагрузка НЕОБХОДИМА только при установке некоторых системных драйверов…
НЛО прилетело и опубликовало эту надпись здесь
Гибернация это не перезагрузка и не считается за перезагрузку.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Виндовс резервирует ровно столько места на диске сколько доступно системе. По многим аппаратным причинам, операционной системе доступна не вся физическая память. Поэтому и выделяется памяти меньше.
На 32-х битной системе с 4Гб физической памяти может быть доступно лишь 2.75Гб из-за отражения адресных пространств устройств на адресное пространство памяти. Не думали тогда что памяти в настольных системах будет настолько много.
А зависит это от производителя материнской платы.
Вспомнил рекламу в журнале… крутейший сервер на 486-м процессоре и аж 256Мб оперативной памяти. Запредельные значения для простых смертных в то время…
На 32-х битной системе с 4Гб физической памяти может быть доступно лишь 2.75Гб из-за отражения адресных пространств устройств на адресное пространство памяти. Не думали тогда что памяти в настольных системах будет настолько много.
А зависит это от производителя материнской платы.
Вспомнил рекламу в журнале… крутейший сервер на 486-м процессоре и аж 256Мб оперативной памяти. Запредельные значения для простых смертных в то время…
НЛО прилетело и опубликовало эту надпись здесь
Гибернация даёт больше чем ускорение загрузки. Это ещё и восстановление состояния всех запущенных приложений, именно за это ценится этот режим.
Жаль, конечно, что при этом расходуется ценный ресурс SSD — удобство имеет свою цену. На стационарном такой проблемы нет — как правило SSD используется только для системного диска, а файл гибернации можно перенести на HDD(интересно, можно ли на отдельный скрытый раздел?).
Жаль, конечно, что при этом расходуется ценный ресурс SSD — удобство имеет свою цену. На стационарном такой проблемы нет — как правило SSD используется только для системного диска, а файл гибернации можно перенести на HDD(интересно, можно ли на отдельный скрытый раздел?).
Не могли бы рассказать, как вы перенесли файл гибернации на HDD?
НЛО прилетело и опубликовало эту надпись здесь
ОС не ломаются, а вот открытые файлы и проекты могут поломаться. особенно если база данных активно отрабатывает без коммитов…
Давно уже жду NVRAM гигабайтных размеров, вот где гибернация не нужна будет… никаких границ RAM/ROM/HDD — одно сплошное адресное пространство и под оперативную память и хранилище данных не требующее питания для хранения. Тогда систему можно останавливать хоть каждую секунду.
Давно уже жду NVRAM гигабайтных размеров, вот где гибернация не нужна будет… никаких границ RAM/ROM/HDD — одно сплошное адресное пространство и под оперативную память и хранилище данных не требующее питания для хранения. Тогда систему можно останавливать хоть каждую секунду.
Для Linux есть например profile-sync-daemon, который умеет синхронизировать кеш с постоянным хранилищем по таймауту (раз в час вроде), плюс делает это при штатном выключении комьютера. Так же он умеет работать через OverlayFS, что позволяет не хранить на RAM диске лишнего. Настройку, если интересно, я описывал тут.
Так вы не решили проблему. Подавляющая часть объема записи FF — это НЕ кеш
Сейчас у меня запись на SSD в сутки составляет 1-2 Гб против 15-25 раньше. Подкрепите, пожалуйста, фактами ваши слова про «подавляющую часть объема».
Ну статья о чем? О профиле, а не о кеше. ФФ спамит (ПЕРЕзаписывает по паре метров ежесекундно) гигабайты в ПРОФИЛЬ. Объем зависит от жирности сессии и активности серфинга. А чем можно КЕШ заспамить в объеме несколько десятков гиг за день — мне сложно представить.
В КЭШ тоже пишет дофига. А профиль все-таки не каждую секунду, в статье какая-то ерунда по этому поводу. Как и написано в той же статье (которая в этом плане сама себе противоречит) — по умолчанию данные сессии FF записывает раз в 15 секунд.
Последил за своим — так и есть, 1 раз в 15 секунд пишет файл recovery.js в профиль. У меня он размером 600 Кб сейчас (большая куча открытых вкладок + история недавно закрытых, по умолчанию 10 штук в нем же хранится). Вот эти 600 Кб раз в 15 сек он и пишет.
Ну и где-то 1 раз в минуту скидывает базу данных со всеми куками (у меня сейчас она где-то 1.5 Мб).
Больше почти ничего не пишет в профиль (иногда по 1-2 кб что-то обновляет без видимой периодичности) по собственной инициативе, только при активности пользователя типа добавления закладок или изменения настроек.
Т.е. при настройках по умолчанию в профиль создает поток порядка: 1.5*60+0.6*3600/15 = 234 Мб в час
или 5.5 Гб за 24ч если вообще круглосуточно не выключать.
При этом за сутки активного использования общий объем записи он у меня он генерирует от 15 до 30 Гб, т.е. в 3-6 раз больше.
И это в основном как раз кэш, который у меня тоже уже давно на RAM-диске по этой причине (хотя изначально по другой — до появления SSD это сильно ускоряло работу браузера по сравнению с кешем размещенным на HDD). Т.е. 20-30% профиль, и 70-80% кэш браузера.
Чем спамить в кэш? Любая работа с «тяжелыми» сайтами (которые сейчас вообще большей частью тяжелые — в интернете повальная болезнь сильного ожирения сайтов). Или банальный просмотр онлайн видео — все просматриваемое в этом случае прокачивается через кэш. Например сейчас открыл Ютуб, включил мониторинг, просмотрел всего один 1080p ролик длиной на 7 минут, выключил мониторинг, — на рам диск где лежит кеш почти 400 Мб было записано пока смотрел.
Что забавно — сам ролик если его скачать в виде файла всего 150 Мб занимает. Т.е. если бы я его скачал на диск и посмотрел обычным плеером, то это было бы 150 Мб записи. А просмотр через браузер веб плеером — почти 400 Мб записи.
Хотя пропорция конечно сильно индивидуальная будет — если например браузер сильно засран совсем невменяемым количеством открытых вкладок (некоторые их по несколько сотен штук накапливают) и старых кук, а вот сам пользователь не особо активно браузером пользуется (просто висит в фоне большую часть времени пока не понадобится), тогда основной объем будет давать профиль, а кэш только незначительную часть.
Последил за своим — так и есть, 1 раз в 15 секунд пишет файл recovery.js в профиль. У меня он размером 600 Кб сейчас (большая куча открытых вкладок + история недавно закрытых, по умолчанию 10 штук в нем же хранится). Вот эти 600 Кб раз в 15 сек он и пишет.
Ну и где-то 1 раз в минуту скидывает базу данных со всеми куками (у меня сейчас она где-то 1.5 Мб).
Больше почти ничего не пишет в профиль (иногда по 1-2 кб что-то обновляет без видимой периодичности) по собственной инициативе, только при активности пользователя типа добавления закладок или изменения настроек.
Т.е. при настройках по умолчанию в профиль создает поток порядка: 1.5*60+0.6*3600/15 = 234 Мб в час
или 5.5 Гб за 24ч если вообще круглосуточно не выключать.
При этом за сутки активного использования общий объем записи он у меня он генерирует от 15 до 30 Гб, т.е. в 3-6 раз больше.
И это в основном как раз кэш, который у меня тоже уже давно на RAM-диске по этой причине (хотя изначально по другой — до появления SSD это сильно ускоряло работу браузера по сравнению с кешем размещенным на HDD). Т.е. 20-30% профиль, и 70-80% кэш браузера.
Чем спамить в кэш? Любая работа с «тяжелыми» сайтами (которые сейчас вообще большей частью тяжелые — в интернете повальная болезнь сильного ожирения сайтов). Или банальный просмотр онлайн видео — все просматриваемое в этом случае прокачивается через кэш. Например сейчас открыл Ютуб, включил мониторинг, просмотрел всего один 1080p ролик длиной на 7 минут, выключил мониторинг, — на рам диск где лежит кеш почти 400 Мб было записано пока смотрел.
Что забавно — сам ролик если его скачать в виде файла всего 150 Мб занимает. Т.е. если бы я его скачал на диск и посмотрел обычным плеером, то это было бы 150 Мб записи. А просмотр через браузер веб плеером — почти 400 Мб записи.
Хотя пропорция конечно сильно индивидуальная будет — если например браузер сильно засран совсем невменяемым количеством открытых вкладок (некоторые их по несколько сотен штук накапливают) и старых кук, а вот сам пользователь не особо активно браузером пользуется (просто висит в фоне большую часть времени пока не понадобится), тогда основной объем будет давать профиль, а кэш только незначительную часть.
>> Т.е. 20-30% профиль, и 70-80% кэш браузера.
Если много смотреть ютуба, то вполне вероятен такой расклад. А вот во время чтения того же Гиктаймса понаблюдайте за ФФ с помощью Process Monitor (тоталы можно посмотреть в Tools \ File Summary \ By Folder). За 10-15 минут он может наперезаписывать в профиль объем сравнимый с часом-полтора простоя. В кэш же при этом мало чего ложится.
http://dl2.joxi.net/drive/2016/10/03/0001/4033/114625/25/e0d8565e3a.png
За почти полтора часа простоя в фоне с mail.ru в кэш записало около 12 мб и около 35-40 мб в профиль (забыл заскринить). Далее ~15 минут чтения статьи об алкоголе. Кэш — ~20-24 мб, профиль — 55 мб. Пришло письмо с твиттера о попытке входа. Поменял пароль, прошвырнулся по настройкам. Минут 10 прошло и внезапно кэш 25 мб, а профиль — 220 мб! Три вкладки всего. Ничего другого открыто не было.
— Пока вам это описывал и зашел на форум, глянул пару сообщений. Еще минут 10 прошло. Получите — распишитесь! Еще +80 в профиль и +3 в кэш! Меня пугает этот экспоненциальный рост. Может он не любит, когда его мониторят? ))
http://dl2.joxi.net/drive/2016/10/03/0001/4033/114625/25/82af5f2d61.png
Итого:
чуть меньше 1.5 часа — бездействие с mail.ru в фоне
чуть больше 0.5 часа — активное использование
4 посещенных ресурса
2-3 вкладки открыты одновременно
300 метров в профиль
Объемы записи неравномерные и непредсказуемые без более глубокого анализа.
Если у человека дофига вкладок открыто и на нескольких из них скрипты периодически что-то обновляют, то будет вам и запись гораздо чаще, чем раз в минуту и десятки гиг в профиль за день при слабо меняющемся кеше. А если ютуб смотреть, то наоборот.
===
Пока ждал разрешения это запостить. За пол часа ПРОСТОЯ с тремя вкладками докинуло еще 3 в кэш и 70 в профиль. Т.е. больше вкладок — больше записи даже в простое, даже если эти вкладки не обновляются автоматически. В общем, без понятия: это sqlite такой сам по себе или его так разработчики ФФ сконфигурили. Но с этим дано уже надо что-то сделать. Особенно учитывая тот факт, что sqlite пишет порциями по одному сектору. Т.е. мало того, что объемы записи зачастую выглядят неадекватно, так еще и производится все это с минимальной эффективностью.
http://dl2.joxi.net/drive/2016/10/03/0001/4033/114625/25/02cfdbbfff.png
Еще забыл понаблюдать динамику роста recovery.js.tmp. В этот раз он выбился в лидеры, хотя обычно лидирует sqlite.
http://dl2.joxi.net/drive/2016/10/03/0001/4033/114625/25/a38f29d9ae.png
Если много смотреть ютуба, то вполне вероятен такой расклад. А вот во время чтения того же Гиктаймса понаблюдайте за ФФ с помощью Process Monitor (тоталы можно посмотреть в Tools \ File Summary \ By Folder). За 10-15 минут он может наперезаписывать в профиль объем сравнимый с часом-полтора простоя. В кэш же при этом мало чего ложится.
http://dl2.joxi.net/drive/2016/10/03/0001/4033/114625/25/e0d8565e3a.png
За почти полтора часа простоя в фоне с mail.ru в кэш записало около 12 мб и около 35-40 мб в профиль (забыл заскринить). Далее ~15 минут чтения статьи об алкоголе. Кэш — ~20-24 мб, профиль — 55 мб. Пришло письмо с твиттера о попытке входа. Поменял пароль, прошвырнулся по настройкам. Минут 10 прошло и внезапно кэш 25 мб, а профиль — 220 мб! Три вкладки всего. Ничего другого открыто не было.
— Пока вам это описывал и зашел на форум, глянул пару сообщений. Еще минут 10 прошло. Получите — распишитесь! Еще +80 в профиль и +3 в кэш! Меня пугает этот экспоненциальный рост. Может он не любит, когда его мониторят? ))
http://dl2.joxi.net/drive/2016/10/03/0001/4033/114625/25/82af5f2d61.png
Итого:
чуть меньше 1.5 часа — бездействие с mail.ru в фоне
чуть больше 0.5 часа — активное использование
4 посещенных ресурса
2-3 вкладки открыты одновременно
300 метров в профиль
Объемы записи неравномерные и непредсказуемые без более глубокого анализа.
Если у человека дофига вкладок открыто и на нескольких из них скрипты периодически что-то обновляют, то будет вам и запись гораздо чаще, чем раз в минуту и десятки гиг в профиль за день при слабо меняющемся кеше. А если ютуб смотреть, то наоборот.
===
Пока ждал разрешения это запостить. За пол часа ПРОСТОЯ с тремя вкладками докинуло еще 3 в кэш и 70 в профиль. Т.е. больше вкладок — больше записи даже в простое, даже если эти вкладки не обновляются автоматически. В общем, без понятия: это sqlite такой сам по себе или его так разработчики ФФ сконфигурили. Но с этим дано уже надо что-то сделать. Особенно учитывая тот факт, что sqlite пишет порциями по одному сектору. Т.е. мало того, что объемы записи зачастую выглядят неадекватно, так еще и производится все это с минимальной эффективностью.
http://dl2.joxi.net/drive/2016/10/03/0001/4033/114625/25/02cfdbbfff.png
Еще забыл понаблюдать динамику роста recovery.js.tmp. В этот раз он выбился в лидеры, хотя обычно лидирует sqlite.
http://dl2.joxi.net/drive/2016/10/03/0001/4033/114625/25/a38f29d9ae.png
Ок, поставил мониторить когда начинал этот пост писать, посмотрим. Правда я не по процессу (firefox.exe) мониторинг включаю, а по пути на диске (профиля и кеша соотвественно) независимо от того какой процесс пишет. Потому как минимум еще плугин-конейнер туда ходит читать/писать и система (ОС) тоже — видимо когда браузер через Win-API какие-то вызовы делает. Т.е. процессом firefox.exe активность не ограничивается.
Так это не sqlite, это как раз влияние recovery.js.tmp и recovery.js сказывается — перезаписываются они всегда целиком, а объем прямо пропорционален количеству вкладок. При этом независимо от наличия активности на этих вкладках, даже не загруженные (у например выставлено в настройках, чтобы странички на вкладках загружались только при обращении к ним) объем увеличивают.
Поэтому что будет в лидерах (куки в базе sqlite или сессия в recovery.js) зависит от кол-ва вкладок и окон браузера и активности. Чем больше вкладок — тем больше recovery.js, чем больше активности — тем больше sqlite база с куками перетряхивается.
Т.е. больше вкладок — больше записи даже в простое, даже если эти вкладки не обновляются автоматически. В общем, без понятия: это sqlite такой сам по себе или его так разработчики ФФ сконфигурили. Но с этим дано уже надо что-то сделать. Особенно учитывая тот факт, что sqlite пишет порциями по одному сектору.
Так это не sqlite, это как раз влияние recovery.js.tmp и recovery.js сказывается — перезаписываются они всегда целиком, а объем прямо пропорционален количеству вкладок. При этом независимо от наличия активности на этих вкладках, даже не загруженные (у например выставлено в настройках, чтобы странички на вкладках загружались только при обращении к ним) объем увеличивают.
Поэтому что будет в лидерах (куки в базе sqlite или сессия в recovery.js) зависит от кол-ва вкладок и окон браузера и активности. Чем больше вкладок — тем больше recovery.js, чем больше активности — тем больше sqlite база с куками перетряхивается.
Пора снимать показания. 4 часа работы браузера и очень активного его использования почти без перерывов. Но потокового видео, браузерных игр или еще чего-то ресурсоемкого или сильно трафикогенерирующего вообще не запускал в эти 4 часа — только серфинг, но зато с большим кол-вом открытых вкладок (харбр/ГТ, поиск в гугле, почта через веб-интерфейс, интернет банки, пара новостных сайтови т.д.)
Настройки по умолчанию, вкладок — куча, куки не чистил.
В таком раскладе действительно профиль с большим отрывом уходит вперед — в этом замере в профиль почти в 8 раз больше оказалось записано в кэш. И как правильно в прошлом посте написал — при большой активности пользователя база с куками уходит в отрыв, тогда как при висении в фоне основной объем дает постоянное сохранение сессии (от кол-ва вкладок и окон).
Хотя одно время (поглядывал в процессе) в лидерах держался тот кого вообще тут не упоминали — банерорезка (AdblockPlus)! Я уж думал так, на 1м месте и останется, но потом почему-то куки резко вперед пошли, а ABP «всего лишь» 1 Гигабайтом записанных данных ограничился:
FireFox_kills_SSD
Впрочем в эти 4 часа мой средний дневной объем серфинга в сети перекрывают (специально по всем основным посещаемым сайтам побольше побегал, по открывал лишние странички которые не собирался читать), за исключением онлайн видео.
Профиль тут дал 5.5 Гб записи и 0.7 Гб записи в кэш, тогда как за сутки как уже писал 15-30 Гб записи у меня набирается и большая часть через кэш. Видимо остальное это действительно только за счет потоковых видео прокачиваемых (причем неэффективно) через кэш набирается и за счет этого выводящих кэш на 1е место по объему при моем режиме использования.
Настройки по умолчанию, вкладок — куча, куки не чистил.
В таком раскладе действительно профиль с большим отрывом уходит вперед — в этом замере в профиль почти в 8 раз больше оказалось записано в кэш. И как правильно в прошлом посте написал — при большой активности пользователя база с куками уходит в отрыв, тогда как при висении в фоне основной объем дает постоянное сохранение сессии (от кол-ва вкладок и окон).
Хотя одно время (поглядывал в процессе) в лидерах держался тот кого вообще тут не упоминали — банерорезка (AdblockPlus)! Я уж думал так, на 1м месте и останется, но потом почему-то куки резко вперед пошли, а ABP «всего лишь» 1 Гигабайтом записанных данных ограничился:
FireFox_kills_SSD
Впрочем в эти 4 часа мой средний дневной объем серфинга в сети перекрывают (специально по всем основным посещаемым сайтам побольше побегал, по открывал лишние странички которые не собирался читать), за исключением онлайн видео.
Профиль тут дал 5.5 Гб записи и 0.7 Гб записи в кэш, тогда как за сутки как уже писал 15-30 Гб записи у меня набирается и большая часть через кэш. Видимо остальное это действительно только за счет потоковых видео прокачиваемых (причем неэффективно) через кэш набирается и за счет этого выводящих кэш на 1е место по объему при моем режиме использования.
Какой прогой пользовались для создания RAM-диска?
Многие тесты показывают, что SSD умирают после записи 800 ТБ — 1 ПБ данных
Если я правильно посчитал, даже если записывать по 50 гб в день, диска хватит на 43 — 54 года
В чем проблема «ресурса диска» то?
Если я правильно посчитал, даже если записывать по 50 гб в день, диска хватит на 43 — 54 года
В чем проблема «ресурса диска» то?
НЛО прилетело и опубликовало эту надпись здесь
Проблема, как обычно, в маркетологах.
Идея тюнинга компьютера это огромный рынок, но свежака там относительно немного. Ну нельзя же в конце концов 20 лет продавать чистильщики реестра и ускорители браузера?
ССД с их ресурсом в этом смысле стал золотой коровой, которую доят буквально все кому не лень, начиная от производителей ссд (у которых появился дополнительный маркетинговый пункт вида «а вот наш ссд»), продолжая создателями программ для контроля ссд (ну как же, а вдруг ресурс кончится, а ты и не заметишь), включая улучшителей производительности и долговечности (как создателей программ так и создателей статей на эту тему) и разумеется не забывая про «компьютерных мастеров» (ой у вас ссд почти при смерти, давайте поменяю недорого).
В общем это классическая ситуация вида «не придумать в какую сферу войти — создай ее и пасись на ней».
При этом у здравомыслящей части аудитории нет стимула опровергать эти басни с той же мощностью, с которой их продвигают, хотя бы просто в меру отсутствия денежного стимула.
Так что смиритесь, это надолго:)
Идея тюнинга компьютера это огромный рынок, но свежака там относительно немного. Ну нельзя же в конце концов 20 лет продавать чистильщики реестра и ускорители браузера?
ССД с их ресурсом в этом смысле стал золотой коровой, которую доят буквально все кому не лень, начиная от производителей ссд (у которых появился дополнительный маркетинговый пункт вида «а вот наш ссд»), продолжая создателями программ для контроля ссд (ну как же, а вдруг ресурс кончится, а ты и не заметишь), включая улучшителей производительности и долговечности (как создателей программ так и создателей статей на эту тему) и разумеется не забывая про «компьютерных мастеров» (ой у вас ссд почти при смерти, давайте поменяю недорого).
В общем это классическая ситуация вида «не придумать в какую сферу войти — создай ее и пасись на ней».
При этом у здравомыслящей части аудитории нет стимула опровергать эти басни с той же мощностью, с которой их продвигают, хотя бы просто в меру отсутствия денежного стимула.
Так что смиритесь, это надолго:)
Согласен с вами. Вот живой пример(никаких оптимизаторов, файл подкачки на SSD, кеш браузера там же):
Рабочая машина
Сервер:
Домашний ПК:
Рабочая машина
Сервер:
Домашний ПК:
НЛО прилетело и опубликовало эту надпись здесь
Отличный поинт.
Ресурсов же много, давайте засрем всё. Гигабайты, гигагерцы, гигаджоули… кого вообще должно волновать, что будет через 50 лет?
Ресурсов же много, давайте засрем всё. Гигабайты, гигагерцы, гигаджоули… кого вообще должно волновать, что будет через 50 лет?
НЛО прилетело и опубликовало эту надпись здесь
Возьмите в расчет современные терминальные сервера, где можно разместить более 240 пользователей. Не редко такие сервера работают с СХД где установленны от 4 шт. SSD c
При этом гарантийный ресурс записи всего 20-100 ТБ, после чего идет обнуление гарантии.
А 800-1000, это
1. На дисках большого объема (и поэтому дорогих)
2. Удачных экземплярах.
3. Синтетических тестах.
4. Обычно новых (только из магазина) дисках — а флеш деградирует не только от перезаписей, но и от времени пока хранит заряд.
Первый мой SSD на 60 Гб вылетел за гарантийный ресурс записи меньше чем через 2 года, при том что гарантия на него по-идее 5 лет (была бы). Второй на 128 Гб пока еще не превысил ресурс, но к нему приближается и точно выйдет раньше, чем кончится календарный срок гарантии.
Это при том что например как раз FF у меня уже давно на рам-диск перенесен, что экономит порядка 10 ГБ/сутки.
А 800-1000, это
1. На дисках большого объема (и поэтому дорогих)
2. Удачных экземплярах.
3. Синтетических тестах.
4. Обычно новых (только из магазина) дисках — а флеш деградирует не только от перезаписей, но и от времени пока хранит заряд.
Первый мой SSD на 60 Гб вылетел за гарантийный ресурс записи меньше чем через 2 года, при том что гарантия на него по-идее 5 лет (была бы). Второй на 128 Гб пока еще не превысил ресурс, но к нему приближается и точно выйдет раньше, чем кончится календарный срок гарантии.
Это при том что например как раз FF у меня уже давно на рам-диск перенесен, что экономит порядка 10 ГБ/сутки.
НЛО прилетело и опубликовало эту надпись здесь
http://www.samsung.com/global/business/semiconductor/minisite/SSD/M2M/html/support/warranty.html
SAMSUNG warrants… for THE SHORTER OF: (I) THE LIMITED WARRANTY PERIOD,… OR (II) THE PERIOD ENDING ON THE DATE WHEN THE SSD HAS EXCEEDED ITS TBW (TOTAL BYTES WRITTEN) THRESHOLD
http://www.kingston.com/us/company/warranty#duration
Product Warranty Based On Five Years or SSD Life Remaining Value:… warranty for one of the following periods, whichever occurs first: (i) five years… or (ii) until the date when the usage of the drive as measured by Kingston’s implementation of the SMART attribute 231 “SSD Life Remaining” reaches a normalized value of one (1)
https://www.sandisk.com/about/legal/commercial-product-warranty-policy
The Warranty Period expires at the end of the earlier of (a) the stated time period ..or (b) the point at which Customer’s use of the Product exceeds the stated endurance limit,… S.M.A.R.T. attribute (E6h/230) “Media Wear Out Indicator”) reaches 100% ..or (ii) the Product’s total Terabytes Written (TBW) as identified in the table below or in the Specifications for the Product.
(в таблице есть и 40-20 ТБ для небольших SSD)
Ограниченная гарантия НЕ РАСПРОСТРАНЯЕТСЯ на:… любой Продукт, исчерпавший – согласно значению «1» SMART-атрибута (E9) «Индикатор износа носителя» – ресурс режима записи,
> Первый мой SSD на 60 Гб вылетел за гарантийный ресурс записи меньше чем через 2 года
Что было дальше? Встал в r/o или продолжал работать? Сколько отработал?
Что было дальше? Встал в r/o или продолжал работать? Сколько отработал?
Продолжил работать естественно. Это же именно гарантированный ресурс, т.е. он имеет юридически-экономическое значение, а не технологическое. В r/ o накопитель переходит при превышении полного (расчетного) ресурса или когда контроллер по внутренней диагностике видит что флешка уже совсем умирает (кол-во ошибок выше критического уровня, «запасные» блоки на подмену полностью изношенным заканчиваются).
А пересечение гарантийного ресурса означает только досрочное прекращение гарантийных обязательств производителя перед покупателем. Впрочем техническое значение он все же имеет — производитель-то его не от балды ставит, а на таком уровне до которого доживают практически 100% накопителей, а после которого вероятность выхода из строя начинает быстро расти. Ищут этот «перелом» на графике и около него и выставляют гарантийный ресурс, чтобы с одной стороны минимизировать расходы по гарантийной замене, а с другой не слишком клиентов ущемлять и не выделяться в худшую сторону по сравнению с конкрурентами.
Сейчас еще работает(через пару месяцев 3 года ему будет) — переставил его в машину, где особой нагрузки нет, так что еще какое-то время поживет. Скорость записи правда уже сильно упала — всего около 50 МБ/с пишет на случайных(не сжимаемых) данных. Т.е. в 2-3 раза медленнее даже обычных HDD, не говоря уже о новом SSD. Скорость чтения тоже снизилась, хотя и не так сильно.
Trim при этом работает, так что это не из-за «мусора».
А пересечение гарантийного ресурса означает только досрочное прекращение гарантийных обязательств производителя перед покупателем. Впрочем техническое значение он все же имеет — производитель-то его не от балды ставит, а на таком уровне до которого доживают практически 100% накопителей, а после которого вероятность выхода из строя начинает быстро расти. Ищут этот «перелом» на графике и около него и выставляют гарантийный ресурс, чтобы с одной стороны минимизировать расходы по гарантийной замене, а с другой не слишком клиентов ущемлять и не выделяться в худшую сторону по сравнению с конкрурентами.
Сейчас еще работает(через пару месяцев 3 года ему будет) — переставил его в машину, где особой нагрузки нет, так что еще какое-то время поживет. Скорость записи правда уже сильно упала — всего около 50 МБ/с пишет на случайных(не сжимаемых) данных. Т.е. в 2-3 раза медленнее даже обычных HDD, не говоря уже о новом SSD. Скорость чтения тоже снизилась, хотя и не так сильно.
Trim при этом работает, так что это не из-за «мусора».
А, забыл дописать. При этом по SMART (и разным «диагностическим» утилиткам, которые по сути просто из SMART это считывают) все еще показывается 85% ресурса, т.е. только 15% износа и оптимистичный прогноз жизни еще на 5-10 лет вперед :)
Гарантийный ресурс при этом уже закончился как уже писал и судя по поведению диска(кратному снижению скорости в частности) реальный запас живучести уже к концу тоже подходит.
Гарантийный ресурс при этом уже закончился как уже писал и судя по поведению диска(кратному снижению скорости в частности) реальный запас живучести уже к концу тоже подходит.
Существует ли похожая проблема в других браузерах?
Думаю ещё может помочь: browser.cache.disk.enable: false
Покажите мне пальцем хоть на одного пользователя, у которого износился в десктопе/ноутбуке SSD. В смысле износились ячейки, а не внезапно умер контроллер (как это обычно бывает).
Мой SSD в EeePC 900. Битых секторов пока нет, но скорость записи уже очень низкая. Доходит до 3 IOPS.
Full trim давно делали?
Там вообще нет поддержки Trim. Субъективно помогает забивание нулями вместо этого, но ненадолго.
Он наверное из тех самых-самых первых SSD. Им данная статья (тем более на такой машинке) тоже ничем не поможет.
Asus EeePC 900 пошли в серию в мае 2008 года. То есть модели на данный момент восемь с половиной лет. Там стояли самые ранние SSD.
Ну извините, 8 год не каждый HDD выдержит, а тут ещё и пионеры среди SSD моделей, тем более, явно не самые качественные (учитывая бюджетность аппарата в целом). Все эти трюки для современных SSD (возрастом год 5, не больше) при регулярном выполнении trim не нужны (постоянно включенный trim сильно просаживает производительность).
> EeePC 900
Там (в eeepc) это нормально. У меня были 701/901, скорость записи всегда была очень так себе.
Там (в eeepc) это нормально. У меня были 701/901, скорость записи всегда была очень так себе.
Одно дело когда так себе, другое — когда при отправке сообщения в jabber вся система подвисает на пару секунд.
В 901 с чем-то подобным сталкивался периодически, почти с самого начала эксплуатации (например, копируешь пару-тройку метров на диск, и в этот момент система замирает на пару секунд). Есть подозрения, что это таки связано с дешевым и не очень качественным SSD (который, к тому же, фактически по USB был подключен внутри, хоть и висел на mini pci-e, насколько помню). Возможно, что таки да, потихоньку отмирать он начал уже тогда.
Ооо, им ещё кто-то пользуется :) У самого EeePC 900 с SSD на 12 гб, 4 гб из которых — быстрые (правда, эму это не помогает), и 8 гб — медленные (скорее всего — на уровне флешки, которая мегабайт 5-6 в секунду пишет). Стоит XP и любое включение Wi-FI на нем — это что-то жуткое, нетбук зависает минут на 5 и дальше еле-еле ворочается после отвисания, что пользоваться им становится невозможно. В итоге — я его запускаю в последнее время раза 2-3 в год, когда хочу посмотреть фильм на ночь, а планшет уже сел :\
Какая ОС у вас установлена? Возможно у вас проблемы с так называемым partition alignment, попробуйте проверить утилитами (легко гуглятся), если у вас Windows XP например — она не умеет корректно выравнивать данные для твердотельных накопителей в итоге сильное проседание производительности.
Контроллер иногда умирает как раз от износа.
Kingston SSDNow V100, 128Гб [SV100S2/128G], JMicron 616 — 128 гигов флеша БЕЗ какого-либо кеша, смарт достаточно приличный, но чипы в капусту и сам накопитель в read-only.
У меня есть Verxex2 на 40 гигабайт. Линейная скорость чтения-записи стала буквально 20 мегабайт/сек. Случайный доступ всё ещё в десятки раз быстрее, чем на HDD, поэтому стоит этот SSD на одном из компов.
Суммарно у меня и знакомых четыре недорогих кингстона 2013-2014, чтение/запись где ниже сотни, где 100-150. Спец. очистки не делали, кроме полного форматирования, нужно попробовать…
У меня раз в неделю (иногда реже) full trim под Linux запускается по расписанию. Был SiliconPower Velox V20 с осени 2011 до начала 2015 проработал без заметной просадки скорости, а однажды просто не вышел из спящего режима и перестал определяться системой. Диск SATA2, ещё и с проблемным (судя по отзывам) поколением контроллера.
Так что запустите full trim (должна быть фирменная утилита под Windows) и скорость должна по большей части вернуться.
У нас сотни три компов с SSD, так вот из них 3 компа были с SSD ADATA… Примерно через год эксплуатации на них стали блоки выпадать. При этом диск нормально форматируется, тестируется, но комп работать с ним полноценно не может- при перезагрузке компа некоторые файлы повреждаются или вовсе пропадают
Как оказалось, даже когда компьютер не работал (но не был выключен)
Вот эту фразу не распарсил.
Если компьютер был включён, но ни одной программы запущено не было, как Firefox мог что-то писать?
Если же Firefox был запущен, то как можно говорить, что «компьютер не работал»? Там в фоновом режиме браузер может своими делами заниматься, это же не секрет. Например, в моменты простоя самое время скачать обновление антифишинговых и антималварных баз. А их приходится как раз сначала локально загружать, а потом уже при сёрфинге сопоставлять посещаемые пользователем сайты с фишинговой базой, чтобы не «сливать» в Сеть информацию о посещённых пользователем сайтах.
И про 600 мегабайт кук я сильно сомневаюсь. Размер файла с куками на прилично так поюзанном браузере (где сотни кук с разных сайтов сохранено) обычно в районе пары мегабайт. Что туда нужно писать объёмом 600 мегабайт? Перезаписывать эти куки по многу раз в секунду? Стояли ли при этом какие-то дополнения?
Это не размер файла разумеется, а объем записи за период (в примере за 45 минут).
Сейчас запустил мониторинг на последнем FF (49й). Всего за 400 секунд пока работал мониторинг было записано
cookies.sqlite-wal — 4.8 Мб, при размере файла 0.8 Мб
cookies.sqlite — 3.9 Мб при размере файла 1.5 Мб
Т.е. примерно 1 раз в минуту 1й перезаписывается и 1 раз в 2 минуты 2й.
С его более 600 Мб похоже он файл кук отрастил где-то до 12-14 Мб. Ну а FF его каждую минуту радостно перезаписывает полностью вместо того чтобы дописывать только изменения.
Так же как файл сессии — каждые 15 секунд.
И это далеко не предел — вон по ссылке сами разработчики FF признаются, что на давно не чищенном браузере эти файлы и больше 100 Мб могут быть. И точно так же будут перезаписываться каждые 15-60 секунд при настройках по умолчанию.
Сейчас запустил мониторинг на последнем FF (49й). Всего за 400 секунд пока работал мониторинг было записано
cookies.sqlite-wal — 4.8 Мб, при размере файла 0.8 Мб
cookies.sqlite — 3.9 Мб при размере файла 1.5 Мб
Т.е. примерно 1 раз в минуту 1й перезаписывается и 1 раз в 2 минуты 2й.
С его более 600 Мб похоже он файл кук отрастил где-то до 12-14 Мб. Ну а FF его каждую минуту радостно перезаписывает полностью вместо того чтобы дописывать только изменения.
Так же как файл сессии — каждые 15 секунд.
И это далеко не предел — вон по ссылке сами разработчики FF признаются, что на давно не чищенном браузере эти файлы и больше 100 Мб могут быть. И точно так же будут перезаписываться каждые 15-60 секунд при настройках по умолчанию.
Вот как. Сначала покупают модное железо, которое по уверениям маркетологов, всем лучше устаревших жёстких дисков, а потом оказывается, что надо каждое используемое приложение тонко настраивать, чтобы жить с этими клёвыми твердотельными накопителями. Нет, конечно, SSD — отличные устройства, у них есть своя ниша применения, но не надо их позиционировать как замену HDD. С этой ролью во всём объёме они пока не справляются. Как мобильный интернет, какой бы он быстрый не был, не способен заменить стационарный.
Способен. Заменяет. Перестаньте пожалуйста повторять набившие оскомину байки. Со скоростью износа, указанной автором,
>диска хватит на 43 — 54 года
Уже было достаточное количество показательных экспериментов, когда диски затирали «до дыр» — они способны работать месяцами в совершенно нештатном режиме непрерывной записи, превышая гарантийный объем записанных данных в десятки раз. В частности, эксперимент с бюджетными дисками OCZ Arc.
Тут на самом деле просто психологический момент — что какая-то программа без особых на то причин потребляет дисковый ресурс, пускай он и огромен.
>диска хватит на 43 — 54 года
Уже было достаточное количество показательных экспериментов, когда диски затирали «до дыр» — они способны работать месяцами в совершенно нештатном режиме непрерывной записи, превышая гарантийный объем записанных данных в десятки раз. В частности, эксперимент с бюджетными дисками OCZ Arc.
Тут на самом деле просто психологический момент — что какая-то программа без особых на то причин потребляет дисковый ресурс, пускай он и огромен.
"… Способен. Заменяет. ..."
Нет, не способен! За цену стоимости оборудования и монтажа, аналогичную кабельной сети — безусловно не способен.
Нет, не способен! За цену стоимости оборудования и монтажа, аналогичную кабельной сети — безусловно не способен.
НЛО прилетело и опубликовало эту надпись здесь
Я приведу аналогию.
Представьте себе, что обычный HDD — это автомобиль. Он может ехать на ручнике, но очень плохо и самое главное — если он на ручнике, это заметно. Поэтому ни один пользователь в здравом уме не будет ехать на ручнике.
По сравнению с ним, SSD это тоже автомобиль, но с гораздо более мощным движком. Таким мощным, что ему пофиг, затянут ручник или нет — водитель даже не заметит.
Тут правильная аналогия кончается)) Потому что по каким-то волшебным причинам ресурс ручника на HDD-автомобиле у нас миллиард километров (ну, если затянуть и ехать), а вот на SSD «всего» миллион.
Ну так вот))
1. По возможности не надо ездить на ручнике, даже если машина позволяет
2. Не надо говорить, что современные технологии говно, только по той причине что приходится следить за ресурсом тормозных колодок на машине, которая настолько мощная, что «не замечает» затянутый ручник
3. Говоря об относительном ресурсе тормозных колодок (у SSD — в 10 раз хуже), желательно всё-таки подумать об абсолютных цифрах. Миллион км на ручнике это в 10 раз меньше чем миллиард, но всё равно больше, чем ресурс автомобиля в целом. Говоря простым языком, просто «чуть более чем достаточно».
Представьте себе, что обычный HDD — это автомобиль. Он может ехать на ручнике, но очень плохо и самое главное — если он на ручнике, это заметно. Поэтому ни один пользователь в здравом уме не будет ехать на ручнике.
По сравнению с ним, SSD это тоже автомобиль, но с гораздо более мощным движком. Таким мощным, что ему пофиг, затянут ручник или нет — водитель даже не заметит.
Тут правильная аналогия кончается)) Потому что по каким-то волшебным причинам ресурс ручника на HDD-автомобиле у нас миллиард километров (ну, если затянуть и ехать), а вот на SSD «всего» миллион.
Ну так вот))
1. По возможности не надо ездить на ручнике, даже если машина позволяет
2. Не надо говорить, что современные технологии говно, только по той причине что приходится следить за ресурсом тормозных колодок на машине, которая настолько мощная, что «не замечает» затянутый ручник
3. Говоря об относительном ресурсе тормозных колодок (у SSD — в 10 раз хуже), желательно всё-таки подумать об абсолютных цифрах. Миллион км на ручнике это в 10 раз меньше чем миллиард, но всё равно больше, чем ресурс автомобиля в целом. Говоря простым языком, просто «чуть более чем достаточно».
SSD не добавляет никакой возможности ездить на ручнике. Просто обычный винт имеет «повремённую» оплату, ему всё равно сколько дурной работы делать — он с ней справляется одинаково, пока хватает пропускной способности. А SSD платит за каждый мегабайт. Зато быстрее. В интернете тоже так было — медленный повремённый (или с абонентской платой) и быстрый, зато платишь за каждый мегабайт.
Опять же ваше сравнение с автомобилем и колодками не корректно. Внутри компьютера может исполняться не одна программа, а десяток, сотня, и тогда износ ресурса станет заметен.
Опять же ваше сравнение с автомобилем и колодками не корректно. Внутри компьютера может исполняться не одна программа, а десяток, сотня, и тогда износ ресурса станет заметен.
Аналогии на то и аналогии, у них задача не 100% корректными быть, а мысль донести.
«Не одна программа» в моей аналогии это десяток-сотня ручников, которые даже мощный движок не вытянет. Вы не станете запускать «десяток, сотня» программ на HDD (имеется в виду таких, что каждая даёт нагрузку в несколько Мб/с) — один ФФ с его 2 Мб/с уже систему с обычным HDD замедляет до неприятного состояния.
То, что SSD с его 150.000 IOPS (против 100 у 7.200 RPM HDD) способен на такие подвиги, не означает что так надо с ним поступать. Или поступайте, но тогда не надо жаловаться на расход ресурса, которого тогда хватит на «жалких» пару лет.
«Не одна программа» в моей аналогии это десяток-сотня ручников, которые даже мощный движок не вытянет. Вы не станете запускать «десяток, сотня» программ на HDD (имеется в виду таких, что каждая даёт нагрузку в несколько Мб/с) — один ФФ с его 2 Мб/с уже систему с обычным HDD замедляет до неприятного состояния.
То, что SSD с его 150.000 IOPS (против 100 у 7.200 RPM HDD) способен на такие подвиги, не означает что так надо с ним поступать. Или поступайте, но тогда не надо жаловаться на расход ресурса, которого тогда хватит на «жалких» пару лет.
НЛО прилетело и опубликовало эту надпись здесь
А программисты не должны оптимизироваться под железо. У них есть абстракция, и они с ней работают. Например, файл. А где этот файл лежит — на ssd, на hdd или вообще на nfs заботить должно только операционную систему. А то будет как с хромиумом, который для работы требует низкоуровневый udev. А что делать тем, кто использует для инициализации устройств другую программу? Правильно, сносить хромиум.
НЛО прилетело и опубликовало эту надпись здесь
Они и не задумываются. Это не их работа определять на какой платформе и через какой интерфейс работать.
Меня дико бесит когда я не могу файлы использовать с сетевого диска — программа их тупо игнорирует!
Нет, этим должны заниматься не программисты а их менеджеры, которые планируют и ставят им задачи.
Меня дико бесит когда я не могу файлы использовать с сетевого диска — программа их тупо игнорирует!
Нет, этим должны заниматься не программисты а их менеджеры, которые планируют и ставят им задачи.
Поведение, описанное в статье, нормальным не назовешь.
Поток данных в 2 Мб/с ради того, чтобы «восстановить сессию» критики не выдерживает — если сайт загружен, то что ещё там качать? Решил проверить сам, поскольку пользуюсь в основном FF, а SSD у меня «не из новых» — сменивший несколько ноутбуков, прошедший огонь и воду OCZ Vertex 4 возрастом около 5 лет. Доверяй, но проверяй — вы можете повторить это сами на своем компе.
ОС — Archlinux x64, свежий ФФ из stable-ветки (прямо сейчас качается свежайшее обновление, даже ещё на Яндекс-зеркале не появилось)
Запускаю от рута iotop, консоль не левую половину экрана, ФФ на правую, поехали.
Открываю-закрываю сайты, сворачиваю ФФ, слежу. Открытие сайта вызывает конечно запись на диск, объем записанных данных составляет к примеру 3 Мб для хабра. Свернутый ФФ тоже пишет, но гораздо меньше — каждые несколько секунд под 100 Кб. После замера получил цифру 1,8 Мб в минуту, что равнозначно 1,8 Гб в сутки, т.е. если комп будет стоять включенным 24 часа.
Есть подозрение, что у автора статьи открыто большое количество вкладок с какими-то специфичными сайтами. У меня во время эксперимента было открыто и полностью прогружено 11 вкладок, включая тяжеловесную с видеороликами.
Поток данных в 2 Мб/с ради того, чтобы «восстановить сессию» критики не выдерживает — если сайт загружен, то что ещё там качать? Решил проверить сам, поскольку пользуюсь в основном FF, а SSD у меня «не из новых» — сменивший несколько ноутбуков, прошедший огонь и воду OCZ Vertex 4 возрастом около 5 лет. Доверяй, но проверяй — вы можете повторить это сами на своем компе.
ОС — Archlinux x64, свежий ФФ из stable-ветки (прямо сейчас качается свежайшее обновление, даже ещё на Яндекс-зеркале не появилось)
Запускаю от рута iotop, консоль не левую половину экрана, ФФ на правую, поехали.
Открываю-закрываю сайты, сворачиваю ФФ, слежу. Открытие сайта вызывает конечно запись на диск, объем записанных данных составляет к примеру 3 Мб для хабра. Свернутый ФФ тоже пишет, но гораздо меньше — каждые несколько секунд под 100 Кб. После замера получил цифру 1,8 Мб в минуту, что равнозначно 1,8 Гб в сутки, т.е. если комп будет стоять включенным 24 часа.
Есть подозрение, что у автора статьи открыто большое количество вкладок с какими-то специфичными сайтами. У меня во время эксперимента было открыто и полностью прогружено 11 вкладок, включая тяжеловесную с видеороликами.
Там много чего сохраняется, в т.ч. то что меняется уже после загрузки сайта:
Ну и да, объем файла прямо пропорционален количеству вкладок (не обязательно прогруженных — висящие в фоне и не загруженные в этом плане занимают столько же сколько и активные, и не обязательно тяжелых сайтов — от любых примерно одинаково). А интенсивность записи это объем файла х частоту перезаписи (по умолчанию стоит на 1 раз в 15 секунд).
Про 2 Мб/с автор глупость ляпнул — это ему мониторинг пиковую скорость непосредственно в момент записи показывает, а не среднюю. При такой средней ему браузер бы по 170 ГБ в сутки писал даже если им вообще не пользоваться, а только в фоне держать.
А так у него файл сессии судя по всему как раз около 2 Мб был. И перезаписывался 1 раз в 15 секунд, давая пиковую скорость чуть больше 2 МБ/с и среднюю около 0,14 МБ/с (500 МБ в час).
Ну и еще куки не мало объема давали (полная перезапись 1 раз в минуту). И еще по мелочи.
Session store contains open tabs, windows, history for each tab, form fields, referrers (so we can re-request the page correctly), titles (so we can restore tabs without re-fetching every page), favicons, charsets, some timestamps, extension data, some kinds of site storage, scroll positions, and a few other things.
The goal of session restore is to restore your session — your open tabs should come back, the same pages should load, scrolled to the same place, and with the right content.
Ну и да, объем файла прямо пропорционален количеству вкладок (не обязательно прогруженных — висящие в фоне и не загруженные в этом плане занимают столько же сколько и активные, и не обязательно тяжелых сайтов — от любых примерно одинаково). А интенсивность записи это объем файла х частоту перезаписи (по умолчанию стоит на 1 раз в 15 секунд).
Про 2 Мб/с автор глупость ляпнул — это ему мониторинг пиковую скорость непосредственно в момент записи показывает, а не среднюю. При такой средней ему браузер бы по 170 ГБ в сутки писал даже если им вообще не пользоваться, а только в фоне держать.
А так у него файл сессии судя по всему как раз около 2 Мб был. И перезаписывался 1 раз в 15 секунд, давая пиковую скорость чуть больше 2 МБ/с и среднюю около 0,14 МБ/с (500 МБ в час).
Ну и еще куки не мало объема давали (полная перезапись 1 раз в минуту). И еще по мелочи.
Автор пишет что SSD ставят как системный диск, почему-то он не предложил переместить программу на второй физический диск.
Проблема в том, что recovery.js состоит на 99% из совершенно ненужного дерьма. Хотя по хорошему было бы достаточно списка (структуры) табов + соответствующие url.
а что в этом пресловутом файле содержится? для чего нужны такие колоссальные объёмы данных, да ещё и постоянно обновляемые?
что за невероятные данные нужны для восстановления сессии? URL? кэши современные браузеры уже не держат и всё равно перезагружают вкладку при её открытии или возврате назад.
что за невероятные данные нужны для восстановления сессии? URL? кэши современные браузеры уже не держат и всё равно перезагружают вкладку при её открытии или возврате назад.
Фиг знает, я не эксперт. Но если просто заглянуть вовнутрь, то там проглядывают даже жипеги закодированные в base64.
Дело не в объеме полезных данных, а в частоте их перезаписи
И справедливости ради, сейчас он не так часто спамит, как год назад, когда я анализировал эту проблему.
Да и лично я не люблю ворочать десятками открытых вкладок, так что и год назад у меня было порядка 5 гиг за день от FF, а не 25+.
И справедливости ради, сейчас он не так часто спамит, как год назад, когда я анализировал эту проблему.
Да и лично я не люблю ворочать десятками открытых вкладок, так что и год назад у меня было порядка 5 гиг за день от FF, а не 25+.
Но всё равно. Зачем хранить что-то окромя URL? ну даже положение на странице и ещё какая-то служебная информация это не так много. и зачем это всё перезаписывать по 2 МБ/с?
В recovery.js и так хранится массив служебных данных. Но там не только сама вкладка, а вся цепочка переходов. Чтобы после восстановления вы могли пользоваться функцией «Назад/Вперед». Т.е. одна вкладка — это может быть и 1 порция данных, и 100 порций данных.
Но текст статьи еще и в заблуждение вводит. Факт лишь в том, что ФФ активно перезаписывает файлы в профиле, генерируя внушительный трафик за день. ФайлЫ, а не только один обсуждаемый recovery.js. На скринах всего-лишь банальный монитор ресурсов, который показывает мгновенную скорость. 2 мб/с ничего не означают особо. И если, как у меня сейчас, 2-4 вкладки висят, то и файлик этот весит 30 кб. А тем не менее гигабайты записи ФФ сгенерит в профиль.
Человек толком не мониторил и не анализировал куда именно его 30 гиг разошлись. Может и в жирный recovery.js (например, если впихнуть в title странички целый рассказ, то он в recovery тоже попадет и, возможно, в 100 экземплярах!), а может в множество других файлов.
Ну а зачем часто сбрасывать на диск? Наверное, в прошлом в гонке за первенство по стабильности и надежности работы браузеров, это казалось верным решением.
Но текст статьи еще и в заблуждение вводит. Факт лишь в том, что ФФ активно перезаписывает файлы в профиле, генерируя внушительный трафик за день. ФайлЫ, а не только один обсуждаемый recovery.js. На скринах всего-лишь банальный монитор ресурсов, который показывает мгновенную скорость. 2 мб/с ничего не означают особо. И если, как у меня сейчас, 2-4 вкладки висят, то и файлик этот весит 30 кб. А тем не менее гигабайты записи ФФ сгенерит в профиль.
Человек толком не мониторил и не анализировал куда именно его 30 гиг разошлись. Может и в жирный recovery.js (например, если впихнуть в title странички целый рассказ, то он в recovery тоже попадет и, возможно, в 100 экземплярах!), а может в множество других файлов.
Ну а зачем часто сбрасывать на диск? Наверное, в прошлом в гонке за первенство по стабильности и надежности работы браузеров, это казалось верным решением.
Не досмотрел. Есть же скриншот в статье с объемами по файлам:
https://habrastorage.org/getpro/geektimes/post_images/084/4e1/eba/0844e1ebacde3ed0faddc49f8fcb2b19.jpg
Именно в sqlite основной объем и падает. В recovery.js понты данных упало.
Т.е. часто перезаписываются именно файлы БД. И по всей видимости, не чем-то новым, а одно и то же, смещенное после добавлений/удалений.
https://habrastorage.org/getpro/geektimes/post_images/084/4e1/eba/0844e1ebacde3ed0faddc49f8fcb2b19.jpg
Именно в sqlite основной объем и падает. В recovery.js понты данных упало.
Т.е. часто перезаписываются именно файлы БД. И по всей видимости, не чем-то новым, а одно и то же, смещенное после добавлений/удалений.
на этом скриншоте совсем мало, потому что он был сделан уже после того как автор позакрывал все свои вкладки. А вот куки не удалял, поэтому остались в основном одни куки как генераторы записи.
А так у него изначально (и у меня например сейчас тоже) больше записи дает именно сессия, а куки идут на 2м месте.
Ну это при фоновой работе — без активности пользователя. А при активности пользователя на 1м месте кэш с большим отрывом, на 2м сессия, на 3м куки.
А так у него изначально (и у меня например сейчас тоже) больше записи дает именно сессия, а куки идут на 2м месте.
Ну это при фоновой работе — без активности пользователя. А при активности пользователя на 1м месте кэш с большим отрывом, на 2м сессия, на 3м куки.
Кэш с большим отрывом может быть только в случае просмотра кино на ютубе. Да и то, учитывая битрейты ютуба — это получится около 600 мб кусков видеопотока в час. Какой же тут большой отрыв? В профиль может упасть не меньше в зависимости от того, что еще открыто.
Если весь час не провести в ютубе, то чего такого должно сотнями метров ежечасно писаться в кэш? В начале работы, если кэшируемый контент множества сходу открытых вкладок нужно обновить, то может и нападать. А дальше — увы, туда такими объемами класть нечего, кроме видео.
Если весь час не провести в ютубе, то чего такого должно сотнями метров ежечасно писаться в кэш? В начале работы, если кэшируемый контент множества сходу открытых вкладок нужно обновить, то может и нападать. А дальше — увы, туда такими объемами класть нечего, кроме видео.
Ну да, ютуб (хотя не конретно ютуб, вообще потоковое видео) я частенько смотрю. Оно у меня вместо телевизора давно. Качаю (с торрентов или еще где-нибудь) перед просмотром редко, чаще всего прямо в браузере и смотрится кроме особых случаев.
Поток у ютуба в HD нормальный — вон в соседнем сообщении писал, 7 минут стандартного FullHD дают 150 Мб файл(если через плагин выкачать оригинал), при этом в кеш браузер успел за время просмотра 400 Мб назаписывать.
С таким потоком если бы я не короткий ролик, а целый фильм или пару передач посмотрел (часа 1.5) это 12-13 Гб записи в кеш с одной только этой ютубовской вкладки.
Не знаю из-за чего у него там такая (более чем 2х кратная) избыточность записи получается, но у них программеры любят с расходом ресурсов не считаться, так что не особо удивился результатам измерений.
Поток у ютуба в HD нормальный — вон в соседнем сообщении писал, 7 минут стандартного FullHD дают 150 Мб файл(если через плагин выкачать оригинал), при этом в кеш браузер успел за время просмотра 400 Мб назаписывать.
С таким потоком если бы я не короткий ролик, а целый фильм или пару передач посмотрел (часа 1.5) это 12-13 Гб записи в кеш с одной только этой ютубовской вкладки.
Не знаю из-за чего у него там такая (более чем 2х кратная) избыточность записи получается, но у них программеры любят с расходом ресурсов не считаться, так что не особо удивился результатам измерений.
А вы посмотрите… файл текстовый, XML-формат…
Всё очень просто и незатейливо — похоже вкладка как объект просто сериализуется и выгружается в файл. Затраты на программирование минимальны, гарантия что вкладка восстановится такой как была — вместе с историей переходов, позицией просмотра на странице, иконку сайта и т.д. Завтра в сериализацию включат полный битмап загруженного сайта и он попадёт в этот файл… автоматически.
Всё очень просто и незатейливо — похоже вкладка как объект просто сериализуется и выгружается в файл. Затраты на программирование минимальны, гарантия что вкладка восстановится такой как была — вместе с историей переходов, позицией просмотра на странице, иконку сайта и т.д. Завтра в сериализацию включат полный битмап загруженного сайта и он попадёт в этот файл… автоматически.
Session store contains open tabs, windows, history for each tab, form fields, referrers (so we can re-request the page correctly), titles (so we can restore tabs without re-fetching every page), favicons, charsets, some timestamps, extension data, some kinds of site storage, scroll positions, and a few other things.
The goal of session restore is to restore your session — your open tabs should come back, the same pages should load, scrolled to the same place, and with the right content.
А мне нравится, когда текст, набранный в формы, восстанавливается после внезапного перезапуска браузера.
Мне бы тоже нравилось, но почему-то ни разу не помню, чтобы после краха формы восстанавливались…
Формы восстанавливаются. И как вам написал человек выше, это очень здорово. А ресурс… зато именно эти мелочи улучшают жизнь.
У меня на FF всегда восстанавливается. Правда часто на динамических сайтах бывает совсем в другой форме оказывается. Например тут на хабре если скажем писал текст комментария к другому коментарию (т.е. не 1го уровня, а вложенные), форма ответа которого открывается динамически по нажатию кнопки «ответить», то если грохнуть браузер в этот момент, то после восстановлении сессии недописанный комментарий окажется в самом низу страницы — в формочке добавления комментария 1го уровня, а не там где он изначально писался.
Такое же и на других сайтах случается, где формы скриптами набиты.
Такое же и на других сайтах случается, где формы скриптами набиты.
О каком «дерьме» идёт речь? Всё что я там увидел это список табов, история переходов(для кнопок назад/вперёд) и некоторая информация о состоянии этих табов.
НЛО прилетело и опубликовало эту надпись здесь
Если у вас обычный жесткий диск, то можно особо не переживать.
Неправда. Ещё несколько лет назад я заметил что файрфокс просто тупо фризится. На обычном жёстком диске. Потому что постоянно что-то туда пишет и читает по мелочи и весь UI блокируется. Диск кстати был и WD Blue и WD RE 4. Так что написал скрипт по хранению профиля в RAM и синхронизации на винт. В принципе уже установил SSD и хотел сдвинуть туда папку с профилями, чтобы избавится от этого костыля, но видимо не судьба…
Всего навсего изменить функцию хранения этого файла с plain text формата на любую базу данных, пусть ту же sqlite, благо эта база уже используется в профиле. Нефиг перезаписывать весь файл при любом изменении.
Статья не совсем полно описывает схему работы ФФ с диском. Файл recovery.js отнюдь не единственный виновник торжества. Помимо него обновляются и sqlite файлы. Например, places.sqlite. А автор «исследования», по сути, не настраивал толком мониторинг, чтобы выяснить, в какие именно файлы сколько именно из его 25 гиг попало. Он просто вооружился суммой за день и визуальным определением первого попавшегося часто обновляемого файла.
Именно в его сценарии js, скорее всего, основную массу делает. Но помог бы тут перенос в БД? Не думаю. Задача у них была именно частое сбрасывание на диск.
Именно в его сценарии js, скорее всего, основную массу делает. Но помог бы тут перенос в БД? Не думаю. Задача у них была именно частое сбрасывание на диск.
P.S.: Именно sqlite трафик и создает, а вовсе не recovery.js:
https://habrastorage.org/getpro/geektimes/post_images/084/4e1/eba/0844e1ebacde3ed0faddc49f8fcb2b19.jpg
Очень крупные скриншоты…
https://habrastorage.org/getpro/geektimes/post_images/084/4e1/eba/0844e1ebacde3ed0faddc49f8fcb2b19.jpg
Очень крупные скриншоты…
НЛО прилетело и опубликовало эту надпись здесь
SSD нужен для ускорения работы, так пускай он ускоряет и работает по максимому. Я наоборот на SSD файлы подкачки перенёс и ReadyBoost на него настроил. Испортится, выкину и куплю новый.
А вот у меня вопрос, в том же ProcessXP у меня всю жисть отображался столбец Disk Write, а у парня на фотке I/O Disk Write. Скажите, кто знает, а в чём разница?
Там есть нужные колонки:
«View»-«Select Columns»-«Process I/O»
«View»-«Select Columns»-«Process I/O»
Да ладно? А то я не знал… :(
вопрос же:
> в чём разница?
вопрос же:
> в чём разница?
У него не I/O Disk Write выведено, а просто I/O Write Bytes
А разница в том, что 2е это счетчик на все операции ввода-вывода(Input/Output), а не только на локальные диски. Например запись/чтение файла по сети увеличивает I/O Write/Read, но не увеличивает Disk Write/Read (если конечно загружаемый по сети файл одновременно на диск не записывается).
А разница в том, что 2е это счетчик на все операции ввода-вывода(Input/Output), а не только на локальные диски. Например запись/чтение файла по сети увеличивает I/O Write/Read, но не увеличивает Disk Write/Read (если конечно загружаемый по сети файл одновременно на диск не записывается).
*тьфу блин, если что, прочитал-то я на скриншоте правильно, а вот написал в комменте — нет :D
Вооот! Значит я правильно думал, что он какую-то погоду на марсе смотрит.
Спасибо!
Вооот! Значит я правильно думал, что он какую-то погоду на марсе смотрит.
Спасибо!
Ну не совсем погоду на марсе. В плане объема записи показания этого счетчика почти в точности с показаниями Disk Write совпадает, если с сетевыми дисками не работать.
Я сравнил эти ежи самые показания у себя. По сравнению с моими — у него однозначно погода где-то там!
Это же не от способа замера зависит, а от самого браузера, его настроек и активности его использования.
Вот мы выше вдвоем независимо замеряли и можем подтвердить — у нас FF тоже пишет в свинских объемах:
https://geektimes.ru/post/280792/#comment_9593674
У меня за 4 часа использования браузера пока работал мониторинг больше 6 Гб данных на диск записал. И это я еще онлайн видео не смотрел пока мониторинг был включен — там активность записи увеличивается во много раз.
Вот мы выше вдвоем независимо замеряли и можем подтвердить — у нас FF тоже пишет в свинских объемах:
https://geektimes.ru/post/280792/#comment_9593674
У меня за 4 часа использования браузера пока работал мониторинг больше 6 Гб данных на диск записал. И это я еще онлайн видео не смотрел пока мониторинг был включен — там активность записи увеличивается во много раз.
Сутки (хотя ночь можно не считать, компьютер в стазисе был), 19 вкладок в одном окне, плюс примерно раз 8, запускалось ещё одно окно с другой группой из 11 вкладок — 4 гигибайта I\O и 890 мегабайтов записи. Да и после первого раза я сравнил показания, разница была фантастическая.
Да, я понимаю, Лиса пишет много, свински много, но не столько же.
Да, я понимаю, Лиса пишет много, свински много, но не столько же.
Если взять за константу 1,1 ГБ записанных Firefox данных, то за рабочий день можно ожидать записи информации объемом 35 ГБ, если не выключать систему.
Установил значение browser.sessionstore.interval в 15000 мс
Проверил – у меня по-дефолту уже стоит 15000. FF 48.0.1.
Я в убунте своей поставил profile-sync-daemon который на overlayfs в рамдиске все пишет и иногда синкает с ssd. Простейшее решение проблемы. Две команды и все.
https://github.com/graysky2/profile-sync-daemon
https://github.com/graysky2/profile-sync-daemon
Вся статья — попытка решить проблему, которой нет.
Не стоит переживать по поводу преждевременной смерти SSD. Современные алгоритмы Wear leveling-а аккуратно «размазывают» эту нагрузку по всему диску.
А запаса даже в 10000 перезаписей на ячейку вполне хватит лет на 5-10 непрерывной записи.
Все известные мне поломки SSD происходили из-за сбоев контроллера. Сами чипы ни разу не подводили.
З.Ы. Это все конечно справедливо, если у вас хотя бы треть пространства на SSD свободна.
Не стоит переживать по поводу преждевременной смерти SSD. Современные алгоритмы Wear leveling-а аккуратно «размазывают» эту нагрузку по всему диску.
А запаса даже в 10000 перезаписей на ячейку вполне хватит лет на 5-10 непрерывной записи.
Все известные мне поломки SSD происходили из-за сбоев контроллера. Сами чипы ни разу не подводили.
З.Ы. Это все конечно справедливо, если у вас хотя бы треть пространства на SSD свободна.
… запись в файл recovery.js ведется постоянно со скоростью 2 МБ/с.
Что можно сделать?
Если у вас обычный жесткий диск, то можно особо не переживать...
Да действительно, обычный HDD же совсем не страдает от нехватки IOPS на современных задачах и не является «бутылочным горлышком» почти во всех случаях работы. Подумаешь, ежесекундное позиционирование головки в определённой области диска и 2МБ/с запись совсем не повредит. То ли дело на SSD, там же ресурс ограничен! Всего-то жалких 200 ТБ для, например, моего 256ГБ Samsung 840 Pro, вышедшего в 2013 году и за три года хардкорного использования, потратившего ОБОЖЕОБОЖЕ 7% ресурса!
Проблема загаживания браузерами дисков мягко говоря не новая. Настолько не новая, что я за время знания о ней поменял несколько SSD. Шло время, уже заметное число пользователей успело перейти на SSD, а не только энтузиасты. Вышла пара десятков «новых» версий каждого из браузеров. Но по прежнему «разработчики знают о проблеме». Круто. Впрочем, судя по комментариям, действительно достаточно было просто подождать, и на современных SSD запись с интенсивностью 2Мб/с уже не является критичной. Да, тупой, бессмысленной, неоправданной и попросту дикой. Но уже вполне допустимой. Круто.
Стоит расширение Session Manager, настроено ежеминутное сохранение профиля. Проблемы с записью 2 Мб/с нет.
Что-то автор переврал…
А это означает что 32Gb не всё на жёсткий диск ушло.
Столбец «Write (byte/s)» списка «Disc activity» приложения «Resource Monitor» это мгновенная скорость, о полном объёме по ней судить нельзя.
Так что, скорее всего, масштаб проблемы преувеличен и по меньшей мере нераскрыт.
Циклы перезаписи SSD уже холивар наравне с ГМО и «вредной» химией)))
I/O Write Bytes — The number of bytes written in input/output operations generated by a process, including file, network, and device I/Os. I/O Write Bytes directed to CONSOLE (console input object) handles are not counted.
А это означает что 32Gb не всё на жёсткий диск ушло.
Столбец «Write (byte/s)» списка «Disc activity» приложения «Resource Monitor» это мгновенная скорость, о полном объёме по ней судить нельзя.
Так что, скорее всего, масштаб проблемы преувеличен и по меньшей мере нераскрыт.
Циклы перезаписи SSD уже холивар наравне с ГМО и «вредной» химией)))
Тоже замечал, что FF любит кушать диск, но не знал кто именно виновник.
Интересно, а такое поведение присутствует у мобильных браузеров?
Одно из решений — перенести папку Roaming на другой диск.
Есть программа SSDReady которая давно не обновлялась, закончился сертификат и поэтому у нее с автозапуском проблемы
Программа очень хорошая, аналогов не нашел
Но в ней четко видно сколько и куда, в какие файлы записалось, при помощи этой программы перенес симлинками несколько программ в которых нет острой необходимости в производительности на HDD
в том числе и профиль Firefox который слишком много пишет (35гб/сутки) на диск (открыт круглосуточно)
что бы не тормозил из за кэша, дисковый отключил, кэш памяти увеличил до 300мб
browser.cache.disk.enable = false
browser.cache.memory.capacity = 307200
торможений не наблюдаю, т.к. открыт постоянно, длительные старты не напрягают
Программа очень хорошая, аналогов не нашел
Но в ней четко видно сколько и куда, в какие файлы записалось, при помощи этой программы перенес симлинками несколько программ в которых нет острой необходимости в производительности на HDD
в том числе и профиль Firefox который слишком много пишет (35гб/сутки) на диск (открыт круглосуточно)
что бы не тормозил из за кэша, дисковый отключил, кэш памяти увеличил до 300мб
browser.cache.disk.enable = false
browser.cache.memory.capacity = 307200
торможений не наблюдаю, т.к. открыт постоянно, длительные старты не напрягают
НЛО прилетело и опубликовало эту надпись здесь
Полезна длительного мониторинга — именно в плане объемов/интенсивности с разбивкой по логическим дискам.
А если нужно работаться кто конкретно и куда пишет, тут да или платная версия или можно бесплатный Process Monitor использовать включив в фильтрах мониторинг только файловой системы и потом вызвав группировку собранного лога по файлам/папкам.
Правда в отличии от SSDReady и других специализированных программ он работу компьютера существенно притормаживает и памяти много есть начинает если интенсивность работы с диком высокая или если надолго включенным оставлять — из-за того что очень и очень подробно все записывает — каждую мельчайшую операцию со всеми подробностями в лог пишет. А за сутки работы там их миллионы или даже десятки миллионов операций набирается и соответственно записей в базе данных.
А если нужно работаться кто конкретно и куда пишет, тут да или платная версия или можно бесплатный Process Monitor использовать включив в фильтрах мониторинг только файловой системы и потом вызвав группировку собранного лога по файлам/папкам.
Правда в отличии от SSDReady и других специализированных программ он работу компьютера существенно притормаживает и памяти много есть начинает если интенсивность работы с диком высокая или если надолго включенным оставлять — из-за того что очень и очень подробно все записывает — каждую мельчайшую операцию со всеми подробностями в лог пишет. А за сутки работы там их миллионы или даже десятки миллионов операций набирается и соответственно записей в базе данных.
И нигде не написано, сколько оперативки у чувака. Операционка может работать в одном из двух режимов — либо диск кешируется в памяти, либо память складируется на диск. Ставящие SSD поперед избыточной оперативки, то есть, не брезгующие вторым вариантом — CCЗБ
Спасибо, что хотя бы так сделали. До этого приходилось использовать самописные скрипты копирования/бэкапа (напр. с помощью windows shadow copy). А то память закончилась — в sessionstore.js пишется мусор + падение через пару дней…
В трекере FF было обсуждение более надёжных схем хранения с меньшими накладными (напр. SQLite), но желающих переделывать уже работающий вариант не нашлось.
В трекере FF было обсуждение более надёжных схем хранения с меньшими накладными (напр. SQLite), но желающих переделывать уже работающий вариант не нашлось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Firefox пишет много данных на SSD. Как это исправить?