Closed Bug 1040430 Opened 6 years ago Closed 6 years ago

Memory report anonymization appears to have broken AWSY

Categories

(Toolkit :: about:memory, defect)

Product:
Toolkit
Component:
about:memory
Version:
33 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ehoogeveen, Assigned: johns)

References

(
URL
)

Details

When bug 1010064 landed, AWSY saw a massive drop in the reported numbers (more than halving those of the first graph). It didn't completely flatline, but it seems clear that something broke (for example, the "Images: After TP5 [+30s]" line did almost go to 0, and every line appears to be affected to some degree). 

I'm filing this in the about:memory component, although it's probably the website that needs to be adjusted in some way.
The window-objects numbers are identical for lots of the windows, which is really weird.
Lots of same-sized windows, which suggest some kind of error soon after their
creation, which makes sense if we're measuring memory frequently:

>   │  ├───0.73 MB (00.61%) ++ top(http://localhost:8083/tp5/etsy.com/www.etsy.com/category/geekery/videogame.html, id=715)
>   │  ├───0.73 MB (00.61%) ++ top(http://localhost:8084/tp5/gmx.net/www.gmx.net/index.html, id=718)
>   │  ├───0.73 MB (00.61%) ++ top(http://localhost:8085/tp5/csdn.net/csdn.net/index.html, id=721)
>   │  ├───0.73 MB (00.61%) ++ top(http://localhost:8086/tp5/xunlei.com/xunlei.com/index.html, id=724)
>   │  ├───0.73 MB (00.61%) ++ top(http://localhost:8087/tp5/hatena.ne.jp/www.hatena.ne.jp/index.html, id=727)
>   │  ├───0.73 MB (00.61%) ++ top(http://localhost:8088/tp5/icious.com/www.delicious.com/index.html, id=730)
>   │  ├───0.73 MB (00.61%) ++ top(http://localhost:8089/tp5/repubblica.it/www.repubblica.it/index.html, id=733)
>   │  ├───0.73 MB (00.61%) ++ top(http://localhost:8090/tp5/web.de/web.de/index.html, id=736)
>   │  ├───0.45 MB (00.38%) ++ top(http://localhost:8091/tp5/slideshare.net/www.slideshare.net/jameswillamor/lolcats-in-popular-culture-a-historical-perspective.html, id=8)
>   │  ├───0.42 MB (00.35%) ++ top(http://localhost:8097/tp5/homeway.com.cn/www.hexun.com/index.html, id=667)
>   │  ├───0.42 MB (00.35%) ++ top(http://localhost:8092/tp5/telegraph.co.uk/www.telegraph.co.uk/index.html, id=652)
>   │  ├───0.42 MB (00.35%) ++ top(http://localhost:8093/tp5/seesaa.net/blog.seesaa.jp/index.html, id=655)
>   │ 

AWSY's code was updated to account for the changes introduced by bug 1010064:

https://github.com/Nephyrin/MozAreWeSlimYet/commit/a80643f1ea6f4818d27323951e48fedf474d6db7

johns, has this change been deployed?
I don't think AWSY/mobile is affected here, it just looks like it is. The data there has always been bimodal - in some cases the memory-pressure code is hit and Fennec unloads background tabs and in some cases that doesn't happen. When it doesn't happen the memory numbers are pretty high, and looking at the window-objects list shows a bunch of URLs. When it does happen the memory numbers drop to pretty low and the window-objects list shows about:blank a lot.

It seems that the frequency with which the memory-pressure code is getting hit has increased recently, so the average "after-tabs" memory numbers have gone down. While this coincided with the time at which 1010064 landed, I don't think it's directly related. If you zoom in on the mobile data you can see the inverse-spikes become more and more frequent over a period of a couple of months. The zoomed-out view just shows averages which doesn't show that as well.
(In reply to Nicholas Nethercote [:njn] from comment #2)
> 
> AWSY's code was updated to account for the changes introduced by bug 1010064:
> 
> https://github.com/Nephyrin/MozAreWeSlimYet/commit/
> a80643f1ea6f4818d27323951e48fedf474d6db7
> 
> johns, has this change been deployed?

Yes, this is live -- builds after bug 1010064 were throwing an exception and failing to test entirely before that was pushed. Were there any other changes to how the callback is fired or what data is passed?
I think the change you made should be enough, but clearly it isn't. Are you able to see the error console during a run? There may be some JS errors showing up there.
(In reply to Nicholas Nethercote [:njn] from comment #5)
> I think the change you made should be enough, but clearly it isn't. Are you
> able to see the error console during a run? There may be some JS errors
> showing up there.

Sigh, indeed, when I restarted the test daemon for the change above it turns out I broke the TP5 symlink, and all pages were 404-ing on the test machine, which was producing no errors until I actually connected to the VNC sessions for the tests and looked at it. Fail.

It should be fixed now, all tests after July 14 re-queue'd. Will close this when the new data starts appearing looking proper
Assignee: nobody → jschoenick
Status: NEW → ASSIGNED
Thanks for looking into it! AWSY is now running again, but it seems to be about 20 days behind (currently). Is it just running as fast as it can until it catches up?
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #8)
> Thanks for looking into it! AWSY is now running again, but it seems to be
> about 20 days behind (currently). Is it just running as fast as it can until
> it catches up?

Yes, there were 1200+ pending tests after I nuked the bad data, so it will take a few days to catch up. I queued July 1st through present followed by the missing builds from june. You can see its progress on http://areweslimyet.com/status/

Leaving this open, however, as it looks like there are some bogus builds in May if you zoom in, so I will need to purge and re-queue those as well.
I think this bug can be closed now.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.