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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Oct 19 19:59:26 PDT 2009


           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
        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
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.

More information about the webkit-unassigned mailing list