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