Firefox每分钟将兆字节的数据写入磁盘,为什么?


26

iotop -a(大约I / O)在Linux上显示约10分钟。浏览互联网:

Total DISK READ:       0.00 B/s | Total DISK WRITE:       0.00 B/s               
  TID  PRIO  USER     DISK READ DISK WRITE>  SWAPIN      IO    COMMAND           
17330 be/4 wojdyr     1540.00 K     38.48 M  0.00 %  0.00 % firefox              
  403 be/3 root          0.00 B     31.65 M  0.00 %  0.06 % [jbd2/sda5-8]        
17276 be/4 wojdyr      800.00 K     31.06 M  0.00 %  0.00 % firefox              
17329 be/4 wojdyr        0.00 B     20.96 M  0.00 %  0.00 % firefox              
31896 idle wojdyr        0.00 B   1200.00 K  0.00 %  0.00 % virtuoso-~.ini +wait 
31924 be/4 wojdyr        0.00 B   1064.00 K  0.00 %  0.00 % akonadi_n~ail_feeder 
18959 be/4 wojdyr        0.00 B    796.00 K  0.00 %  0.01 % firefox

我对写入磁盘的数据量感到非常惊讶。我关闭了磁盘缓存,但是并没有什么明显的区别。我关闭了block-reported-attack-sites/ web-forgeries-没有任何变化。

在Firefox(10.0.1)中,这种写入磁盘的速率正常吗?它很快超过了我的Firefox配置文件的总大小。

查看firefox配置文件中文件的修改时间,我发现一些文件经常被修改:

cookies.sqlite{-wal,-shm}
sessionstore.js
places.sqlite{-wal,-shm}
permissions.sqlite

我的系统或配置有问题吗?或者是FF的典型问题?

我不喜欢这种无意义的写入(SSD)磁盘。我可以做些什么吗?

编辑:我已经找到本指南如何将整个Firefox配置文件重新定位到RAM。在会话期间,它几乎将firefox写入的数据减少到零。(我知道这有点偏执,可能不值得麻烦。)


7
我认为您太担心SSD的写入限制。除非它是第一代固态硬盘,否则笔记本电脑将比固态硬盘先死。
surfasb 2012年

你是对的。我知道我没有理由为此磁盘担心太多,但我
无能为力

我知道这是一个古老的问题,但这是我在Google上搜索时遇到的问题。对我来说,我发现Firefox的Web Of Trust(WOT 20150708)附件每秒写入磁盘38.8 KB。因此我禁用了该加载项。
路易吉·普林格

ServeTheHome最近也发现了此问题:servethehome.com/…–
bwDraco

2
@surfasb“除非它是第一代固态硬盘,否则您的笔记本电脑将先于固态硬盘死掉。” 现在情况恰恰相反-基于TLC的新型SSD的使用寿命比带有MLC的旧SSD的寿命短得多,尤其是与具有SLC NAND的固态硬盘相比。
ggurov '16

Answers:


17

我调查了写入SSD的位置。我发现了你做的同样的事情。在分析了写入日志并思考了一切之后,我意识到这是Firefox的崩溃恢复。为了能够从崩溃中恢复,Firefox必须将会话写入磁盘。会话信息存储在您列出的四个文件中。Firefox每30秒更新一次。在一个大型会话中,有很多选项卡,每天总计可能增加几个GB。

但是,正如surfasb所说,这根本不用担心。


1
谢谢!很好的分析。您知道是否可以更改磁盘写入频率吗?每30秒似乎有些过于频繁对我来说
马辛

4
about:config其中有一个设置browser.sessionstore.interval。有趣的是,Firefox应该每15秒存储一次。这不是我观察到的间隔。
Alpha先生2012年

请注意,如果您有固态硬盘,这些过多的写入操作绝对值得担心。
Pointy

1
并不是的。如果Firefox在一天之内进行10GB的写操作,那么十年之内仍只能增加36TB的顺序写操作。即使它的低端SSD导致36TG顺序写入成为问题,但十年之内,其他事情可能还是有时间先死了。
Alpha先生

2
这些70-75 TB的数字与保修有关,这意味着如果您超出了该写入次数,则无法在保修期内更换它。这并不意味着该驱动器会在那时磨损并死掉,这并不意味着该驱动器会在3年后就失效,仅仅是因为它具有3年的保修期。像保修一般一样,它们非常保守。
Alpha先生

23

Firefox中有一个设置可以控制会话还原保存文件的频率。转到about:config并更改:

  • browser.sessionstore.interval更改保存会话的频率。在我的系统上,默认值为15000(毫秒),因此它每15秒写入一次磁盘。如果将其增加到300000,它将仅每5分钟写入一次。

  • 可以将browser.sessionstore.enabled设置false为完全禁用此功能。这将减少Firefox写入的磁盘数量,但这也将阻止Firefox崩溃时还原会话。


在我的RHEL 7上,firefox将我的负载增加到6,但是它对CPU使用率的贡献不大。因此应该是消耗I / O的I / O。该解决方案实际上减少了I / O流量,从而使Firefox再次可用。
鼎陈义

3

加载大约10页后,Chrome浏览器中的某些页面看起来像这样:

iotop -a输出

所以我想这是正常的交换/页面文件使用。

(尽管有人会认为我只使用31%的RAM,但它根本不会交换。)


感谢测试!我看起来不像交换,如果强制将某些文件尽可能频繁地写入磁盘而不是将其保留在内存中,显然不是Firefox。
marcin 2012年

1

FF不断以2.5+ MB / s的速度写入磁盘!我跑去sudo iosnoop -p PID,发现Evernote Web Clipper正在完成所有写作。我将其删除,磁盘写入速度降至0至几kb / s。


对于这个可能很愚蠢的问题感到抱歉,但是是FF进程(通过Evernote插件)还是Evernote进程本身使您的I / O饱和了?在第一种情况下,如何iosnoop能够检测到它?我从未使用过该工具,但我认为它跟踪了进程的I / O,无法将Firefox自身的用法与Firefox中运行的扩展区分开来。
安东尼奥

-1

浏览器将对Cookie的更改和会话存储到磁盘上是完全正常的。关于您打开了哪些标签的数据必须保存在某处。首先,不应将您的usr目录(我认为是Firefox用来存储这些内容的目录)位于SSD上,而应将其移至HDD。


问题在于大量的书面数据,比存储cookie或打开标签页所需的数量级高几个数量级。关于HDD,我只有SSD。
marcin'3

是笔记本电脑还是类似设备?使用纯SSD设置效率不是很高,因此,如果可以帮助我,建议您使用HDD来存储易失性文件。我想您的FF可能有问题,但是我怀疑使用我们的数据可以很容易地进行诊断。您是否尝试过备份FF配置文件并进行全新安装?
kotekzot 2012年

3
我看不到不使用SSD应该有什么帮助。如果经常访问该文件,那就很好了,甚至建议将其保存在SSD上。我能理解将电影/照片存储在HDD上的原因,因为时间/速度在这里并不重要,但是由于文件经常访问,因此应该将其存储在原处。如果您将其放入答案中,我将为-1。答案本身是好的,只是评论并没有真正的依据。
MadBoy 2012年

@MadBoy如果这些文件位于HDD上,则对于整体速度而言并没有多大关系,但对于SSD的使用寿命而言,这无疑是一个奇迹。
kotekzot 2012年

2
kotekzot- “它将为SSD的使用寿命创造奇迹” -是否有任何资源可以证明您的主张?我要说的是,将会话存储在SSD上要好得多,因为它速度快且不会产生无休止的噪音,也不令人讨厌。
Tomas 2013年

-1

也许有人破坏了该计算机,并正在将其用于具有混淆和加密文件系统的匿名P2P或F2F网络?喜欢:

https://zh.wikipedia.org/wiki/I2P

要么

https://zh.wikipedia.org/wiki/暗网(文件共享)

https://zh.wikipedia.org/wiki/僵尸网络


1
那可能不是这个,但是感谢您的帮助,-1不是我的意思:)
marcin 2012年

无论如何,我可能做出了太多的假设,但我想如果不先进行测试就不应该建议灾难。我忘记了网页上的图像和内容有多大。
conspiritech 2012年

他们之所以这样做,是因为当您决定启动Photoshop或其他工具时,他们不想占用RAM,并且猜测不可行/不允许在其周围编写规则。
conspiritech 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.