On Tue, 5 Dec 2017, Ewen Chan wrote:
I'm a little bit confused by your reply here.
X is a network protocol, so it can be used to render to a remote display.
ssh -Y performs the forwarding over the tunnel.
However, in practice the forwarding only works for applications with
modest interface, like a gnome control panel or, better, xterm. firefox
pushes it already and any computer-aided design GL program is unlikely to
work well over it.
The main reason is not so much network bandwidth, but rather latency -
there are lots of calls that need a reply back and this slows down
rendering. Routing calls over ssh makes the issues worse.
On top of that network forwarding of GL calls does not use hardware
renderer - last time I checked, which was a while ago. So you should just
not ever do it. Use Xvnc if you must, but only for relatively simple GL
apps because Xvnc does software rendering.
For a non-GL app, you also have an option to Xvnc and this is better
because the app would still be there if the network connection is broken -
which could happen in out-of-memory condition.
The nice thing about trying Xvnc is that it is a separate Xserver and it
does not need Xorg running.
best
Vladimir Dergachev
If it doesn't rely on GL, can you please help clarify why would I want to use
Xvnc instead?
(Was that suppose to be "If it DOES (rely on GL), to use Xvnc instead"?)
Thanks.
On Tue, Dec 5, 2017 at 7:17 PM, Vladimir Dergachev <volo...@mindspring.com>
wrote:
On Tue, 5 Dec 2017, Ewen Chan wrote:
Not really sure.
Someone suggested that I tried Xvfb but I didn't really know how I
can use that without using an X server already, and again, in trying to conduct
my own due
diligence research into the
issue, I stumbled upon using ssh -Y and enabling X11 forwarding via
ssh so I will have to see how that works next (unless there are other
suggestions that come
before that that I can also
quickly test out as well).
If your app relies on GL you don't want to use ssh -Y.
If it does not, then I recommend running it in Xvnc instead.
best
Vladimir Dergachev
Thanks.
On Tue, Dec 5, 2017 at 6:36 PM, Vladimir Dergachev
<volo...@mindspring.com> wrote:
Also, given the the high usage does not happen outside of
gnome session, perhaps this is connected to compositing..
best
Vladimir Dergachev
On Wed, 6 Dec 2017, Hi-Angel 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
_______________________________________________
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
