[Opera-Linux] OK, what can I do about Opera's never-ending thirst for memory?!

[Daniel Eckl]

Hi Eirik!

[...]
> Of course, this changes a lot of variables, so I'm not sure how much we
> can learn from it.
[...]
> Given that it seems to be a rather uncommon problem, I'm not sure that
> would tell us much, though.  It's changing too many things at once :)

As well for 64-bit to 32-bit change, as for trying on another PC, it
would give a hint if there is any cause in the local settings, in the
many image gallery pages Kenny uses or so on. If taking the whole
opera config and saved session to another machine and the problem is
gone, then we don't need to focus on the web pages itself, nor on
cache settings or cache locations and so on and so forth. It's all
about ruling out variables, you know? Then we could go back to the
main system and look at filesystem, file allocators etc.pp.

Don't be afraid of trying big changes first to get a rough direction
on where to look ;)

Best,
Daniel

2009/6/16 Eirik Byrkjeflot Anonsen <eirik at opera.com>:
> Daniel Eckl <daniel.eckl at gmx.de> writes:
>
>> Hi Kenny!
>>
> [...]
>> You can't easily get rid of the 64-bit environment without going
>> virtual by using vmware/Virtualbox and install a complete independent
>> 32-bit system inside. But still it might be worth a try, perhaps later
>> on in case we're still stuck.
>
> Of course, this changes a lot of variables, so I'm not sure how much we
> can learn from it.
>
>> So lets first focus on the other two points. As far as I understood,
>> you can reproduce this memory usage with rather low effort, so after
>> some hours it starts to raise. My first try would be to eliminate the
>> pages as a cause. Start with up to 5 tabs with a more text-page,
>> google, forums, webmail, whatever. The standard web user scenario. Try
>> to reproduce that this way. If it does not occur, then we know it's
>> triggered by the gallery pages (perhaps just one of them, who knows).
>> Try to add them one by one and observe. In case memory usage raises
>> linear, then it would point to your thought about not releasing
>> pixmaps or such. But perhaps you see a spike in raising when adding a
>> special site, so you could give the devs a hint which site triggers
>> that most.
>
> Yes, this would probably be the most useful approach.
>
> I would first try disabling java and plug-ins just to see if that's
> involved somehow.  But since we don't run plug-ins in-process on linux,
> it is unlikely to be the plug-ins themselves that leak memory (as long
> as it is the opera process itself that grows, of course.)
>
>
>> 2009/6/16 Kenneth Crudup <kenny at panix.com>:
> [...]
>>> I've been running Opera for a few years now (since 2002, anyway) and
>>> this is the only platform I've seen it on, but it's also the only one
>>> that's:
>>>
>>>  - a 64-bit platform
>>>  - using the NVidia closed-source drivers
>>>  - using Compiz
>
> I have a family member who has been complaining about similar behaviour
> for several years.  But he's running windows.
>
>>> Again, I'd love to have something to send the devs (map usage, the output
>>> of "inspectr" (is that finally running on the Linux/64 platform) but I
>>> think in my mind it's just not releasing all the pixmaps (which could be
>>> related to the display driver), but that's just my wild guess.
>
> Yes, that would be nice.  Unfortunately, I think it would be quite hard
> to make a program that could properly analyze opera's memory usage.
>
> I doubt the display driver has any significant effect on whether opera
> releases pixmaps.  Of course, if the X process is using large amounts of
> memory, it is possible that it is the display driver that doesn't
> release pixmaps (which could be opera's fault).  A similar argument
> holds for compiz (whether a program is running under compiz or not
> shouldn't really change much from the program's point of view.)
>
>>>
>>> I guess I could suffer thru the "nv" driver for a while :) and see what's
>>> up, but I develop on this system, too, and stuff like that might interfere
>>> with work.
>
> As long as it is the opera process that eats memory, the X driver
> shouldn't matter.  It is possible that changing the driver (or running
> compiz) will to some extent change the code paths taken in opera, but I
> think it's unlikely to affect the problem significantly.
>
>>> I have a AMD 64-bit system that's "headless" (i.e., I run the standard
>>> Ubuntu GNOME desktop on it, but only thru XVnc server), I could maybe
>>> move over one of the saved session files and run thru that, I guess.
>
> Given that it seems to be a rather uncommon problem, I'm not sure that
> would tell us much, though.  It's changing too many things at once :)
>
> eirik
>
> --
> Opera-Linux: https://list.opera.com/mailman/listinfo/opera-linux
> More lists: https://list.opera.com/mailman/listinfo/
> Unsubscribe: mailto:opera-linux-request at opera.com?subject=unsubscribe
>