☰

Google Chrome 发生了什么事并删除了文件

tag-icon • tag-icon files chrome tmpfs deleted-files
Google Chrome 发生了什么事并删除了文件

调试一些 CouchDB 问题，我正在寻找（仍然打开）已删除的文件：

$ lsof -nP | grep '(deleted)'

令我惊讶的是，我发现 Google Chrome 大约有 16900 个这样的文件：

  • 15870 个文件/run/shm/.com.google.Chrome/
  • 969 个文件/opt/google/chrome/

大约有 350 个从其他应用程序（Dropbox 等）中删除的文件

  • 这是否意味着 Chrome 正在“泄露”文件？
  • 这些文件是否会占用内存（除了少量使用内核表条目之外）？我想不是：它们可能只存在于文件系统中，尽管没有目录条目。
  • 他们使用磁盘空间吗？我想说的是，由于它们仍然打开，内核没有释放磁盘空间。

我有 Google Chrome Version 43.0.2357.130 (64-bit)，我的系统是：

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty

答案1

这不是您系统的问题，而是 Chrome 的工作方式问题。它不会泄漏内存或文件或任何东西，这是 Chrome 当前正在使用的数据。

Chrome 使用许多单独的进程（不完全是每个选项卡一个进程，但这是总体思路）。其中一些进程需要交换数据。他们通过共享内存来做到这一点。 Chrome 通过内存文件系统 (tmpfs) 中的文件实现（至少部分）这种共享内存，这些文件一旦创建就会被删除（确保文件不会混淆）。

您看到的文件不占用任何磁盘空间，而是占用内存。它们位于/run内存文件系统下。它们可以像 RAM 中的其他任何东西一样被交换。

/opt/google/chrome只有当您升级了 Chrome 但尚未重新启动时，您才会在下面看到已删除的文件。重新启动它，删除的文件就会消失。

答案2

mikeserv 说“39 个（共 40 个）选项卡[不需要]”。

这（可能）不是真的。没错，我们看着一次只有一个选项卡。我们保留多个选项卡，因为在一天中的不同时间，我们需要这些选项卡中的信息，并且通常希望在查阅其他选项卡中的信息后从我们离开的地方进行选择。

当 Chrome 运行时，名为“Composito”、“WorkerPoo”的东西和 chromium 使用 270,479 个打开文件中的 26%。对于 30 个标签来说，这似乎有点太多了！

41062 Composito
17078 chromium-
12625 WorkerPoo

通过 30 个选项卡，lsof 报告了各种库模块的大约 170 个实例：

lsof | grep '^Composito' | sed -e 's/^.............................................................................................//' | sort | uniq -c | sort -nr
173  /usr/lib/locale/locale-archive
172  /usr/lib/x86_64-linux-gnu/libXss.so.1.0.0
172  /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
172  /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
172  /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
172  /usr/lib/x86_64-linux-gnu/libXinerama.so.1.0.0
172  /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
172  /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0

相关内容