Keep in mind that Xorg will show memory usage from mapping graphics
memory.. which could be large on your card.
Also, are you using CUDA ?
best
Vladimir Dergachev
On Wed, 6 Dec 2017, Hi-Angel wrote:
Oh, wow, this looks like a Xorg bug then. I'd recommend trying latest Xorg then
— yours one is 3 years old, hopefully it's something fixed. If it won't help,
I'd recommend report a bug.
Although ulimit workaround worth a try, but If this is really a memory leak, I
doubt it'd help much. What I think would happen is that Xorg won't be able to
allocate resources on apps'
behalf, making apps to crash.
On 6 December 2017 at 00:49, Ewen Chan <chan.e...@gmail.com> wrote:
Thank you, Hi-Angel.
I thought so too originally, but when I am launching the analysis via a
terminal on the console (or even via ssh from cygwin into the system) and it is
still exhibiting the same
behaviour despite the fact that there isn't any graphical component running
beyond just runlevel 5 (and having GNOME running on X), issuing the ps aux
command shows Xorg being the
culprit for the high memory consumption.
In trying to perform the forensic analysis, I would think that it would be true
if there is a graphic component that's actually running, but there isn't
(beyond runlevel
5/GNOME-on-X).
X is supposed to release the memory back into the available pool, but it
doesn't -- it just keeps increasing.
So even after the application has terminated, if X doesn't release the memory
back, then ps aux will show X as being the process that's holding the memory.
Again, the idea of providing the first link was to limit how much RAM can X use
for the caching/retention (using ulimit -m somehow and editing
/etc/security/limits.conf) and I raised
the question (on the SLES forum) how would I know what I should set the limit
at? Too low and it will crash often. Too high, and I am back to this current
problem that I am
experiencing now.
[IMAGE]
(sorry that the output of xrestop above is a screenshot because I am twice
remotely logged in (first to home system and then again via the IPMI to the
console).)
xrestop only shows about 22 MiB.
ps aux | grep Xorg is still showing about 100 GiB tied to the Xorg process.
Thanks.
Sincerely,
Ewen
On Tue, Dec 5, 2017 at 4:28 PM, Hi-Angel <hiangel...@gmail.com> wrote:
The troubleshooting link you provided states that the high memory
usage typically belongs to some other application. Sorry, I am just an
occasional bystander here, and can't tell much of technical details,
but I imagine it works like this(I hope someone will correct me on
details): an app requests, for example, a glx object, and XServer
allocates one. When the app is done with the object, it requests
XServer to deallocate it. The point is: although this memory accounted
on part of XServer process — it is actually owned by the app. The link
also states that you can use `xrestop` application to see the owners
and amounts of the memory.
On 5 December 2017 at 21:14, Ewen Chan <chan.e...@gmail.com> wrote:
> To Whom It May Concern:
>
> Hello everybody. My name is Ewen and I am new to this distribution list.
>
> So let me start with a little bit of background and the problem
statement of
> what I am seeing/encountering.
>
> I am running a SuperMicro Server 6027TR-HTRF
> (https://www.supermicro.com/products/system/2u/6027/sys-6027tr-htrf.cfm)
> (which uses a Matrox G200eW graphics chip and it has four half-width
nodes,
> each node has two processor, each processor is an Intel Xeon E5-2690
(v1)
> (8-core, 2.9 GHz stock, HTT disabled) running SuSE Linux Enterprise
Server
> 12 SP1 (SLES 12 SP1).
>
> Here are some of the outputs from the system:
>
> ewen@aes4:~> X -version
>
> X.Org X Server 1.15.2
> Release Date: 2014-06-27
> X Protocol Version 11, Revision 0
> Build Operating System: openSUSE SUSE LINUX
> Current Operating System: Linux aes4 3.12.49-11-default #1 SMP Wed Nov
11
> 20:52:43 UTC 2015 (8d714a0) x86_64
> Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.49-11-default
> root=UUID=fc4dcdb9-2468-422c-b29f-8da42fd7dec0
> resume=/dev/disk/by-uuid/1d5d8a9c-218e-4b66-b094-f5154ab08434
splash=silent
> quit showopts crashkernel=123M,high crashkernel=72M,low
> Build Date: 12 November 2015 01:23:55AM
>
> Current version of pixman: 0.32.6
> Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> ewen@aes4:~> uname -a
> Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015
(8d714a0)
> x86_64 x86_64 x86_64 GNU/Linux
>
> The problem that I am having is that I am running a CAE analysis
application
> and during the course of the run, X will eventually consume close to
100 GiB
> of RAM (out of 125 GiB installed)
>
> ewen@aes4:~> date
> Tue Dec 5 05:08:28 EST 2017
> ewen@aes4:~> ps aux | grep Xorg
> root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 1078:19
/usr/bin/Xorg
> :0 -background none -verbose -auth /run/gdm/aut
> h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
> ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep --color=auto Xorg
>
> This does not occur when I perform the same analysis in runlevel 3 and
when
> I switch back to runlevel 5 and I am using GNOME for the desktop
> environment, regardless of whether I initiate the analysis via a
Terminal
> inside GNOME or I ssh into the system (via cygwin from a Windows box),
the
> host server's X memory usage will continually increase as the analysis
> progresses.
>
> In trying to research this issue, I have found that I can either
restrict
> the amount of cache that X does via ulimit -m (Source:
> https://wiki.ubuntu.com/X/Troubleshooting/HighMemory) or I can edit
> xorg.conf by adding this option:
>
> Option "XaaNoPixmapCache"
>
> (Source:
https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml)
>
> Would that be the recommended solution to the problem that I am
experiencing
> with X?
>
> A couple of other notes:
>
> ewen@aes4:~> free -g
> total used free shared buffers
cached
> Mem: 125 125 0 0 0
3
> -/+ buffers/cache: 122 3
> Swap: 256 170 85
> ewen@aes4:~> cat /proc/sys/vm/vfs_cache_pressure
> 200
>
> Your help and commentary would be greatly appreciated. Thank you.
>
> Sincerely,
>
> Ewen Chan
>
> _______________________________________________
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
