Trace: https://drive.google.com/a/google.com/file/d/0BymXqkwbVFZ7LWVyWlo2WDZ3b28/view?usp=sharing

Folder with debug dumps: https://drive.google.com/open?id=0BymXqkwbVFZ7S21PSllndkF2c2s

For the record: I'm actually not bothered by Chrome eating all my RAM, what concerns me is keyboard input being laggy which seems to be correlated with the high amount of RAM used in the browser process.

Another FTR: After closing Chrome, 17G of RAM were released.

folks, this a quite emblematic case. Thanks to tnagel@'s patience we collected lot of data.
To be clear, this is not just about memory numbers themselves. tnagel@ here ended up with a sluggish browser being almost unusable.
There is a number of different things going on here.

First of all, reference trace here is: "trace_3rd_attempt.json.gz" in the #2 link

What's going on:
- This is Chrome 54.0.2840.100 on Google Ubuntu
- Chrome in total uses 17 GB of memory (PSS)
- There are 63 processes in total, around ~40 tab opens, considering the number of extensions, ppapi processes.

If you do some rough math, (15 GB - $browser-pss - $tracing_tab-pss) / 62 processes ~= 177 MB per child process, which is a quite reasonable value itself.
The things that are not reasonable here are:
- There are some definite outliers there:
  - The Google Groups tab is using 740 MB:
    - 392 MB of V8 heap, most of that (342 MB) in the old space
    - 250 MB in BlinkGC, although the details of the dump says that there are *only* 182 MB of allocated objects in the oilpan heap
    - 45 MB in PartAlloc
  - Inbox: 632 MB, similar distribution
  - Play Music: 564 MB
  The other tabs are more, somewhat, reasonable.
  Now it has to be said that there were lot of improvements in M54->M56 so probably these values would be quite different today.
  What is really beating us is the number of processes kept alive.

- The browser process itself takes 5GB. As I was fearing most of that is in malloc, so right now cannot add too much.
  This seems to be a repeating pattern, there is something going wrong in the browser process and we need to figure out what.
  However I asked him to take a coredump (see #2). Honestly I've never tried this before and I don't know how much is possible to extract from a core dump, but it's worth at least trying.
  Debugging Symbols are here: paste/6667209149513728

Will Purge and Suspend (https://bugs.chromium.org/p/chromium/issues/detail?id=607077) make this go away, or does purging only affect the tab-specific renderer processes (i.e. leaving the browser process still bloated)?

Definitely some of the problems will be solved by purge and suspend and definitely the memory coordinator.
tnagel's comment in #3 is spot on: the problem here is not just 17 GB, it is the fact that chrome is choking.
I guess that if were using "smartly" 17 GB tnagel wouldn't have opened the task manager in the first place.
THe other big problem here is browser process @ 5GB: I strongly suspect there is a bloat/leak there.

Yeah, some of the problems will be solved by Memory Coordinator, but we should definitely look into the browser process @ 5 GB.

We currently strongly suspect a memory leak in the browser, as we've observed the malloc heap grow monotonically with time. In which case MemoryCoordinator won't do much if anything here.

(In poking around we found one minor memory leak on Windows 7 only. No smoking gun yet.)

I believe I'm having the same issue here.  The behavior I see is a sudden increase from ~0.8-1.0 GB to 5+GB in a period of <1min, during which the browser (actually, my entire laptop) becomes essentially unusable.  It then suddenly drops to 1GB again.

 This should have been because of  issue 678768 . The guess is that it started in 53-54.

After getting back from vacation, my browser process is at 5.7GB (running 55.0.2883.87 (Official Build) (64-bit) on my corp Ubuntu).

In lack of detailed data, i'm speculatively marking this as a dupe of  Issue 678768 . Really smells like that one

Extremely likely this is a dupe of  issue 678768