Memory usage with Xorg on the thin clients
Tue, 2007.05.15 - 09:59 — müzso
Yesterday I've experienced something on my thin client for the first time: the screen froze, but the box was still running. I had lock ups previously, but then I could not ping it or ssh into the client. To cut things short: it ran out of memory and the kernel killed Xorg completely to keep things running.
The freeze came, when I was watching a full-screen slideshow of an image gallery on my website (it's done with some JavaScript magic ... you could say it's AJAX
). After a couple of images (between 10 and 15) the screen froze ... it was showing the browser and the last image that was displayed, but nothing was responding (neither the keyboard nor the mouse). I could ssh into the client and saw that there was plenty of free memory ... but Xorg was not running. Starting up X with
The reason behind all this is that some applications (like Firefox and Konqueror) force the client's X server to cache images. So my slideshow in Firefox has kept all displayed images in the thin client's memory.
I've found with a bit of googling that unfortunately there're quite some applications that do things this way. However Opera does not (or at least v9.20 since I tested on that one)! I could watch the full slideshow (the same that killed Xorg after 10-20 images in Firefox and Konqueror) in Opera with an almost constant memory usage during the whole session! Of course raising the swap space helps somewhat, but viewing a gallery of 400 images in Firefox would need something like 512MB swap for the thin client. 
I do not understand why Firefox and Konqueror fail like this and I'm quite sad since FF is my number one choice for a browser. It might be necessary to switch to something else on the thin clients though.
Btw. check out this page for a decent article on analyzing memory usage on Linux. It talks about a tool called exmap which I didn't know yet. You should also take a look at the
The freeze came, when I was watching a full-screen slideshow of an image gallery on my website (it's done with some JavaScript magic ... you could say it's AJAX
). After a couple of images (between 10 and 15) the screen froze ... it was showing the browser and the last image that was displayed, but nothing was responding (neither the keyboard nor the mouse). I could ssh into the client and saw that there was plenty of free memory ... but Xorg was not running. Starting up X with openvt /usr/lib/ltsp/screen.d/startx did bring the GUI back ... of course with the login screen and not my killed session.The reason behind all this is that some applications (like Firefox and Konqueror) force the client's X server to cache images. So my slideshow in Firefox has kept all displayed images in the thin client's memory.
I've found with a bit of googling that unfortunately there're quite some applications that do things this way. However Opera does not (or at least v9.20 since I tested on that one)! I could watch the full slideshow (the same that killed Xorg after 10-20 images in Firefox and Konqueror) in Opera with an almost constant memory usage during the whole session! Of course raising the swap space helps somewhat, but viewing a gallery of 400 images in Firefox would need something like 512MB swap for the thin client. I do not understand why Firefox and Konqueror fail like this and I'm quite sad since FF is my number one choice for a browser. It might be necessary to switch to something else on the thin clients though.
Btw. check out this page for a decent article on analyzing memory usage on Linux. It talks about a tool called exmap which I didn't know yet. You should also take a look at the
xrestop tool too. You can use it to monitor resource allocation (eg. pixmaps) in X servers.
All of my own contents here (if not noted otherwise) are licensed under the
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License. My posts reflect my personal opinion and shall not be associated with any of my employers.
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License. My posts reflect my personal opinion and shall not be associated with any of my employers.
Comments
I think you are blaming the
First, I think killing applications is by no means an acceptable strategy for desperate memory handling. Welcome to the wonderful world of Linux.
Second, Firefox and Konqueror do the right thing. Opera doesn't. If you don't want backing store in your X server, start it with the "-bs" option.
Re: I think
I agree. If the X server cannot allocate more memory for application windows (etc.), then the requests (opening a new window, loading a new image, etc.) should simply fail. The same for the kernel: if there's no free memory, then requests for new allocations should be denied and not existing applications should be killed.
I wonder whether we can change this behaviour with a kernel (compile-time) option or some /proc/* variable?
"Second, Firefox and Konqueror do the right thing. Opera doesn't. If you don't want backing store in your X server, start it with the "-bs" option."
OK. But what if I already do not have a backing store in my X server?
From my Xorg's log file:
(==) NSC(0): Backing store disabledThe "(==)" means that this is a default behaviour and not caused by a config parameter.
Hm, wrong track then. About
mem/swap