In povray.unoffical.patches, In early November I picked up a severe 
performance issue with the preview feature and SDL2.0:

"Performance issue with preview and sdl2.0."

True, I guess, except the severity appears to be tangled in the fact the 
Ubuntu 20.4.1 Gnome desktop is leaking memory over time. This leak 
apparently a known issue for which I'm having to reboot Ubuntu about 
every 10-12 days or so - lest I start to swap. :-(

I've not gotten any of the suggested gnome restart patches to work in 
the sense of actually returning leaked memory. I don't understand enough 
about the desktop to understand why or why not. Maybe it's not Gnome, or 
just Gnome, leaking...

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I've not gotten any of the suggested gnome restart patches to work in
> the sense of actually returning leaked memory. I don't understand enough
> about the desktop to understand why or why not. Maybe it's not Gnome, or
> just Gnome, leaking...

and running something else temporarily (eg 'xfce') is not an option?


regards, jr.

Post a reply to this message

On 12/10/20 12:39 PM, jr wrote:
> hi,
> 
...
> 
> and running something else temporarily (eg 'xfce') is not an option?
> 

I suppose it and other desktops are an option...

My desktop initialization, though, isn't simple. Fifty eight placed 
terminals(1) over 4 work spaces / activities on two monitors. I'm unsure 
how easily/well the set up would map to another desktop.

Aside: I suspect the Gnome memory leak might not be a true leak (why 
it's been hanging around for so long), but caching set ups like mine for 
fancy effects to be fast.

I'm not sure, but once in a while I hit some key - by accident - which 
puts all those windows on my primary screen in miniature. It seems like 
I often notice the buff/cache memory is as large as my real memory after 
this happens. Once all my real memory is assigned to that buffer 
memory(2), I start to page.

(1) I'm using the gnome terminal and switching to uxterm/xterm an option 
I could try too. The gnome terminal has gotten pretty heavy - now has 
tabbing into virtual xterms inside the gnome terminal - which I'm not 
using/trying as it's not the set up I'm used to using. It might be those 
options with fewer actual terminals open would use less resource, but 
they are less standard, and I hesitate to get used to them.

(2) The buffer memory value as shown by top I don't completely 
understand. The ram disk consumed is included there, but it's now 
obvious other things - not memory mapped files - can make use of this 
buffer space too, but I can't yet "find" that related to Gnome. Not sure 
how to completely see the buffer memory and what applications are it.

...All this me thinking aloud for little or no benefit to anyone here I 
expect. :-)

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/10/20 12:39 PM, jr wrote:

> ...
> (1) I'm using the gnome terminal and switching to uxterm/xterm an option
> I could try too. The gnome terminal has gotten pretty heavy - now has
> tabbing into virtual xterms inside the gnome terminal - which I'm not
> using/trying as it's not the set up I'm used to using. It might be those
> options with fewer actual terminals open would use less resource, but
> they are less standard, and I hesitate to get used to them.
>
> (2) The buffer memory value as shown by top I don't completely
> understand. The ram disk consumed is included there, but it's now
> obvious other things - not memory mapped files - can make use of this
> buffer space too, but I can't yet "find" that related to Gnome. Not sure
> how to completely see the buffer memory and what applications are it.

have a look at '/usr/src/linux/Documentation/sysctl/vm.txt'.  thinking that some
of the settings may be of use (eg admin_reserve_kbytes, overcommit_memory, the
cache stuff).

> > and running something else temporarily (eg 'xfce') is not an option?
>
> I suppose it and other desktops are an option...
>
> My desktop initialization, though, isn't simple. Fifty eight placed
> terminals(1) over 4 work spaces / activities on two monitors. I'm unsure
> how easily/well the set up would map to another desktop.

sticking my neck out -- the majority of those terminals will 'ssh' sessions?  in
which case, if you're not familiar/having considered already, a single (u)xterm
running screen(1) could take care of those.  v convenient ime, detachable
sessions etc, "old" s/ware, ie stable.

(six "virtual" desktops, here.  nowhere near as many terminal session though
:-))

> ...All this me thinking aloud for little or no benefit to anyone here I
> expect. :-)

am somewhat interested because I've enabled the pre-installed Linux VM on the
Chromebook, and that is Debian/Ubuntu, though no gnome desktop.


regards, jr.

Post a reply to this message

On 12/11/20 9:53 AM, jr wrote:
...
>> buffer space too, but I can't yet "find" that related to Gnome. Not sure
>> how to completely see the buffer memory and what applications are it.
> 
> have a look at '/usr/src/linux/Documentation/sysctl/vm.txt'.  thinking that some
> of the settings may be of use (eg admin_reserve_kbytes, overcommit_memory, the
> cache stuff).
> 

Thank you - a place to start.

...
> 
> sticking my neck out -- the majority of those terminals will 'ssh' sessions?  in
> which case, if you're not familiar/having considered already, a single (u)xterm
> running screen(1) could take care of those.  v convenient ime, detachable
> sessions etc, "old" s/ware, ie stable.

Some and sometimes more, sometimes less.

Thanks for the mention of screen! New to me, though in reading about it, 
I wonder if this not the functionality on which the Gnome terminal tabs 
lean. In any case, it looks useful - and its picked up newish 
programming ownership.

Please feel free to mention the "obvious" with me. Daily, I find 
significant gaps and errors in my knowledge... Plus, my old brain isn't 
all that good at pulling stuff to the surface these days - even when 
I've run across it at some past point!
...
> am somewhat interested because I've enabled the pre-installed Linux VM on the
> Chromebook, and that is Debian/Ubuntu, though no gnome desktop.

I'm interested in your experiences with the linux VM on a Chromebook. 
The latter relatively cheap, and I've been without a workable laptop 
capable of POV-Ray / povr hacking for a long time.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/11/20 9:53 AM, jr wrote:
> ...
> >> buffer space too, but I can't yet "find" that related to Gnome. Not sure
> >> how to completely see the buffer memory and what applications are it.
> >
> > have a look at ...
>
> Thank you - a place to start.

an other "obvious" place to get info is '/proc/$$/'  ('man 5 proc').

> > sticking my neck out -- the majority of those terminals will 'ssh' sessions?  in
> > which case, if you're not familiar/having considered already, a single (u)xterm
> > running screen(1) could take care of those.  v convenient ime, detachable
> > sessions etc, "old" s/ware, ie stable.
>
> Some and sometimes more, sometimes less.
>
> Thanks for the mention of screen! New to me, though in reading about it,
> I wonder if this not the functionality on which the Gnome terminal tabs
> lean. In any case, it looks useful - and its picked up newish
> programming ownership.

it's worth (imo) spending time setting up the '~/.screenrc' with "comfortable"
defaults and key-combos, etc.

> Please feel free to mention the "obvious" with me. Daily, I find
> significant gaps and errors in my knowledge... Plus, my old brain isn't
> all that good at pulling stuff to the surface these days - even when
> I've run across it at some past point!

heh, self struggles to stay lucid.  :-)

> > am somewhat interested because I've enabled the pre-installed Linux VM on the
> > Chromebook, and that is Debian/Ubuntu, though no gnome desktop.
>
> I'm interested in your experiences with the linux VM on a Chromebook.
> The latter relatively cheap, and I've been without a workable laptop
> capable of POV-Ray / povr hacking for a long time.

go for it!  only proviso, afaik, the VM requires an Intel-based Chromebook; I'm
using an ASUS C301 (bought Jun 2018).  got POV-Ray 3.7.0.8 via 'apt-get',
working fine.  Tcl, SQLite3, etc, all work, although I've run into trouble with
a Tk script which lists available/installed fonts.  X Windows windows just
appear on the desktop.

the only "problem" I have is that the VM is invisble to my LAN router, it runs
in a container managed by Google's foo.  but the user's HOME shows in the file
manager, and so I can copy to/from the SAMBA server.  would like the VM to have
a '192.168.0.x' address, but dare not touch that stuff at the moment.


regards, jr.

Post a reply to this message

On 12/10/20 10:40 AM, William F Pokorny wrote:
> In povray.unoffical.patches, In early November I picked up a severe 
> performance issue with the preview feature and SDL2.0:
> 
> "Performance issue with preview and sdl2.0."
> 
> True, I guess, except the severity appears to be tangled in the fact the 
> Ubuntu 20.4.1 Gnome desktop is leaking memory over time. ...

An update. Playing with uxterms, watching /proc/meminfo over time... 
Thanks jr for the pointers. (The uxterms reduce the initial memory 
footprint)

Then, two days ago I hit the awful slowdown swapping windows, doing 
window / desktop stuff - while I still had 4GB plus free... Maybe more 
of a local gnome memory space filling or non linear algorithmic behavior 
apparent after time???

When it happened, I noticed I had a hanging empty desktop as was true on 
some of the other painful slowdowns too - easy to create by paging one 
workspace too far. So...

I found and installed a gnome-tweaks tool. Moved from dynamic desktops 
to 4 static ones and turned off animations. A hope it helps...

I also dug up the method to force the freeing of file buffering related 
memory the next time I see the slow down. It's apparent now most of the 
buff/cache consumption at any given time is file related. It also sunk 
in I was seeing previously "memory paging" - not necessarily swapping to 
and from the disk swap space - though some swap was consumed at the 
time. Wondering now if this activity was at all related to the Gnome 
slow down or just something which happened to be going on at the same time.

FWIW.

Bill P.

Post a reply to this message