Cinnamon 2.4 / 17.1RC memory behaviour

[brownsr]

The Cinnamon process is growing in memory use over time. Here are some initial memory observations for this process. The measurements below are done using a simple readout from the supplied system monitor. The desktop has been stripped down to a minimum to remove potential causes - a static background, no startup apps at all, no 3rd party applets, but I will admit to a custom theme ;-) There was no connectivity - no physical connections, no bluetooth applet, and wifi turned off in the computer by a hardware switch. I did not touch the keyboard at all in the first set of measurements other than to launch the monitor, so there were no external events that should have been affecting Cinnamon at all. Memory measurements in MB

startup 73.3 (I launched the monitor by hand as quickly as I could after startup) rising to 83.5 2 or 3 seconds later 84.6 +53 seconds 84.7 +40 secs more From this point on I just recorded the running time 84.8 1:30 84.9 2:06 85 2:27 85.1 3:16 85.2 3:50 85.3 4:15 85.4 4:37 86.5 5:15 86.6 5:30

at this point I turned the hardware wireless switch on memory rose from 86.6 to 94.8 immediately then I recorded 98.4 and 101.6 in the first 10 secs after turning the switch on further readings of 101.6, 101.7, 102.4 in the next 10 secs stabilising at about 105.1

at this point I turned the hardware wireless switch off, memory remained stable at 105.1, so the memory used in the wireless connection setup was not returned

I turned on the update manager. This was the first time I had touched the keyboard after launching the monitor. Memory rose from 105.6 to 106.7, and fell back again to 105.6 after around 20 seconds. (No searching for updates etc., just launch of the program.)

At this point I realised that although I had turned off the bluetooth app, I had not actually turned bluetooth off. I turned bluetooth off and rebooted and took another series of measurements:

startup 73.8 quickly rising to 85 after 2-3 secs or so 85.1 1:59 85.2 2:32 85.2 3:07 85.3 3:30 85.4 4:06 85.5 4:48 86.5 4:54 86.6 5:27

So tentatively it would appear that there is something kicking in shortly after the desktop displays that is eating up 11-12 MB, a slow and gradual increase of around 1-200K per minute without any obvious event based cause, something kicking in around 5min or so that uses up about 1MB, and then there is an event based use of around 20MB when initiating a subsequent wireless connection that does not come back when closing the connection. Bluetooth being turned on did not have any obvious effect. Launch of the update manager did not have any obvious effect.

[ghost]

@vpal: I'm against the current architecture, but this is on that way because the main support of Gnome Shell and Cinnamon is provided by Firefox and the Firefox design is on that way (i think thats this is ok to firefox, but not for a desktop), because the graphical componentes don't support multitheradings (or at less this the justification).

Anyway as @dalcde say and about this specific problematic of memory, this is not a big problem. What could be a problem, speaking about memory, is the need of restart the whole desktop, for an specific memory issue of one application, not more than that (the sum of memory, will be the same).

I don't think that is a security risk if the extension, aplets and desklets, will be installed with root permissions (will be a user decision on that case), but currently not occurs on thats way(true).

Speaking about performance, stability and when a user is disturbed by a problem that is not cinnamon (is an external app), yes, is a problem.

[dalcde]

@vpal true, but installing an FF plugin will certainly increase the memory consumption of FF! (well, probably, but you get the idea) What we can do is probably to improve our garbage collection mechanism (which is HARD).

@letscape I think most, if not all, devs are against the current architecture. But that's not an easy thing to fix...

[vpal]

@dalcde I think it is a big mistake to compare a DE to a browser. I expect FF to be kind of unstable in some aspects as it is written to consume the "Internet", purely written JS code not well formatted HTML, a lot of plugins like Flash, etc. And it is not just FF but all the browsers on the market. A browser is by design something that I restart now and then to decrease memory consumption or even CPU usage. And mostly I can do that without any additional penalty as it returns to the state where it was. At the time being it can't even be different as a browser implementation is determined by the content on the Internet. On the other hand I would expect from a DE to be rock stable. I would like to use a DE with just suspending my laptop for months and not restarting the OS or the DE without any issues. Restarting a DE is much more painful than restarting a browser. Additionally if a browser crashes there happens nothing, I restart it and get where I was. As opposed to this when a DE crashes I have lost all my unsaved work, all the running apps and the state of them, my SSH key unlocked, my SSH sessions, etc., etc. And a DE has the opportunity to be stable as it does not have to consume things like a browser.

I think misconceptions like comparing DEs to browsers may very well lead to situations like this where plugins run inside a DE. And I think that the fact that users are used to unstable browsers does not mean that they should get used to unstable DEs.

[dalcde]

I was referring to the technical aspects of plugins. That's how plugins work. Even if we loaded them externally, it doesn't help. You're just consuming a whole lot of memory somewhere else. It doesn't make a difference whether the memory is consumed under the name of "cinnamon".

Additionally, if an external application ends up using to much memory or other system resources, it WILL cause your system to crash, even if it is not the DE. To illustrate this, running the following command on the terminal (under a default linux setup) will cause your computer to freeze and hang. I did warn you it is going to brake your computer

:(){ :|:& };:

High consumption will lead to unstable desktop regardless of whether it is by the DE.

There are things devs can do, and will do, to help with the problem, but loading extensions externally isn't the solution.

[vpal]

@dalcde "You're just consuming a whole lot of memory somewhere else. It doesn't make a difference whether the memory is consumed under the name of "cinnamon"."

I think you are wrong here. Just one simple thought, how easy is it to determine what consumes memory when the plugin is run as an external process? And how easy is it when it runs inside Cinnamon? And you can ask more similar questions like this and it will turn out that separating things has a lot of advantages. As an extreme example for me it really makes a difference if for example the "init" process is leaking that I'm not able to restart easily of FF that I am... One causes an unstable system the other an instable application, and those are not the same.

Don't get me wrong there is no way I would try to convince the Cinnamon developers that they should rewrite Cinnamon to run the plugins as separate processes. I'm just saying that my opinion is that running plugins "internally" has a lot of disadvantages like potentially making something unstable and making debugging also much harder (it is very hard to say here if Cinnamon or one of the plugins is leaking), etc.

I would like to end this discussion here and sorry for hijacking this thread so far.

[tyler71]

I've been running for 3 days, 10 hours (frequent suspends) and my memory is now staying at 162mb. Was something fixed? I've been updating without really paying attention. Hmm.. Running my while xeyes loop raised the memory about .3mb and is stayed steady - https://github.com/linuxmint/Cinnamon/issues/3690#issuecomment-71144730 at 160mb Then running it again jumped the memory .5mb every couple of seconds (sometimes 2mb at a time!) for a total of 22mb before leveling off.

With a restart of cinnamon in between each run and repeating the above.. gains of - 21, 25, 23. This is much better then increasing to 600mb (or more)!

Hopefully this is useful. This has been a issue for me since when cinnamon reached > 500mb, cinnamon started acting weird.

expo & scale would spaz out and lock me in it (couldn't exit out) my keyboard would randomly stop working when resuming from suspend, the background would spaz out and reset to some really old wallpaper.

[mtwebster]

If external programs (like a music player, or LibreOffice) are causing jumps in cinnamon's memory usage, which don't go away when said program is closed, then there could be a memory leak somewhere in Cinnamon. It is, however, natural to have a slight increase in the process's usage when opening any programs - there are frames to draw, compositing to perform, etc... except in certain situations, you're not necessarily seeing that app's true window on the screen, you're seeing a clone of sorts, a viewport to it.

It is technically impossible at this time to run applets, extensions, and desklets in their own isolated memory space. They are loaded, they become part of Cinnamon, part of its javascript 'loop' - the are 'monkey-patched' in, so-to-speak. This is how it works in gnome-shell as well by the way. We as developers need to be careful, and so do applet developers, to be sure we follow good practices, and release resources appropriately, that won't get automagically released when you're done with them. This frequently changes due to the fact that we don't 'own' the javascript engine - we have a bindings package (cjs) that makes our javascript able to work well with the underlying graphics and other libraries we're using (clutter, gtk, glib, etc..). Things that were no issue in the past may suddenly become issues suddenly because you upgraded these underlying packages, but our bindings weren't updated. Problems like this are a good example of why we decided to stick to an LTS/stable distribution base - so we could establish a baseline behavior, and not suffer regressions for an extended period of time.

The fact that Cinnamon and its extensions runs under a single process is not really possible to change at this time, without a great deal of hackery and shenanigans, that would ultimately cause more problems then it solves, trust me.

Also trust me when I say, these issues are never far from our mind when fixing, refactoring, implementing features and the like - you may not see it in these threads, but discussion is constantly being had - is this safe to do in our process? Should we offload X or Y utility stuff to cinnamon-settings-daemon? (which does run in its own thread).

Additionally, we've discussed taking all of the old (largely un-supported) applets on Spices, and collecting them on github, to be fixed, updated, and basically brought up-to-snuff with the current state of affairs, and republished. Hopefully we can attract new or existing current developers to 'adopt' some of these applets, and possibly eliminate the apparent surfeit of nearly-identical applets that people have copied and re-published over the past couple of years. Hopefully we can implement this relatively soon - it would go a long way towards eliminating unknowns when trying to troubleshoot users' issues if we were comfortable that the 3rd party stuff they're using was reasonably sane.

[collinss]

@mtwebster Just a friendly suggestion here: It might be a good idea to add what you said in the second paragraph (about the 'good practices') to the applets tutorial on the spices website (which could benefit from a major update btw). I didn't know that stuff when I first started developing applets, and I imagine most (if not all) other new applet developers are in the same boat. It might help prevent a few of these problems in the future. :)

[ghost]

I know that is not possible solve the problem, but gtk2 also not support multihreading (they separate things, like mate). So, i think that is possible separate the cinnamon in 3 process, and try that external things will run on the less important one. Thats will help to not crash cinnamon as a whole, just the one process, that could be rescued inside cinnamon main process. One possibility is the cinnamon main process, another for panels and applets and another for desklets. The extensions will be the most problematics. And need to be decided if popup menu will run over the desklet process or what doing with this. This ofcourse will not resolve the problem, just will be more easy to find problems.

[brownsr]

Minded to close this shortly - memory performance is now well behaved for me, and it feels like this thread has run its course in terms of specific actionable information

[ghost]

For me now is ok too...

[rickyzhang82]

Finding 3rd party applets are memory leak culprits doesn't help the situation here (assuming they are not scapegoat). Unless cinnamon dev team suggest me quit using 3rd party applets, we need a solution instead of offensive and defensive comments, or even close the issue in a premature way and pretend nothing happens.

If the stability of system relies on good practice of application developer, we have to admit there is a design flaw in the system.

[glebihan]

@rickyzhang82 : have you not read any of the posts in that thread ? If there is indeed still a memory issue, then more information for TROUBLESHOOTING purpose is needed. Disabling third-party applets is a way to possibly detect where the memory leak exists.

If no one here can (or wants) to provide useful information that could help solve this issue (as it was asked countless times now), then there's no point in keeping it opened.

[tyler71]

I agree with brownsr and lestcape. Cinnamon memory seems to be regulating itself now for me. I'm curious (if it was identified) what the issue was - but it's not critical info.

[dalcde]

@rickyzhang82 Also, if the stability of a system relies on good practice of application developer, it is not a design flaw. It is because IT IS A SYSTEM! According to your logic, since the fork bomb I mentioned above can take down your whole system, the linux kernel has a design flaw!

With that said, there are things Cinnamon devs CAN do to lessen the impact of third party applets (we can't solve it completely - if an applet decides to launch a fork bomb, we are doomed anyway). That is done by users providing feedback on what extensions cause the memory leaks, so Cinnamon devs can see what the extensions are doing to eat memory, and then perhaps improve our memory management system.

[brownsr]

Closing now.

[NeoGeo64]

I hope everyone got something out of this. I love Mint!

[ghost]

I don't know what think the devs, but on my opinion the most disturbed person are who more loved the things... The fact is that this is a development site, and not a place to to share the fury. We are human all's, not machines, and i consider that this is normal. Any way, the problem was fixed and in the conversation not apported any more to the original problem. If someone considered that there are more things to speak and this would help devs, can open a new thread.

[gregsheremeta]

I was experiencing a similar memory leak on Fedora 20 / Cinnamon 2.4.x -- cinnamon would grow to 2GB + in about a day. I upgraded to cinnamon 2.4.6-1.fc20 and all seems fixed.