(earlier this week:) To debug this further I started chromium under
"strace -f -o /tmp/..."  : Must be run as root. Hmm.

Today I tried something different. I used strace on ALL 33 chrome
processes. Many did something every second or so, just one was in a
tight loop. This is also the process that continues to use about 30% of
one core.

I used "task manager" from Chrome to try to figure out what chrome would
call this process itself. I expected to find "browser", but the top CPU-
users according to chrome were using only about 2% of CPU time, so it is
not listed on the "task manager" list. :-/

The process that is using CPU time, turns out to be the same as the one
that is causing the network traffic: Just stopping that one process
causes the network traffic to stop.

What I don't understand is how the calls:


poll([{fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=30, events=POLLIN}, 
{fd=31, events=POLLIN}, {fd=41, events=POLLIN}], 5, 0) = 1 ([{fd=12, 
revents=POLLIN}])
recvmsg(30, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
read(12, "!", 2)                        = 1
write(28, "\0", 1)                      = 1
recvmsg(30, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
poll([{fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=30, events=POLLIN}, 
{fd=31, events=POLLIN}, {fd=41, events=POLLIN}], 5, 0) = 0 (Timeout)
recvmsg(30, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(30, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)

end up causing NFS traffic. It is about 50/50 that I see a timeout and "data 
available on fd 12" 
When that data is available and read (one character) then often one character 
is written to fd 30 (more than 50% of the cases, but not always). 

The three filedescriptors are a pipe and two sockets. I don't know how
to find out where they go.

lr-x------ 1 wolff wolff 64 Feb 20 13:40 12 -> 'pipe:[42472991]'
lrwx------ 1 wolff wolff 64 Feb 20 13:40 30 -> 'socket:[42471337]'
lrwx------ 1 wolff wolff 64 Feb 20 13:40 31 -> 'socket:[42470374]'

I see 4637 poll calls each 10 seconds, 2270  read (12...) calls (49%)
and 1537 (33%) writes to fd 30. With about 23000 total EAGAIN calls to
recvmsg. The total of 23000 corresponds to the number of network packets
in a period of 10 seconds...

So my conclusion is that

recvmsg(30, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(30, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)

is causing NFS(?!) network traffic.

OK. Found it.... That process has many tasks and pipe 12/13 is used for
inter-task communciation.  Some of the other tasks are spinning on
statting and/or opening some files:

/home/wolff/snap/chromium/common/chromium/Default/databases/Databases.db-wal
/home/wolff/snap/chromium/common/chromium/Default/databases/Databases.db-journal
/home/wolff/snap/chromium/common/chromium/Default/File System/primary.origin

These files don't exist. (such a "does not exist" is not cached by NFS,
by design).

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1893650

Title:
  Chromium snap causes network traffic. (Duh!)

Status in chromium-browser package in Ubuntu:
  New

Bug description:
  When Chromium is running (but otherwise idle!), there is NFS traffic
  between my workstation and the NFS server here. On the order of 24000
  packets per second. Several tens of packets, OK. several hundreds:
  mwah. But this is outrageous.

  When strace-ing the chrome process I see:

  poll([{fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=31, events=POLLIN}, 
{fd=32, events=POLLIN}, {fd=137, events=POLLIN}], 5, 0) = 0 (Timeout)
  recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
  recvmsg(31, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
  recvmsg(32, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
  recvmsg(32, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)
  recvmsg(32, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily 
unavailable)

  It uses poll to wait for events... and then gets informed: A timeout
  occurred, no filedescriptors are ready and then STILL Tries to read
  from fd 31 and 32. Furthermore, the process seems to specify a 0
  timeout as quite often I see the poll call return in about 20-50
  microseconds.

  The process that is doing this shows as:

   /snap/chromium/1284/usr/lib/chromium-browser/chrome --no-default-
  browser-check --no-first-run --password-store

  1) 
  Description:    Ubuntu 20.04.1 LTS
  Release:        20.04

  2) 
  chromium-browser:
    Installed: 84.0.4147.105-0ubuntu0.20.04.1
    Candidate: 84.0.4147.105-0ubuntu0.20.04.1
    Version table:
   *** 84.0.4147.105-0ubuntu0.20.04.1 500
          500 http://nl.archive.ubuntu.com/ubuntu focal-updates/universe amd64 
Packages
          100 /var/lib/dpkg/status
       80.0.3987.163-0ubuntu1 500
          500 http://nl.archive.ubuntu.com/ubuntu focal/universe amd64 Packages

  
  3) I expect chromium to use little to no resources (CPU, network) when I'm 
not actively using it. (asking for small memory footprint is not currently 
realistic). 

  4)_ Chromium seems to do something that requires NFS traffic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1893650/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to