4

Debugging some CouchDB problems, I was looking for (still open) deleted files:

$ lsof -nP | grep '(deleted)'

And to my surprise I found that Google Chrome has around 16900 such files:

  • 15870 files in /run/shm/.com.google.Chrome/
  • 969 files in /opt/google/chrome/

And there are around 350 deleted files from other applications (Dropbox, etc)

  • Does this mean Chrome is "leaking" files?
  • Do these files use up memory (appart from the small use of kernel table entries)? I guess not: they are probably only in the filesystem, albeit without directory entry.
  • Do they use disk space? I would say so, since they are still open, the kernel is not freeing up the disk space.

I have Google Chrome Version 43.0.2357.130 (64-bit), and my system is:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty
Improve this question
7
  • It doesn't leak - and yes they use disk-space. To Chrome they're not deleted - those are files which exist only in Chrome's namespace sandbox. I think it's kind of cool/weird you can detect them at all. Anyway, Googke prohibits any Chrome tab process from reaching out and touching the filesystem - and that's mostly how. They had to come up with something like it to push the HTML 5 filesystem into the spec. Commented Jun 30, 2015 at 9:03
  • Yes but ... 17000 files! Are they all being used by Chrome? Or are they forgetting to close the file handles somewhere? Commented Jun 30, 2015 at 9:06
  • No, they all get closed... eventually. Have you ever looked at Chrome's own task manager? Do shift+esc. Commented Jun 30, 2015 at 9:09
  • Well, I have around 40 tabs, and 17000 files. I find it difficult to believe that all those files are needed by chrome right now. I find it easier to accept that, since I started chrome (yesterday), it has been opening and closing files, deleting some, forgetting to close some, and we have reached a situation where some not needed files are still open. I mean ... 17000 files! Commented Jun 30, 2015 at 9:13
  • 1
    No, they're not all needed, but neither are 39 of your tabs. There's at least one process for each tab - and then there are renderers and V8 and ... well, there's a lot going on there - and you've got 40 times that. And anyway, what does it matter? Those are mostly all in RAM. Commented Jun 30, 2015 at 9:17

2 Answers 2

Reset to default
4

That's not a problem on your system, it's the way Chrome works. It isn't leaking memory or files or anything, that's data that Chrome is currently using.

Chrome uses many separate processes (not exactly one per tab, but that's the general idea). Some of these processes need to exchange data. They do this via shared memory. Chrome implements (at least some of) this shared memory via files in an in-memory filesystem (tmpfs) which are deleted as soon as they're created (ensuring that the files don't get mixed up).

The files you're seeing don't take any disk space, they take up memory. They're located under /run, which is an in-memory filesystem. They can get swapped out like almost anything else in RAM.

The only time when you'd be seeing deleted files under /opt/google/chrome is if you've upgraded Chrome but not restarted it yet. Restart it and the deleted files will go away.

Improve this answer
0

mikeserv says "39 (out of 40) of your tabs [are not needed]".

This is (probably) not true. Yes, we look at only one tab at a time. We keep multiple tabs because, at different times of the day, we need the info in those tabs and, usually, want to pick from where we left off, after consulting info in other tabs.

When chrome is running, something called "Composito", "WorkerPoo", and chromium use 26% of the 270,479 open files. This seems rather excessive for 30 tabs!

41062 Composito
17078 chromium-
12625 WorkerPoo

With my 30 tabs, lsof reports around 170 instances of various library modules:

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
Improve this answer
2
  • is this supposed to be answer or more question? Commented Oct 23, 2015 at 19:03
  • It's more info. It's shocking to me to see so many files being kept open by these 3 programs. It's 2 orders of magnitude more than I would have expected. I'm still getting truncated Thunderbird messages. That problem was cured when I upped the number of open files in /etc/security/limits.conf from 4096 to 8192, but the problem is back again! Do I really need to up the number of open files to half a meg? Commented Dec 19, 2015 at 7:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.