[opensuse] Thunderbird does seem slugish (rantish)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Well, here I am with a big desktop new computer. I have 32 gigs of ram, an AMD Ryzen 5 3600X 6-Core Processor, a Radeon RX 580 graphics card, and after 8 days of use Thunderbird does seem sluggish. top output: top - 22:19:26 up 8 days, 11:12, 2 users, load average: 1,63, 1,44, 0,83 Tasks: 575 total, 1 running, 573 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,6 us, 0,2 sy, 0,0 ni, 99,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 2216932 free, 13011280 used, 17648500 buff/cache KiB Swap: 10485760+total, 10453939+free, 318208 used. 18559720 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5234 cer 20 0 7705532 4,235g 163400 0 D 2,985 13,51 376:07.07 thunderbird-bin As you can see, Th is using the absurd amount of 4.2 gigs of ram. Not a problem, I have lots of it - but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted. Conclusion: Thunderbird is indeed slow and a memory hog. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXrhjThwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVXfkAn3Z/ZP7/Zh49jIE3V/x6 fO/PWMtqAJ4hdeyD84vOrYQd2Zp+MBhDHqZuHA== =WIPg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/05/2020 22:25, Carlos E. R. wrote:
Well, here I am with a big desktop new computer. I have 32 gigs of ram, an AMD Ryzen 5 3600X 6-Core Processor, a Radeon RX 580 graphics card, and after 8 days of use Thunderbird does seem sluggish.
top output:
top - 22:19:26 up 8 days, 11:12, 2 users, load average: 1,63, 1,44, 0,83 Tasks: 575 total, 1 running, 573 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,6 us, 0,2 sy, 0,0 ni, 99,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 2216932 free, 13011280 used, 17648500 buff/cache KiB Swap: 10485760+total, 10453939+free, 318208 used. 18559720 avail Mem
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND
5234 cer 20 0 7705532 4,235g 163400 0 D 2,985 13,51 376:07.07 thunderbird-bin
As you can see, Th is using the absurd amount of 4.2 gigs of ram. Not a problem, I have lots of it - but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
Conclusion: Thunderbird is indeed slow and a memory hog.
Have you copied existing mail folders into a new Thunderbird instance? It could be the indexer running through archives of mails. Or just that the indexer has got stuck in a loop. I've never had much joy with it, I turn it off because even after a few years when I gave it another shot on a new install, it seemed to cause issues. Go into Preferences -> Advanced, and uncheck Global Search and Indexer. When I need to search I can still do so from the Find -> Search Messages function. gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/05/2020 23.39, gumb wrote:
On 10/05/2020 22:25, Carlos E. R. wrote:
...
Conclusion: Thunderbird is indeed slow and a memory hog.
I forgot to mention than on start, for an hour or so, Thunderbird stays under 1 gigabyte.
Have you copied existing mail folders into a new Thunderbird instance?
Nope.
It could be the indexer running through archives of mails. Or just that the indexer has got stuck in a loop.
I tried once, then disabled it. It runs high cpu for days. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 05/10/2020 03:25 PM, Carlos E. R. wrote:
As you can see, Th is using the absurd amount of 4.2 gigs of ram. Not a problem, I have lots of it - but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
Conclusion: Thunderbird is indeed slow and a memory hog.
Both thunderbird and firefox can use obnoxious amounts of memory. It is actually by design. I don't agree with the philosophy from a programming standpoint, but I understand it is a valid choice to make. Mozilla in general approaches memory management with the philosophy of: "if it's available -- use it to speed up execution of the code". I prefer the design choice of: "optimize your memory usage, using only what is needed for the current task and the release it" The problem with the mozilla approach is with computers now coming with huge amounts of memory 16G, 32G+, the overhead to scan through all of the memory allocated and in use -- takes time, and if swap is any way involved, that can be a LOT of time. I don't know what the answer is, as I don't know how much control, if any, mozilla gives you over RAM usage. Even the control over cache size has been whittle back (which is probably due to using ever increasing amounts of RAM). I know from my recent thread of the computer appearing "locked" when allocating more than 4G of RAM to a process, that much memory can take a lot of time to scan through.... -- David C. Rankin, J.D.,P.E.
David C. Rankin wrote:
Both thunderbird and firefox can use obnoxious amounts of memory. It is actually by design. I don't agree with the philosophy from a programming standpoint, but I understand it is a valid choice to make. Mozilla in general approaches memory management with the philosophy of:
"if it's available -- use it to speed up execution of the code". [snip] The problem with the mozilla approach is with computers now coming with huge amounts of memory 16G, 32G+, the overhead to scan through all of the memory allocated and in use -- takes time, and if swap is any way involved, that can be a LOT of time.
The solution seems obvious - restrict the amount memory available for TB to abuse, make it unavailable. ISTR that being discussed already ? It's easily done with cgroups. My own TB : PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9381 per 20 0 3911224 479812 55616 S 0.000 11.90 205:57.21 thunderbird-bin (4 IMAP accounts). Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ? -- Per Jessen, Zürich (17.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 5/11/20 5:30 PM, Per Jessen wrote:
David C. Rankin wrote:
Both thunderbird and firefox can use obnoxious amounts of memory. It is actually by design. I don't agree with the philosophy from a programming standpoint, but I understand it is a valid choice to make. Mozilla in general approaches memory management with the philosophy of:
"if it's available -- use it to speed up execution of the code". [snip] The problem with the mozilla approach is with computers now coming with huge amounts of memory 16G, 32G+, the overhead to scan through all of the memory allocated and in use -- takes time, and if swap is any way involved, that can be a LOT of time.
The solution seems obvious - restrict the amount memory available for TB to abuse, make it unavailable. ISTR that being discussed already ? It's easily done with cgroups.
On my old laptop I used to do this with firefox, it was pretty simple I just ran it as a systemd user service with the cgroup stuff enabled. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 11/05/2020 10.00, Per Jessen wrote:
David C. Rankin wrote:
Both thunderbird and firefox can use obnoxious amounts of memory. It is actually by design. I don't agree with the philosophy from a programming standpoint, but I understand it is a valid choice to make. Mozilla in general approaches memory management with the philosophy of:
"if it's available -- use it to speed up execution of the code". [snip] The problem with the mozilla approach is with computers now coming with huge amounts of memory 16G, 32G+, the overhead to scan through all of the memory allocated and in use -- takes time, and if swap is any way involved, that can be a LOT of time.
The solution seems obvious - restrict the amount memory available for TB to abuse, make it unavailable. ISTR that being discussed already ? It's easily done with cgroups.
I remember we did, yes. But that time my Tw swapped, and now I have ram to spare. Previously I assumed that the sluggishness was due to having to retrieve areas from swap, when needed.
My own TB :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9381 per 20 0 3911224 479812 55616 S 0.000 11.90 205:57.21 thunderbird-bin
(4 IMAP accounts).
Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ?
Will it not simply go into swaping? You have to tell top to also display swap. Display fields (f), navigate to the swap entry, activate it, then move the column where you like. Then possibly write as default. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
My own TB :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9381 per 20 0 3911224 479812 55616 S 0.000 11.90 205:57.21 thunderbird-bin
(4 IMAP accounts).
Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ?
Will it not simply go into swaping? You have to tell top to also display swap.
Try it. In my case above, 0 swap in use. If David is right in his theory that TB basically uses available memory, and that for machines with large amounts of memory this becomes a problem, cgroups ought to fix it. -- Per Jessen, Zürich (15.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2020 12.41, Per Jessen wrote:
Carlos E. R. wrote:
My own TB :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9381 per 20 0 3911224 479812 55616 S 0.000 11.90 205:57.21 thunderbird-bin
(4 IMAP accounts).
Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ?
Will it not simply go into swaping? You have to tell top to also display swap.
Try it. In my case above, 0 swap in use.
I did try it a month or two ago, and it was not better. It began to swap earlier.
If David is right in his theory that TB basically uses available memory, and that for machines with large amounts of memory this becomes a problem, cgroups ought to fix it.
I will try again. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
On 11/05/2020 12.41, Per Jessen wrote:
Carlos E. R. wrote:
My own TB :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9381 per 20 0 3911224 479812 55616 S 0.000 11.90 205:57.21 thunderbird-bin
(4 IMAP accounts).
Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ?
Will it not simply go into swaping? You have to tell top to also display swap.
Try it. In my case above, 0 swap in use.
I did try it a month or two ago, and it was not better. It began to swap earlier.
Then I suspect it is an issue specific to your config. -- Per Jessen, Zürich (14.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2020 08:28, Per Jessen wrote:
Then I suspect it is an issue specific to your config.
Just to. I might be one thing 'debugging this' peering over your shoulder, accessing your keyboard and doing a frenzy of searches, but debug-by-email is slow and interpretation prone. It might depend, for example, not only on the add-on/plug-ins you have but how your desktop is configured or how your system is set up in a larger context. if this were me I'd take a morning out to change to a radically different desktop and run just that one application. The do it again with all the add-ons disabled. The add one other application. Early in my engineering career I had this strict 'scientific' approach knocked into me by an older, more experienced engineer when I tried taking short cuts in debugging. Short cuts, were fine, when you know which ones to take, but often in dealing with pernicious problems such as $SUBJ you don't know which one to take and you find yourself, as is the case in this thread, making unscientific wild assed speculation. At that point you have to <strike>drop back and punt</strike> become scientific and reductionist in your approach and minimise the variables. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-05-11 07:26 AM, Carlos E. R. wrote:
If David is right in his theory that TB basically uses available memory, and that for machines with large amounts of memory this becomes a problem, cgroups ought to fix it.
I will try again.
Let us know how it goes. I've never used cgroups. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2020 13.26, Carlos E. R. wrote:
On 11/05/2020 12.41, Per Jessen wrote:
Carlos E. R. wrote:
My own TB :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9381 per 20 0 3911224 479812 55616 S 0.000 11.90 205:57.21 thunderbird-bin
(4 IMAP accounts).
Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ?
Will it not simply go into swaping? You have to tell top to also display swap.
Try it. In my case above, 0 swap in use.
I did try it a month or two ago, and it was not better. It began to swap earlier.
If David is right in his theory that TB basically uses available memory, and that for machines with large amounts of memory this becomes a problem, cgroups ought to fix it.
I will try again.
The process was (retrieved from bash_history; I can't locate the email): cd /sys/fs/cgroup/memory mkdir thunderbird cd thunderbird echo 1G >memory.limit_in_bytes pidof thunderbird-bin >cgroup.procs cat memory.usage_in_bytes cat memory.max_usage_in_bytes cat memory.limit_in_bytes cat memory.usage_in_bytes memory.max_usage_in_bytes memory.limit_in_bytes cat cgroup.procs cat cgroup.procs cat tasks cat memory.usage_in_bytes memory.max_usage_in_bytes memory.limit_in_bytes cat cgroup.procs ls memor* cat memory.pressure_level cat memory.stat cat memory.swappiness Ie: Telcontar:~ # cd /sys/fs/cgroup/memory Telcontar:/sys/fs/cgroup/memory # mkdir thunderbird Telcontar:/sys/fs/cgroup/memory # cd thunderbird Telcontar:/sys/fs/cgroup/memory/thunderbird # echo 2G >memory.limit_in_bytes Telcontar:/sys/fs/cgroup/memory/thunderbird # pidof thunderbird-bin >cgroup.procs Telcontar:/sys/fs/cgroup/memory/thunderbird # cat memory.usage_in_bytes 163840 Telcontar:/sys/fs/cgroup/memory/thunderbird # cat memory.max_usage_in_bytes 442368 Telcontar:/sys/fs/cgroup/memory/thunderbird # cat memory.limit_in_bytes 2147483648 Telcontar:/sys/fs/cgroup/memory/thunderbird # cat memory.usage_in_bytes memory.max_usage_in_bytes memory.limit_in_bytes 521936896 932331520 2147483648 Telcontar:/sys/fs/cgroup/memory/thunderbird # cat cgroup.procs 5234 Telcontar:/sys/fs/cgroup/memory/thunderbird # cat memory.usage_in_bytes memory.max_usage_in_bytes memory.limit_in_bytes 521895936 932331520 2147483648 Telcontar:/sys/fs/cgroup/memory/thunderbird # cat memory.pressure_level cat: memory.pressure_level: Invalid argument Telcontar:/sys/fs/cgroup/memory/thunderbird # cat memory.stat cache 573440 rss 520839168 rss_huge 67108864 shmem 532480 mapped_file 532480 dirty 0 writeback 0 pgpgin 200866 pgpgout 89920 pgfault 201918 pgmajfault 0 inactive_anon 532480 active_anon 520810496 inactive_file 36864 active_file 4096 unevictable 0 hierarchical_memory_limit 2147483648 total_cache 573440 total_rss 520839168 total_rss_huge 67108864 total_shmem 532480 total_mapped_file 532480 total_dirty 0 total_writeback 0 total_pgpgin 200866 total_pgpgout 89920 total_pgfault 201918 total_pgmajfault 0 total_inactive_anon 532480 total_active_anon 520810496 total_inactive_file 36864 total_active_file 4096 total_unevictable 0 Telcontar:/sys/fs/cgroup/memory/thunderbird # cat memory.swappiness 60 Telcontar:/sys/fs/cgroup/memory/thunderbird # Thunderbird remains using 4 GB of memory nonetheless. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote: [after setting 1Gb memory limit with cgroups]
Thunderbird remains using 4 GB of memory nonetheless.
Try restarting it - I don't know that setting a memory limit will also automatically reduce the current usage. Regardless - keep in mind this is only to test out David's idea about TB using up as much memory as possible. Setting 1Gb will almost certainly make TB swap at some point, and probably not solve $SUBJ. -- Per Jessen, Zürich (6.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/05/2020 09.51, Per Jessen wrote:
Carlos E. R. wrote:
[after setting 1Gb memory limit with cgroups]
Thunderbird remains using 4 GB of memory nonetheless.
Try restarting it - I don't know that setting a memory limit will also automatically reduce the current usage.
I did - but because I run an update. When I limited the memory of a process using systemd tools, months ago, it did reduce the memory of the running process and sent it to swap, IIRC.
Regardless - keep in mind this is only to test out David's idea about TB using up as much memory as possible. Setting 1Gb will almost certainly make TB swap at some point, and probably not solve $SUBJ.
Ok. Limiting to 2 GiB. top - 11:12:40 up 10:20, 1 user, load average: 0,20, 0,19, 0,14 Tasks: 506 total, 1 running, 504 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,8 us, 0,2 sy, 0,2 ni, 98,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 23258724 free, 7404080 used, 2213908 buff/cache KiB Swap: 10485760+total, 10390185+free, 955736 used. 24676092 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5060 cer 39 19 7068384 2,020g 55592 0 S 0,000 6,444 19:12.84 tracker-extract 11496 cer 20 0 3763696 671800 278268 0 S 0,597 2,043 3:28.51 firefox 6788 cer 20 0 3507452 661016 137488 0 S 0,000 2,011 1:16.88 thunderbird-bin 5098 cer 39 19 1647780 529104 13784 0 S 0,000 1,609 1:28.91 tracker-miner-f Well, you see TH is using less than 700MB. I will now visit all inboxes top - 11:14:04 up 10:21, 1 user, load average: 0,30, 0,22, 0,15 Tasks: 504 total, 1 running, 502 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,6 us, 0,4 sy, 0,0 ni, 99,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 23426060 free, 7240480 used, 2210172 buff/cache KiB Swap: 10485760+total, 10390185+free, 955736 used. 24839124 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5060 cer 39 19 7068384 2,020g 55592 0 S 0,000 6,444 19:12.84 tracker-extract 11496 cer 20 0 3763696 678800 278268 0 S 0,000 2,065 3:29.53 firefox 5098 cer 39 19 1647780 529104 13784 0 S 0,299 1,609 1:28.92 tracker-miner-f 6788 cer 20 0 3508012 473324 138244 0 S 0,299 1,440 1:19.42 thunderbird-bin It's gone down to 470. I will visit now the nntp groups. top - 11:18:12 up 10:25, 1 user, load average: 0,48, 0,39, 0,23 Tasks: 509 total, 2 running, 506 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,6 us, 0,1 sy, 0,0 ni, 99,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 23434572 free, 7228560 used, 2213580 buff/cache KiB Swap: 10485760+total, 10390185+free, 955736 used. 24851016 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5060 cer 39 19 7068384 2,020g 55592 0 S 0,000 6,444 19:12.84 tracker-extract 11496 cer 20 0 3767792 688472 278268 0 S 3,582 2,094 3:32.37 firefox 5098 cer 39 19 1647780 529104 13784 0 S 0,000 1,609 1:28.94 tracker-miner-f 6788 cer 20 0 3508856 524952 138248 0 S 0,000 1,597 1:24.24 thunderbird-bin top - 11:19:15 up 10:27, 1 user, load average: 0,80, 0,47, 0,27 Tasks: 509 total, 2 running, 506 sleeping, 0 stopped, 1 zombie %Cpu(s): 2,1 us, 0,4 sy, 0,6 ni, 96,9 id, 0,1 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 23406244 free, 7245136 used, 2225332 buff/cache KiB Swap: 10485760+total, 10390185+free, 955736 used. 24826264 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5060 cer 39 19 7068384 2,020g 55592 0 S 0,000 6,444 19:12.84 tracker-extract 11496 cer 20 0 3768816 690688 278268 0 S 2,388 2,101 3:33.05 firefox 5098 cer 39 19 1647780 529104 13784 0 S 0,000 1,609 1:28.95 tracker-miner-f 6788 cer 20 0 3509184 487356 139076 0 S 6,269 1,482 1:29.42 thunderbird-bin 11976 cer 20 0 3505032 475936 153044 0 S 19,70 1,448 17:09.19 Web Content Well, it doesn't take all ram, it takes quite little, and goes up and down, not much related to my activity. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2020-05-12 at 11:23 +0200, Carlos E. R. wrote:
On 12/05/2020 09.51, Per Jessen wrote:
Carlos E. R. wrote:
Regardless - keep in mind this is only to test out David's idea about TB using up as much memory as possible. Setting 1Gb will almost certainly make TB swap at some point, and probably not solve $SUBJ.
Ok. Limiting to 2 GiB.
Well, Th got to 2 GiB, and was using some swap, but it could be because I had hibernated the machine previously. However, at somepoint while editing an email (a table in an html post), Th locked hard at 100% CPU. Removing the cgroups directory did not help, so I had to kill thunderbird. And not activate cgroups for it again. More stable. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXr5jmxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVQUEAoI4xZ27ICivvXj4WoEOv mcbKFikqAKCGaUmQrEbtgLR9AUl9R9En9VEJYg== =ilzy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/05/2020 05:40, Carlos E. R. wrote:
On Tuesday, 2020-05-12 at 11:23 +0200, Carlos E. R. wrote:
On 12/05/2020 09.51, Per Jessen wrote:
Carlos E. R. wrote:
Regardless - keep in mind this is only to test out David's idea about TB using up as much memory as possible. Setting 1Gb will almost certainly make TB swap at some point, and probably not solve $SUBJ.
Ok. Limiting to 2 GiB.
Well, Th got to 2 GiB, and was using some swap, but it could be because I had hibernated the machine previously. However, at somepoint while editing an email (a table in an html post), Th locked hard at 100% CPU. Removing the cgroups directory did not help, so I had to kill thunderbird. And not activate cgroups for it again. More stable.
Running under KDE .. TB uses about 2/3 as much virtual as FF, and 1/5 as much physical, with abut the same amount of shared. FF is using about 40% of all memory, TB about 8%. And that's without Cgroups. I have no swapping/paging going on. # swapon -s Filename Type Size Used Priority /dev/sda2 partition 5858300 0 2 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2020 12:41, Per Jessen wrote:
Carlos E. R. wrote:
My own TB :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9381 per 20 0 3911224 479812 55616 S 0.000 11.90 205:57.21 thunderbird-bin
(4 IMAP accounts).
Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ?
Will it not simply go into swaping? You have to tell top to also display swap.
Try it. In my case above, 0 swap in use.
If David is right in his theory that TB basically uses available memory, and that for machines with large amounts of memory this becomes a problem, cgroups ought to fix it.
I have Thunderbird (now 68.8 under Leap 15.1) running constantly on my laptop fitted with 32GB RAM. It's currently consuming around 200MB. I almost always have Firefox (with a couple of dozen tabs) and Dolphin (several tabs too) open, anything else is not permanent. But system memory usage rarely goes over 4GB. (Bought the laptop secondhand, I wouldn't have chosen 32GB myself, 8 would suffice for me). So anyway, it must be something about your mail accounts, overflowing mailing lists or, as I mentioned in the other reply, the indexer going crazy. gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2020-05-11 a las 14:15 +0200, gumb escribió:
On 11/05/2020 12:41, Per Jessen wrote:
Carlos E. R. wrote:
...
I have Thunderbird (now 68.8 under Leap 15.1) running constantly on my laptop fitted with 32GB RAM. It's currently consuming around 200MB. I almost always have Firefox (with a couple of dozen tabs) and Dolphin (several tabs too) open, anything else is not permanent. But system memory usage rarely goes over 4GB. (Bought the laptop secondhand, I wouldn't have chosen 32GB myself, 8 would suffice for me).
So anyway, it must be something about your mail accounts, overflowing mailing lists or, as I mentioned in the other reply, the indexer going crazy.
I do have several imap accounts, plus news (nntp). Including one local dovecot server with many folders. Th starts using 800 MB, then goes up and up over the days. I think it is memory fragmentation. - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXrlehhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVDbwAn39H492p5rY3JK5+/qCr Nag6scuRAJ9NELAwzcyRVNtEKQ/YexPqwWfL+g== =igyb -----END PGP SIGNATURE-----
On 11/05/2020 10:17, Carlos E. R. wrote:
Th starts using 800 MB, then goes up and up over the days. I think it is memory fragmentation.
If you are running on a virtual memory system that should not matter. A VM system works buy a scatter-gather layer of memory management underneath what the application sees. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2020 04:00, Per Jessen wrote:
Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ?
I don't expect so. As I've observed, I have 18 internet IMAP accounts, two Gmail accounts, fetchmail polling about a dozen accounts into my local system that Dovecot manages and indexes and that TB has two IMAP connections to, one to the 'archived (aka more than 1 year, 18 months or so old) and one to the more current and more personal (such as regular personal correspondents or finances). What delays the accessing of any single message are a) it has massive attachments that need downloading b) the heading from some individuals (such as Simon Lee) seem to take a long time to process. Often this is the DKIM signature but for Simon it is the Autocrypt line. ??WTF?? But then, consider, I work almost exclusivity in plain text, so I'm not faced with HTML rendering. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 11/05/2020 04:00, Per Jessen wrote:
Any chance the memory usage might be dependent on the setup - IMAP or POP accounts, indexing etc ?
I don't expect so.
Currently, I see no other explanation. Only Carlos is complaining about this issue, that is highly suggestive of it being a local issue. His system is a brandnew installation, that leaves little but his config or usage pattern.
What delays the accessing of any single message are a) it has massive attachments that need downloading b) the heading from some individuals (such as Simon Lee) seem to take a long time to process. Often this is the DKIM signature but for Simon it is the Autocrypt line. ??WTF??
In my case, what delays the accessing of any single message is the download over a 2400baud modem ;-) -- Per Jessen, Zürich (13.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2020 07.44, David C. Rankin wrote:
On 05/10/2020 03:25 PM, Carlos E. R. wrote:
As you can see, Th is using the absurd amount of 4.2 gigs of ram. Not a problem, I have lots of it - but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
Conclusion: Thunderbird is indeed slow and a memory hog.
Both thunderbird and firefox can use obnoxious amounts of memory. It is actually by design. I don't agree with the philosophy from a programming standpoint, but I understand it is a valid choice to make. Mozilla in general approaches memory management with the philosophy of:
"if it's available -- use it to speed up execution of the code".
This is not true when there isn't, and Th goes into swap, as it did in my previous machine. I read somewhere and time ago that it was due to memory fragmentation. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 11/05/2020 05:58, Carlos E. R. wrote:
On 11/05/2020 07.44, David C. Rankin wrote:
On 05/10/2020 03:25 PM, Carlos E. R. wrote:
As you can see, Th is using the absurd amount of 4.2 gigs of ram. Not a problem, I have lots of it - but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
Conclusion: Thunderbird is indeed slow and a memory hog.
Both thunderbird and firefox can use obnoxious amounts of memory. It is actually by design. I don't agree with the philosophy from a programming standpoint, but I understand it is a valid choice to make. Mozilla in general approaches memory management with the philosophy of:
"if it's available -- use it to speed up execution of the code".
This is not true when there isn't, and Th goes into swap, as it did in my previous machine.
I read somewhere and time ago that it was due to memory fragmentation.
The "time ago" has it. it might work for a roll-in/roll-out system ala UNIX V7 or some forms of Windows, but this is Linux and late model dual queue virtual memory we are talking about. The whole idea of swap is misnamed. the term 'swap' came from the roll-in/roll-out ways where you swapped one programme out, in its entirety, and swapped another one in, often cost you could only run one at a time in the very literal sense, the CP/M or PDP-8/DOS sense of the 'transient program area' model. But no, we are running late model Lunix with virtual memory. Paging is not the same as swapping. You can, very literally, start a program with ZERO Emory allocated. The OS context switches to the app and it tried to access the first byte of executable code and ... page fault. So the system put a [page request on the queue and that gets processed and the page brought in and the app process restarted and it immediately need to access some data and ... page fault. And so it goes. With all the processes running. All pages are on a queue somewhere so when there is no more 'free' (for some value of that according to the 40+ parameters the VM system algorithm runs under) (see /proc/sys/vm) the oldest (aka the one that has not been accessed the longest) is freed up. If that is a code page, then it is simply put on the 'available' queue, since the code can be retrieved from the FS. if it is a data page it is 'swapped out', that is paged out', that page put on the free list. Of course that is a queue-to-disk and might not happen immediately. See the parameter "vm.dirty_ratio" and "vm.dirty_background_ratio". Check your won system using cat /proc/vmstat | egrep "dirty" If you are running 'vmstat' (as I am) you can see some of this happening. PLEASE DON"T FORGET that all process ned the page allocation tables and that vm pages have to be allocated for this. Stop and think about that. Some of the TLB's get to be pretty huge! They are not going to be so readily paged! Now here comes the GOTCHA! There are exceptional conditions, so don't assume they are happening to you, where the system might, just might, decide to meld a couple of pages into a 'big page'. I'm not clear on the conditions where this can happen. big pages cannot be paged and cannot be rolled out to swap. They stay in memory so the conditions must be important. Unless, that is the application can somehow make it happen and hang onto the Big Pages. Perhaps there is an undocumented system call, a variation of 'Malloc()' or perhaps Mozilla is simply doing a 'vmalloc()' ju-jitsu to achieve that end. MAYBE. The VM system is VERY VERY configurable for those in the know. I know a bit about VM possibilities from having worked with many systems that use it from mainframes down, from having see how Bill Joy implemented it and tuned it on BSD on the VAX, how Dave Cutler worked on the DEC version and how they competed: Dave using assembler and Bill using C (and usually trouncing Dave when it cam to OS performance, particularly VM performance). I've worked 'under the hood', unofficially) with AIX and HP/UX, and seem Linux VM grow and develop. I don't claim to be an authority, but I do now about the differences, the influences and inaccuracies. in the context of this thread you might benefit from reading https://sysctl-explorer.net/vm/pagecluster/ https://sysctl-explorer.net/vm/overcommit_memory/ https://sysctl-explorer.net/vm/user_reserve_kbytes/ And of course you can use 'swappiness' to minimise some disk IO. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oops. I did not post to the list. I noticed when you replied. On Friday, 2020-05-15 at 09:28 -0400, Anton Aylward wrote:
On 11/05/2020 05:58, Carlos E. R. wrote:
On 11/05/2020 07.44, David C. Rankin wrote:
On 05/10/2020 03:25 PM, Carlos E. R. wrote:
...
And of course you can use 'swappiness' to minimise some disk IO.
You misunderstand. In this machine there is no "swapping", as it has 32 GB of puhiscal ram. However, I do use hibernation, which forces "things" into swap, which may remain in swap after thawing if they are no longer needed. Which is not the case now for thunderbird: top - 21:01:47 up 3 days, 20:09, 1 user, load average: 0,37, 0,35, 0,37 Tasks: 542 total, 2 running, 539 sleeping, 0 stopped, 1 zombie %Cpu(s): 2,3 us, 0,4 sy, 0,1 ni, 97,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 17922640 free, 10544392 used, 4409680 buff/cache KiB Swap: 10485760+total, 10349480+free, 1362788 used. 20594000 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 11496 cer 20 0 4820848 858960 326736 61240 S 2,695 2,613 66:53.50 firefox 24710 cer 20 0 4181128 855848 137252 0 S 0,299 2,603 10:39.50 thunderbird-bin 11845 cer 20 0 3932404 773160 150408 36940 S 0,599 2,352 10:24.29 Web Content 3813 vscan 20 0 1168052 711000 3936 231376 S 0,000 2,163 2:08.23 clamd As you can see, thunderbird is not using any swap, even after two or three hibernation cycles (the machine is running three days). And its memory usage is less than 900 MB, which is strange - but there was an update. So my hypothesis for today is that devs corrected some hole. However, the previous session I was limiting thunderbird to 2GB with cgroups, and it was swapping. And it locked. So I removed the cgroups limit. You can see, however, how firefox has some memory in swap - this is because of the hibernation cycles I commented. And you can see how clamd is also using swap - in this case it is because I limit its memory use with cgroups. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXr72MRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV7SMAnRKPKPikk9j3oQxirI89 vBpiwm68AJsG2UMa11ykIQfglCnY93chbGF0FQ== =XmHU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 5/11/20 5:55 AM, Carlos E. R. wrote:
Hi,
Well, here I am with a big desktop new computer. I have 32 gigs of ram, an AMD Ryzen 5 3600X 6-Core Processor, a Radeon RX 580 graphics card, and after 8 days of use Thunderbird does seem sluggish.
top output:
top - 22:19:26 up 8 days, 11:12, 2 users, load average: 1,63, 1,44, 0,83 Tasks: 575 total, 1 running, 573 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,6 us, 0,2 sy, 0,0 ni, 99,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 2216932 free, 13011280 used, 17648500 buff/cache KiB Swap: 10485760+total, 10453939+free, 318208 used. 18559720 avail Mem
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND
5234 cer 20 0 7705532 4,235g 163400 0 D 2,985 13,51 376:07.07 thunderbird-bin
As you can see, Th is using the absurd amount of 4.2 gigs of ram. Not a problem, I have lots of it - but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
Conclusion: Thunderbird is indeed slow and a memory hog.
Ram seems normal for what I see here, one thing I found that helped alot with IMAP is I filter alot of mailinglists etc and end up with a large number of unread messages, marking old emails as read then changing some of my mail rules to mark stuff as read when it puts it in a folder (if i'm unlikely to read it anyway) made a big difference for me. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 11/05/2020 09.56, Simon Lees wrote:
On 5/11/20 5:55 AM, Carlos E. R. wrote:
Hi,
...
Conclusion: Thunderbird is indeed slow and a memory hog.
Ram seems normal for what I see here, one thing I found that helped alot with IMAP is I filter alot of mailinglists etc and end up with a large number of unread messages, marking old emails as read then changing some of my mail rules to mark stuff as read when it puts it in a folder (if i'm unlikely to read it anyway) made a big difference for me.
If memory were more or less constant, I would agree. But the first hour it stays under 1 Gig, and it responds fast and snappy. Then over the days it grows and grows bigger and slower. In the end, I have to restart it. Previously, with my older machine which had "only" 8 gigs, it swapped (up to 6 gigs). So I thought that the sluggishness came from having to retrieve chunks from swap. But that is not the case now. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-05-11 06:11 AM, Carlos E. R. wrote:
If memory were more or less constant, I would agree. But the first hour it stays under 1 Gig, and it responds fast and snappy. Then over the days it grows and grows bigger and slower. In the end, I have to restart it.
This is exactly the situation I've described here several times. Killing the browsers fixes the problem temporarily, but sooner or later I have to at least log out of the desktop. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2020-05-11 a las 09:43 -0400, James Knott escribió:
On 2020-05-11 06:11 AM, Carlos E. R. wrote:
If memory were more or less constant, I would agree. But the first hour it stays under 1 Gig, and it responds fast and snappy. Then over the days it grows and grows bigger and slower. In the end, I have to restart it.
This is exactly the situation I've described here several times. Killing the browsers fixes the problem temporarily, but sooner or later I have to at least log out of the desktop.
Not exactly. In your case, you had high memory load. - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXrldRBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVQVgAnjfyqnOO9xnsnvzdMSFg 8Sg3jdArAJ9BpNTIoekptbFQurSkAC0k0u9Qmw== =Wh+2 -----END PGP SIGNATURE-----
On 2020-05-11 10:12 AM, Carlos E. R. wrote:
Not exactly. In your case, you had high memory load.
Even with low memory load. Currently, I'm at about 12 GB memory of 16 and 2.3 GB swap. A few minutes ago, it bogged down so that Amarok couldn't even properly play music, without it breaking up severely. I'd be going along, just like now, with everything going fine and then I have a lot of CPU and disk activity and extremely poor response. I have been unable to identify any specific cause, other than shutting down browsers fixes things temporarily. BTW, I have seen it with as little as about 4 MB memory usage and very little swap. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2020 16.17, James Knott wrote:
On 2020-05-11 10:12 AM, Carlos E. R. wrote:
Not exactly. In your case, you had high memory load.
Even with low memory load. Currently, I'm at about 12 GB memory of 16 and 2.3 GB swap.
And that's a difference: I don't have used swap. Your machine needs more memory for your use pattern.
A few minutes ago, it bogged down so that Amarok couldn't even properly play music, without it breaking up severely. I'd be going along, just like now, with everything going fine and then I have a lot of CPU and disk activity and extremely poor response. I have been unable to identify any specific cause, other than shutting down browsers fixes things temporarily.
I have no CPU usage, and everything responds fast, except Thunderbird after several days of use.
BTW, I have seen it with as little as about 4 MB memory usage and very little swap.
-- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On 11/05/2020 06:11, Carlos E. R. wrote:
But the first hour it stays under 1 Gig, and it responds fast and snappy. Then over the days it grows and grows bigger and slower.
That's also a characteristic of a memory leak. It maybe a simple memory leak, for example in a plug-in/add-on. Or it might be a systemic memory leak, for example in the handling of attachments and embedded imaged. The observations James makes about Firefox, also Mozilla code, make me wonder about that. Then again, if that's so, why isn't everyone suffering from this? These are also gnome-context (or GTK rather than QT context) items. Maybe its configuration there that is the problems. So many possible interactions. My point here is that this isn't happening to me; I zypper up regularly and run a KDE/plasma environment. I have 8G on a an old machine - 'lscpu' tells me Model name: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz One note: I run FF with one process, two windows. I tried moving some tabs off to a third window as an effort at 'grouping'. It absolutely killed performance, not just for FF but the whole machine. Not swapping, something else. Load factor went up from the normal <2.5 to >25 I have one xterm running 'vmstat' so I can both swap, disk IO and memory as well as CPU, and also how much of disk IO is devoted to swap. it also shows interrupts and context switches. That latter is what was alarming. I suggest that 'vmstat -SM -a 15' in an xterm will tell you more about what's going on than 'top'. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2020-05-15 at 07:08 -0400, Anton Aylward wrote:
On 11/05/2020 06:11, Carlos E. R. wrote:
...
I suggest that 'vmstat -SM -a 15' in an xterm will tell you more about what's going on than 'top'.
I tried, I find it cryptic. Telcontar:~ # vmstat -SM -a 15 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 1 0 1330 17369 2280 10992 0 0 332 146 51 38 6 1 92 0 0 0 0 1330 17477 2280 10882 0 0 0 16 3454 5955 2 0 97 0 0 1 0 1330 17461 2280 10901 0 0 0 27 3250 5629 2 0 97 0 0 What is each column? After a while, the header disapears, so I don't even have that minimal information. The header should not flow out. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXr7y4Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVlpwAniM413KNZRmuX3ecyfnI Otj78kixAKCWKN3soMlHt9gnClwMdlAoxdA4/Q== =SsMi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 15 May 2020 21:52:01 +0200 (CEST)
"Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2020-05-15 at 07:08 -0400, Anton Aylward wrote:
On 11/05/2020 06:11, Carlos E. R. wrote:
...
I suggest that 'vmstat -SM -a 15' in an xterm will tell you more about what's going on than 'top'.
I tried, I find it cryptic.
Telcontar:~ # vmstat -SM -a 15 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 1 0 1330 17369 2280 10992 0 0 332 146 51 38 6 1 92 0 0 0 0 1330 17477 2280 10882 0 0 0 16 3454 5955 2 0 97 0 0 1 0 1330 17461 2280 10901 0 0 0 27 3250 5629 2 0 97 0 0
What is each column?
man vmstat?
After a while, the header disapears, so I don't even have that minimal information. The header should not flow out.
That depends on what assumptions it makes about the capabilities of the device its output is rendered by. You seek to prevent it rendering on basic devices? You can always write a filter to apply afterwards.
- -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar)
-----BEGIN PGP SIGNATURE-----
iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXr7y4Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVlpwAniM413KNZRmuX3ecyfnI Otj78kixAKCWKN3soMlHt9gnClwMdlAoxdA4/Q== =SsMi -----END PGP SIGNATURE-----
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/05/2020 01.25, Dave Howorth wrote:
On Fri, 15 May 2020 21:52:01 +0200 (CEST) "Carlos E. R." <> wrote:
On Friday, 2020-05-15 at 07:08 -0400, Anton Aylward wrote:
On 11/05/2020 06:11, Carlos E. R. wrote:
...
I suggest that 'vmstat -SM -a 15' in an xterm will tell you more about what's going on than 'top'.
I tried, I find it cryptic.
Telcontar:~ # vmstat -SM -a 15 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 1 0 1330 17369 2280 10992 0 0 332 146 51 38 6 1 92 0 0 0 0 1330 17477 2280 10882 0 0 0 16 3454 5955 2 0 97 0 0 1 0 1330 17461 2280 10901 0 0 0 27 3250 5629 2 0 97 0 0
What is each column?
man vmstat?
I'll bite. "man vmstat" then search for "columns" produces nothing. I'm not the one that wants to use vmstat, so it is possible that Anton already knows and can tell me faster than me finding out :-)
After a while, the header disapears, so I don't even have that minimal information. The header should not flow out.
That depends on what assumptions it makes about the capabilities of the device its output is rendered by. You seek to prevent it rendering on basic devices? You can always write a filter to apply afterwards.
You could have said that it prints the headers again every while. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 15/05/2020 22:55, Carlos E. R. wrote:
On 16/05/2020 01.25, Dave Howorth wrote:
On Fri, 15 May 2020 21:52:01 +0200 (CEST) "Carlos E. R." <> wrote:
On Friday, 2020-05-15 at 07:08 -0400, Anton Aylward wrote:
On 11/05/2020 06:11, Carlos E. R. wrote:
...
I suggest that 'vmstat -SM -a 15' in an xterm will tell you more about what's going on than 'top'.
I tried, I find it cryptic.
Telcontar:~ # vmstat -SM -a 15 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 1 0 1330 17369 2280 10992 0 0 332 146 51 38 6 1 92 0 0 0 0 1330 17477 2280 10882 0 0 0 16 3454 5955 2 0 97 0 0 1 0 1330 17461 2280 10901 0 0 0 27 3250 5629 2 0 97 0 0
What is each column?
man vmstat?
I'll bite. "man vmstat" then search for "columns" produces nothing. I'm not the one that wants to use vmstat, so it is possible that Anton already knows and can tell me faster than me finding out :-)
From "man vmstat"
FIELD DESCRIPTION FOR VM MODE Procs r: The number of runnable processes (running or waiting for run time). b: The number of processes in uninterruptible sleep. Memory swpd: the amount of virtual memory used. free: the amount of idle memory. buff: the amount of memory used as buffers. cache: the amount of memory used as cache. inact: the amount of inactive memory. (-a option) active: the amount of active memory. (-a option) Swap si: Amount of memory swapped in from disk (/s). so: Amount of memory swapped to disk (/s). IO bi: Blocks received from a block device (blocks/s). bo: Blocks sent to a block device (blocks/s). System in: The number of interrupts per second, including the clock. cs: The number of context switches per second. CPU These are percentages of total CPU time. us: Time spent running non-kernel code. (user time, including nice time) sy: Time spent running kernel code. (system time) id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time. wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle. st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown It's right there in front of you.
After a while, the header disapears, so I don't even have that minimal information. The header should not flow out.
That depends on what assumptions it makes about the capabilities of the device its output is rendered by. You seek to prevent it rendering on basic devices? You can always write a filter to apply afterwards.
You could have said that it prints the headers again every while.
I did. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/05/2020 05.06, Anton Aylward wrote:
On 15/05/2020 22:55, Carlos E. R. wrote:
On 16/05/2020 01.25, Dave Howorth wrote:
On Fri, 15 May 2020 21:52:01 +0200 (CEST) "Carlos E. R." <> wrote:
On Friday, 2020-05-15 at 07:08 -0400, Anton Aylward wrote:
On 11/05/2020 06:11, Carlos E. R. wrote:
...
I suggest that 'vmstat -SM -a 15' in an xterm will tell you more about what's going on than 'top'.
I tried, I find it cryptic.
Telcontar:~ # vmstat -SM -a 15 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 1 0 1330 17369 2280 10992 0 0 332 146 51 38 6 1 92 0 0 0 0 1330 17477 2280 10882 0 0 0 16 3454 5955 2 0 97 0 0 1 0 1330 17461 2280 10901 0 0 0 27 3250 5629 2 0 97 0 0
What is each column?
man vmstat?
I'll bite. "man vmstat" then search for "columns" produces nothing. I'm not the one that wants to use vmstat, so it is possible that Anton already knows and can tell me faster than me finding out :-)
From "man vmstat"
FIELD DESCRIPTION FOR VM MODE Procs r: The number of runnable processes (running or waiting for run time). b: The number of processes in uninterruptible sleep.
Memory swpd: the amount of virtual memory used. free: the amount of idle memory. buff: the amount of memory used as buffers. cache: the amount of memory used as cache. inact: the amount of inactive memory. (-a option) active: the amount of active memory. (-a option)
what units? maybe MiB, because you told to use -SM.
Swap si: Amount of memory swapped in from disk (/s). so: Amount of memory swapped to disk (/s).
I'd prefer read/write
IO bi: Blocks received from a block device (blocks/s). bo: Blocks sent to a block device (blocks/s).
What's a block? Maybe 1KiB.
System in: The number of interrupts per second, including the clock. cs: The number of context switches per second.
CPU These are percentages of total CPU time. us: Time spent running non-kernel code. (user time, including nice time) sy: Time spent running kernel code. (system time) id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time. wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle. st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown
stolen? what is that?
It's right there in front of you.
I did not see it... :-D
After a while, the header disapears, so I don't even have that minimal information. The header should not flow out.
That depends on what assumptions it makes about the capabilities of the device its output is rendered by. You seek to prevent it rendering on basic devices? You can always write a filter to apply afterwards.
You could have said that it prints the headers again every while.
I did.
I did not see it. I see that the program does it, now, several hours after I asked :-D Thanks. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 15/05/2020 23:19, Carlos E. R. wrote:
On 16/05/2020 05.06, Anton Aylward wrote:
On 15/05/2020 22:55, Carlos E. R. wrote:
On 16/05/2020 01.25, Dave Howorth wrote:
On Fri, 15 May 2020 21:52:01 +0200 (CEST) "Carlos E. R." <> wrote:
On Friday, 2020-05-15 at 07:08 -0400, Anton Aylward wrote:
> On 11/05/2020 06:11, Carlos E. R. wrote:
...
> I suggest that 'vmstat -SM -a 15' in an xterm will tell you more > about what's going on than 'top'.
I tried, I find it cryptic.>>>> Telcontar:~ # vmstat -SM -a 15 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 1 0 1330 17369 2280 10992 0 0 332 146 51 38 6 1 92 0 0 0 0 1330 17477 2280 10882 0 0 0 16 3454 5955 2 0 97 0 0 1 0 1330 17461 2280 10901 0 0 0 27 3250 5629 2 0 97 0 0
What is each column?
man vmstat?
In one sense all manual pages are; reading them is an acquired skill. (Writing them is also a skill!) Nevertheless, RTFM.
I'll bite. "man vmstat" then search for "columns" produces nothing. I'm not the one that wants to use vmstat, so it is possible that Anton already knows and can tell me faster than me finding out :-)
You could have searched for, variously 'procs' and the other heading items.
From "man vmstat"
...
what units?
maybe MiB, because you told to use -SM.
yes, that too is in the manual :-)
Swap si: Amount of memory swapped in from disk (/s). so: Amount of memory swapped to disk (/s).
I'd prefer read/write
How is that not read/write?
IO bi: Blocks received from a block device (blocks/s). bo: Blocks sent to a block device (blocks/s).
What's a block? Maybe 1KiB.
How is you system set up? What's a disk block? Is it 4K or ore you still on 512byte disk blocks?
CPU These are percentages of total CPU time. us: Time spent running non-kernel code. (user time, including nice time) sy: Time spent running kernel code. (system time) id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time. wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle. st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown
stolen? what is that?
Since I don't run a virtual machine I don't know. I suspect it has to do it you run this ON a virtual machine.
I did not see it... :-D
It was pretty blatant and unavoidable. As manual pages go, this is pretty informative. If anything, the problem is with vmstat since it can be run in many modes, all producing completely different results. There are some other XXstat programs that are a lot more awkward and obscure. Try running cpupcstat for Thunderbird! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On 15/05/2020 23:19, Carlos E. R. wrote:
On 16/05/2020 05.06, Anton Aylward wrote:
On 15/05/2020 22:55, Carlos E. R. wrote:
On 16/05/2020 01.25, Dave Howorth wrote:
...
What is each column?
man vmstat?
In one sense all manual pages are; reading them is an acquired skill. (Writing them is also a skill!)
It is certainly a skill. This particular one is better written than others. There are some that takes me months to understand, so fearing that, I asked.
Swap si: Amount of memory swapped in from disk (/s). so: Amount of memory swapped to disk (/s).
I'd prefer read/write
How is that not read/write?
I mean that to me, r/w is easier.
IO bi: Blocks received from a block device (blocks/s). bo: Blocks sent to a block device (blocks/s).
What's a block? Maybe 1KiB.
How is you system set up? What's a disk block? Is it 4K or ore you still on 512byte disk blocks?
There may be both, depending on the age of each disk. Tha manual says that it is 1KiB on all modern kernels, though.
CPU These are percentages of total CPU time. us: Time spent running non-kernel code. (user time, including nice time) sy: Time spent running kernel code. (system time) id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time. wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle. st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown
stolen? what is that?
Since I don't run a virtual machine I don't know. I suspect it has to do it you run this ON a virtual machine.
I do run virtual machines some times, and I have never seen this concept. Any way, now it shows: procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 3 0 2329 19751 1637 9508 0 0 45 133 3620 6020 71 8 0 20 0 0 0 2329 19790 1637 9468 0 0 0 112 3568 6004 87 10 0 3 0 1 1 2329 19706 1637 9552 0 0 33 128 3243 5820 81 13 0 6 0 3 0 2329 19683 1637 9578 0 0 4 38 3267 5645 87 9 0 4 0 0 0 2329 19644 1637 9615 0 0 0 102 3240 5419 86 10 0 4 0 0 0 2329 19252 1910 9725 0 0 20092 269 4013 6954 49 8 0 42 0 0 0 2328 19250 1912 9731 0 0 171 185 3169 5506 66 7 0 27 0 1 0 2328 19277 1912 9706 0 0 0 97 3267 5490 85 9 0 6 0 4 0 2328 19287 1679 9930 0 0 49 127 3278 5681 69 10 0 22 0 3 0 2328 19251 1698 9943 0 0 33 1589 3545 6133 62 10 0 28 0 2 0 2327 19290 1698 9904 0 0 74 46 3360 5696 72 8 0 20 0 top - 14:02:56 up 4 days, 13:10, 2 users, load average: 0,60, 0,65, 0,53 Tasks: 551 total, 2 running, 548 sleeping, 0 stopped, 1 zombie %Cpu(s): 2,0 us, 0,3 sy, 0,0 ni, 97,5 id, 0,1 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 18335128 free, 10401488 used, 4140096 buff/cache KiB Swap: 10485760+total, 10257641+free, 2281184 used. 20870552 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND CODE DATA nMaj vMj vMn RSan RSfd RSlk 24710 cer 20 0 4430776 0,980g 85640 0 S 0,000 3,126 20:18.60 thunderbird-bin 212 1617252 377 0 0 942068 59760 0 11496 cer 20 0 4843260 872956 312428 64460 S 2,388 2,655 86:40.71 firefox 212 912816 5276 0 0 560528 59052 0 11845 cer 20 0 4071616 784796 95820 37160 S 0,000 2,387 11:57.00 Web Content 212 1161692 375 0 3 688976 55692 0 11976 cer 20 0 3977680 585980 86052 64712 S 0,597 1,782 168:09.69 Web Content 212 1028908 4925 0 123 499928 60132 0 20464 cer 20 0 4401012 584172 179544 0 S 0,000 1,777 19:17.50 firefox 212 729260 209 0 0 404628 55656 0 20628 cer 20 0 3577652 512744 202828 0 S 0,896 1,560 43:35.84 Web Content 212 554964 2 0 1k 309916 54028 0 11911 cer 20 0 3830272 473816 115144 4848 S 0,000 1,441 13:06.18 Web Content 212 802968 1146 0 0 358672 60896 0 11794 cer 20 0 3749636 465324 93140 5312 S 0,000 1,415 13:12.27 Web Content 212 757192 1515 0 0 372184 61308 0 3813 vscan 20 0 1168052 449440 3112 502912 S 0,000 1,367 2:08.61 clamd 180 995972 880k 0 0 446328 3112 0 - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXr/aDBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVZb8AoI2bv4Exfi0yVHH8w4Mv PFegRZxNAJ9bvyrmIa0BTa65HpOViJgKJ/RbSA== =oiS/ -----END PGP SIGNATURE-----
Anton Aylward wrote:
On 15/05/2020 23:19, Carlos E. R. wrote:
On 16/05/2020 05.06, Anton Aylward wrote:
Swap si: Amount of memory swapped in from disk (/s). so: Amount of memory swapped to disk (/s).
I'd prefer read/write
How is that not read/write?
IO bi: Blocks received from a block device (blocks/s). bo: Blocks sent to a block device (blocks/s).
What's a block? Maybe 1KiB.
How is you system set up? What's a disk block? Is it 4K or ore you still on 512byte disk blocks?
It matters not - he could have a variety of disk block sizes. -- Per Jessen, Zürich (16.7°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/05/2020 22:55, Carlos E. R. wrote:
I'll bite. "man vmstat" then search for "columns" produces nothing.
it wouldn't be helpful to express it that way. The columns' alter depending on the mode in which vmstat is run. Those modes are made clear on the command line and the first few 'options'. Variously: vmstat -m vmstat -d to which 'columns' would you want to refer to? no, it is documented by the mode. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
- but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
And this remains so for a while or is it just something temporary? With menus being slow, that isn't necessarily the application, but could be the overall windowing/GUI system. You don't see the same issue elsewhere, in firefox, in libreoffice, in gimp ? -- Per Jessen, Zürich (13.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/05/2020 12.49, Per Jessen wrote:
Carlos E. R. wrote:
- but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
And this remains so for a while or is it just something temporary? With menus being slow, that isn't necessarily the application, but could be the overall windowing/GUI system. You don't see the same issue elsewhere, in firefox, in libreoffice, in gimp ?
Just this app, permanently (goes 0.5 up and down). At start, it uses less than 1 GB, and goes up over the days. Sorting by memory. top - 13:27:11 up 9 days, 2:19, 2 users, load average: 0,67, 0,44, 0,35 Tasks: 563 total, 1 running, 561 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,9 us, 0,2 sy, 0,0 ni, 98,8 id, 0,1 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 32876712 total, 1252484 free, 13813292 used, 17810936 buff/cache KiB Swap: 10485760+total, 10453683+free, 320768 used. 17815212 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5234 cer 20 0 7858524 4,440g 175816 0 S 0,000 14,16 414:52.35 thunderbird-bin 5396 cer 20 0 4648448 967096 357180 0 S 1,791 2,942 118:40.46 firefox 5818 cer 20 0 4100180 965620 185736 0 S 0,299 2,937 155:18.20 Web Content 3718 vscan 20 0 1158272 711216 5032 234092 S 0,000 2,163 5:33.75 clamd 4685 cer 20 0 12,721g 639836 197784 0 S 0,299 1,946 20:46.62 soffice.bin 5697 cer 20 0 3782768 607512 191136 0 S 0,299 1,848 64:14.83 Web Content 5057 cer 39 19 1710348 587396 14588 0 S 0,000 1,787 1:34.98 tracker-miner-f (note: clamd uses swap because I force it to, using cgroups). -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
On 11/05/2020 12.49, Per Jessen wrote:
Carlos E. R. wrote:
- but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
And this remains so for a while or is it just something temporary? With menus being slow, that isn't necessarily the application, but could be the overall windowing/GUI system. You don't see the same issue elsewhere, in firefox, in libreoffice, in gimp ?
Just this app, permanently (goes 0.5 up and down). At start, it uses less than 1 GB, and goes up over the days.
No, not the memory issue, just the sluggishness, in menus. -- Per Jessen, Zürich (14.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-05-11 08:27 AM, Per Jessen wrote:
Just this app, permanently (goes 0.5 up and down). At start, it uses less than 1 GB, and goes up over the days. No, not the memory issue, just the sluggishness, in menus.
Yep, the system just bogs down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2020-05-11 a las 14:27 +0200, Per Jessen escribió:
Carlos E. R. wrote:
On 11/05/2020 12.49, Per Jessen wrote:
Carlos E. R. wrote:
- but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
And this remains so for a while or is it just something temporary? With menus being slow, that isn't necessarily the application, but could be the overall windowing/GUI system. You don't see the same issue elsewhere, in firefox, in libreoffice, in gimp ?
Just this app, permanently (goes 0.5 up and down). At start, it uses less than 1 GB, and goes up over the days.
No, not the memory issue, just the sluggishness, in menus.
No, only Thunderbird felt sluggish. - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXrldpRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVL+wAoIp6bT8vXjcel2pPG7i/ X51u3/2QAJ9um13b0UgwM61l/30fxRWtMsgYgw== =fRw3 -----END PGP SIGNATURE-----
On 11/05/2020 06:49, Per Jessen wrote:
Carlos E. R. wrote:
- but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
And this remains so for a while or is it just something temporary? With menus being slow, that isn't necessarily the application, but could be the overall windowing/GUI system. You don't see the same issue elsewhere, in firefox, in libreoffice, in gimp ?
What you are asking there is "Do other GTK applications behave like this?" -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 11/05/2020 06:49, Per Jessen wrote:
Carlos E. R. wrote:
- but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
And this remains so for a while or is it just something temporary? With menus being slow, that isn't necessarily the application, but could be the overall windowing/GUI system. You don't see the same issue elsewhere, in firefox, in libreoffice, in gimp ?
What you are asking there is "Do other GTK applications behave like this?"
Yes, I was suspecting an issue in the GUI, not in the app. When Carlos said "Click on a menu or option and I have to wait for it to get highlighted", I think that is not for TB to do, that is for the windowing system. Mind you, I have not done any such GUI programming for almost 30 years. -- Per Jessen, Zürich (13.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2020-05-15 at 18:39 +0200, Per Jessen wrote:
Anton Aylward wrote:
On 11/05/2020 06:49, Per Jessen wrote:
Carlos E. R. wrote:
- but sometimes I type and the letters take a second to appear. Or click on a menu or option and I have to wait for it to get highlighted.
And this remains so for a while or is it just something temporary? With menus being slow, that isn't necessarily the application, but could be the overall windowing/GUI system. You don't see the same issue elsewhere, in firefox, in libreoffice, in gimp ?
What you are asking there is "Do other GTK applications behave like this?"
Yes, I was suspecting an issue in the GUI, not in the app. When Carlos said "Click on a menu or option and I have to wait for it to get highlighted", I think that is not for TB to do, that is for the windowing system. Mind you, I have not done any such GUI programming for almost 30 years.
No, I have not observed it, or at least not significant. Sometimes the menu may have to be loaded from disk, being the first time it is used. But the system is running on M2 nvme "disk". - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXr7qEBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV9KgAn11NXQcZxzqN8UzdSeWV Xsuvyn0vAKCK1bFB0952DoD/0z9wZpz6SrUiGA== =4cVP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-05-15 12:39 PM, Per Jessen wrote:
Yes, I was suspecting an issue in the GUI, not in the app. When Carlos said "Click on a menu or option and I have to wait for it to get highlighted", I think that is not for TB to do, that is for the windowing system. Mind you, I have not done any such GUI programming for almost 30 years.
I have also noticed such sluggish behaviour. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anton Aylward -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
gumb -
James Knott -
Per Jessen -
Simon Lees