2017-10-05 69 views
2

最近我一直在用MATE玩Ubuntu 16.04(補丁和升級)。在操作系統之上安裝了Firefox 56(FF),用於瀏覽網頁。正如我們所知,有些場合FF下降。但是我注意到在這種場合之後有相當高的磁盤利用率。原因是舊的FF進程沒有關閉稱爲Web Content的緩存進程。在Firefox崩潰後Web內容進程仍在內存中

根據Google-d信息,默認情況下有4個這樣的進程。通過擺弄about:config,您可以修改子進程的數量。有關此檢查的更多信息FF Electrolysis。我不會標記這種惡意行爲,但其不便之處永遠不會那麼少。
我已經做了一個腳本,在FF崩潰和殺死這樣的過程。他們運行命令與此類似:

"/usr/lib/firefox/firefox-contentproc-childID8-isForBrowser-intPrefs5:50|6:-1|18:0|28:1000|33:20|34:10|43:128|44:10000|49:0|51:400|52:1|53:0|54:0|59:0|60:120|61:120|91:2|92:1|106:5000|117:0|119:0|130:10000|155:24|156:32768|158:0|159:0|167:5|171:1048576|172:100|173:5000|175:600|176:4|177:1|186:2|200:60000|-boolPrefs1:0|2:0|4:0|26:1|27:1|30:0|35:1|36:0|37:0|38:0|41:1|42:1|45:0|46:0|47:0|48:0|50:0|55:1|56:1|57:0|58:1|62:1|63:1|64:0|65:1|66:1|67:0|68:1|71:0|72:0|75:1|76:1|80:1|81:1|82:1|83:0|85:0|86:0|87:1|88:0|93:1|94:0|100:0|105:0|108:1|109:0|111:1|112:1|114:1|118:0|120:0|122:0|124:1|125:1|131:0|132:0|133:1|135:0|146:0|153:0|154:0|157:1|160:0|162:1|164:1|165:0|170:0|174:1|179:0|180:0|181:0|182:1|183:0|184:0|185:1|188:1|192:0|193:0|194:1|195:1|196:0|197:1|198:1|199:1|201:0|202:0|204:0|212:1|213:1|214:0|215:0|216:0|-stringPrefs3:7;release|134:3;1.0|151:332;  ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

‪‫‬‭‮ ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞./。ᅠ�|152:8;moderate|-greomni/usr/lib/firefox/omni.ja-appomni/usr/lib/firefox/browser/omni.ja-appdir/usr/lib/firefox/browser1078truetab "

配件此命令到目前爲止,我已經確定了:

  1. 對於首發:/usr/lib/firefox/firefox -contentproc -childID"CHILD_ID" -isForBrowser
    其中"CHILD_ID"是子處理緩存FF的指數,我有他們從0到9,因爲我的FF設置默認爲4,但最大爲10.其他參數是不言自明的。
  2. 然後有許多喜好int /布爾/字符串看起來像管道過程到其他進程。我不確定如何將這些解釋爲人類可讀的語言。
  3. 最後所有進程都以-greomni/usr/lib/firefox/omni.ja -appomni/usr/lib/firefox/browser/omni.ja -appdir/usr/lib/firefox/browser "FF_PID" true tab
    結尾,其中omni.ja是一個多庫存檔,更多信息here。 「FF_PID」是創建這種緩存子進程的FF進程的進程ID號。最後兩個參數true tab對我而言未知。 FF的手冊頁太淺,無法在這裏幫助。
  4. 如果你想看到你掛了流程盡我搭訕:ps -ef | grep "firefox -contentproc" --color=never | awk ' { t = $1; $1 = $3; $3 = t; print; } ' | grep "^1" --color=never

所以我的推理和質疑是:

  1. 爲什麼是它FF崩潰報告將這些過程在存儲?
    這是剩餘的子進程用於標籤恢復?
    如果不是,爲什麼?
  2. 我可以在崩潰前使用此功能恢復瀏覽器中的文本編輯(例如論壇消息在崩潰時丟失)嗎?
  3. 到目前爲止,我終止了所有進程以釋放我的磁盤使用。有沒有更好的辦法 ?請讓我知道。
  4. 命令中那些荒謬的管道是什麼?我想這是我的磁盤使用率如此之高的主要原因。尋找一些不存在的內存地址?

我的清理行是:for ch_id in `ps -ef | grep "firefox -contentproc" --color=never | awk ' { t = $1; $1 = $3; $3 = t; print; } ' | grep "^1" --color=never | awk '{print$2}'`; do kill -9 $ch_id ; done

回答

1

這僅僅約在命令行的「管道」的部分的答案。這些不是管道,而是 - * Prefs選項的firefox命令行參數語法的一部分。據我所知,這只是在源代碼中「記錄」(見https://dxr.mozilla.org/mozilla-release/source/dom/ipc/ContentProcess.cpp)。

例如-stringPrefs選項引用了一些關於字符串的偏好(我不知道更多),語法如下:「index:length; string |(next entry ...)」。的怪異人物名單似乎對應於http://kb.mozillazine.org/Network.IDN.blacklist_chars列出的黑名單字符。

我有相同(或非常相似),結果當我「PS -elf |火狐」我已經在別處找到了在互聯網上的其他參照此字符串(但不是這個字符串)。