[Webkit-unassigned] [Bug 30551] New: What's eating up all the memory?

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30551

           Summary: What's eating up all the memory?
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
               URL: http://4.bp.blogspot.com/_JFpJ_4Fo-ZU/StzrnoCXLGI/AAAA
                    AAAAFFM/o1dBTLZ65os/s1600-h/test.png
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: luying.pan at gmail.com


Not sure if this is a leak. I'm testing memory footprint for the webkitgtk
port. I left about 20 sessions running in separate processes over the weekend
and when I came back, only two were left running, and their mem usage grew from
30MB to 600MB while cycling over the same 20 urls while the other 18 processes
simply died away. To do this test, I modified the GtkLauncher to cycle through
the URLs when the LOAD_FINISHED condition is reached. I tried something similar
on the QT port, but didn't get a chance to wait that long to see results.
However just cycling through about 5 URLs within a few minute I saw the memory
grow to 40MB
(http://4.bp.blogspot.com/_JFpJ_4Fo-ZU/StzrnoCXLGI/AAAAAAAAFFM/o1dBTLZ65os/s1600-h/test.png).
I've seen it grow as high as 100MBs with more URLs, even though I disabled
caching, and set the max cached page in memory to 0 (on qt port only).

Does the webkit memory mean to grow unbounded? If so, are there any ways to
limit it throug configuration? I'm looking for a predictable way to run as many
browsing sessions as I can in their own processes (private browsing sessions)
regardless of size of the pages being viewed knowing that no one browser will
be starved of resources. Is there anyway to guarantee this? As in given a
certain amount of RAM, I want to know the exact number of active webkit
browsing sessions I can run.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.