There is a memory spike of about 60MB between Feb 2 and Feb 3 on the Mac OS X 10.6.8 x86_64 nighlies. Chart: http://mozmill-release.blargon7.com/#/endurance/charts?branch=13.0&platform=Mac&from=2012-01-31&to=2012-03-13 Report from 2012-02-02: http://mozmill-release.blargon7.com/#/endurance/report/60c6a10dbd2309ae006fdbe21d0443b1 Report from 2012-02-03: http://mozmill-release.blargon7.com/#/endurance/report/9543ad0209d5ac0be23230ff97071734 Changeset: http://hg.mozilla.org/mozilla-central/rev/e777c939a3f9
Interesting to note that this spike has more or less sustained over the last couple of days. I'm also seeing an increased duration of the testruns. The only thing that changed in our Endruance tests recently was disabling tests (we did not actually add any new code).
Of all the changes between the 2nd and 3rd on mozilla-central, I would expect this: http://hg.mozilla.org/mozilla-central/rev/c18523b51058 Bug 716014 - Use CompartmentGC more often
According to the following report, we see a huge spike when the Private Browsing test executes: http://mozmill-release.blargon7.com/#/endurance/report/66015da03b8cfecd3cf0cf0a86000a6e testFlash_SWFVideoObject.i50 = 120MB testPrivateBrowsing_EnterAndLeave.i3 = 125MB testPrivateBrowsing_EnterAndLeave.i17 = 174MB testPrivateBrowsing_EnterAndLeave.i24 = 197MB testPrivateBrowsing_EnterAndLeave.i38 = 232MB testPrivateBrowsing_EnterAndLeave.i45 = 243MB testTabbedBrowsing_OpenNewTab.i1 = 113MB
Note that before Feb 3rd, testPrivateBrowsing_EnterAndLeave goes from 120MB at i1 to 160MB at i45. It's possible that we have always had this regression in the test but that something recent has caused the memory footprint to be exaggerated.
Running this test in a sandbox (ie. alone) memory starts at 119MB in i1 and grows to 262MB by i50.
And one more test, on Firefox Nightly from Feb 2nd, memory starts at 124MB and grows to 195MB when run in a local sandbox.
I can manually reproduce this behaviour. 1) Start Firefox Nightly on a new profile and install memchaser 2) Open 10 new tabs to different pages (I just CMD+click open links from the first run page) 3) Enter private browsing mode 4) Quit private browsing mode RESULTS: After step 1: 124MB After step 2: 191MB After step 3: 166MB After step 4: 262MB, trickles down to 194MB after a minute I would say there is a probably memory regression when immediately exiting Private Browsing mode. I don't think the changeset in comment 2 caused this, it merely makes it more visible. Dave Hunt, what do you think?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8) > Created attachment 594794 [details] > Memchaser Log Some interesting highlights from the attached log file: 21:28:46 149MB (starting the test) 21:29:50 200MB (10 tabs loaded, enter PB mode) 21:30:09 176MB (PB mode on) 21:30:17 259MB (Exit PB mode) 21:32:44 157MB (Memory has settled after exiting PB mode) Main take-away: 50% spike in ~10s upon exiting PB mode, taking ~150s to clear.
OS: Mac OS X → All
Hardware: x86_64 → All
Summary: Memory usage spike detected in Mozmill Endurance tests for Mac OS X 10.6.8 x86_64 → Memory usage spike caused by Private Browsing endurance test
Anthony, what happens if you manually force a reduce memory action via about:memory? Does it drop immediately or how many times you have to repeat the action?
No amount of clicking "Minimize Memory Usage" in about:memory reduces the memory footprint.
Shouldn't we dupe this to bug 724677?
(In reply to Henrik Skupin (:whimboo) from comment #13) > Shouldn't we dupe this to bug 724677? No, this is not a dupe. At best it could be a "fixed by". I'd like to see what the fix for bug 724677 does to this test.
Component: General → Mozmill Tests
Product: Firefox → Mozilla QA
QA Contact: general → mozmill-tests
Version: 13 Branch → unspecified
No action happened here in over 2 years. Closing as incomplete.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [mozmill-endurance] → [endurance]
You need to log in before you can comment on or make changes to this bug.