On 2020-03-04 11:14 AM, Patrick Shanahan wrote:

sysctl vm.swappiness vm.swappiness = 60

isn't google amazing!

If you know what you're looking for. One thing I've noticed is there's a lot of disk activity when the system bogs down.  What value of swapiness would you recommend? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-04 11:48 AM, Patrick Shanahan wrote:

I have no swap but do have 36G system memory:

I have 16 G and, as I mentioned, don't reach that.  So, turning off swap might help? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* James Knott [03-04-20 11:54]:

On 2020-03-04 11:48 AM, Patrick Shanahan wrote:

...

I have no swap but do have 36G system memory:

I have 16 G and, as I mentioned, don't reach that.  So, turning off swap might help?

it is simple to do and to restore: as root swapoff swap on "might" leaves much leeway ... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 04.03.20 um 18:04 schrieb James Knott:

On 2020-03-04 12:00 PM, Patrick Shanahan wrote:

...

it is simple to do and to restore:    as root    swapoff            swap on

"might" leaves much leeway ...

swapoff: /var/lib/swap/swapfile: swapoff failed: Cannot allocate memory

do this when system has nothing in swap memory- if i understand this error message correct, there is not enough memory to put all what is inside swap back to main memory, - see my last post simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/03/2020 06:34, Carlos E. R. wrote:

And yes, your system bogs down as more swap is used, because modern swap can not cope when set on rotating rust. You need to move it to an SSD disk.

No. If it is happening then it is symptomatic of something wrong. A faster swap with SSD wont fix it. It just speeds up the IO rate of the thrashing. Just like a faster CPU will speed up the rate at which the memory gets scanned for scheduling the IO. So what? https://en.wikipedia.org/wiki/Thrashing_(computer_science) In computer science, thrashing occurs when a computer's virtual memory resources are overused, leading to a constant state of paging and page faults, inhibiting most application-level processing. -- 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:

On 05/03/2020 14.54, Anton Aylward wrote:

...

On 05/03/2020 06:34, Carlos E. R. wrote:

...

And yes, your system bogs down as more swap is used, because modern swap can not cope when set on rotating rust. You need to move it to an SSD disk.

No.

Yes.

I have to side with Anton, there is no absolute need. If your system is running out of memory, buy more memory, not swap space. If you are memory-constrained and dependent on swap, then using an SSD for swap will no doubt help. That is the only situation, otherwise it is not necessary. -- Per Jessen, Zürich (8.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 2020-03-05 02:56 PM, Carlos E. R. wrote:

...

I have to side with Anton, there is no absolute need.  If your system is running out of memory, buy more memory, not swap space.

Sure. IF the machine can accept more memory modules. Mine will not.

I have the slots.  I don't have the memory to put in them and it's no longer available. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-06 03:16 AM, jdd@dodin.org wrote:

Le 05/03/2020 à 21:10, James Knott a écrit :

...

I have the slots.  I don't have the memory to put in them and it's no longer available.

that's curious. Special kind? can you share the reference?

Here's what I currently have: https://www.kingston.com/datasheets/KHX16C10B1R_8.pdf

I use mostly old machines and I always could find ram, sometime second hand

I couldn't find any new.  I did try some used, different brand though, and my computer wouldn't even boot.  The person I got it from said it tested OK for him. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 6 Mar 2020 22:11:59 +0100 "jdd@dodin.org" wrote:

Le 06/03/2020 à 16:14, James Knott a écrit :

...

On 2020-03-06 03:16 AM, jdd@dodin.org wrote:

...

Le 05/03/2020 à 21:10, James Knott a écrit :

...

I have the slots.  I don't have the memory to put in them and it's no longer available.

that's curious. Special kind? can you share the reference?

Here's what I currently have: https://www.kingston.com/datasheets/KHX16C10B1R_8.pdf

may be ask kingston for a dealer?

Amazon says the product has a replacement, so maybe ask Kingston if the replacement will work with his hardware will be a better question?

jdd

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 7 Mar 2020 17:15:25 -0500 James Knott wrote:

On 2020-03-06 05:21 PM, Dave Howorth wrote:

...

...

may be ask kingston for a dealer? Amazon says the product has a replacement, so maybe ask Kingston if the replacement will work with his hardware will be a better question?

The replacement is out of stock.

https://smile.amazon.co.uk/HyperX-HX316C10FW-memory-1600MHz-240-pin/dp/B00J8... says in stock "Get it Tomorrow if you order within 50 mins" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 7 Mar 2020 18:09:50 -0500 James Knott wrote:

On 2020-03-07 05:55 PM, Dave Howorth wrote:

...

On Sat, 7 Mar 2020 17:15:25 -0500 James Knott wrote:

...

On 2020-03-06 05:21 PM, Dave Howorth wrote:

...

...

may be ask kingston for a dealer? Amazon says the product has a replacement, so maybe ask Kingston if the replacement will work with his hardware will be a better question? The replacement is out of stock.

https://smile.amazon.co.uk/HyperX-HX316C10FW-memory-1600MHz-240-pin/dp/B00J8...

says in stock "Get it Tomorrow if you order within 50 mins"

Get it tomorrow from England?  I live in Canada and it's enough of a pain getting stuff from the U.S..  Also, it's £39.76.  What's that in $Canadian?  (or kilograms? ;-) )  About $70 each or $140 for the pair, which is a lot more than memory costs here., plus duty, etc..

Sorry my point was simply that it clearly isn't out of stock, so perhaps check your local sources again. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott composed on 2020-03-07 18:36 (UTC-0500):

Dave Howorth wrote:

...

Sorry my point was simply that it clearly isn't out of stock, so perhaps check your local sources again.

I have checked the local store, where I bought the mom board, eBay and Amazon in Canada.

£39.76 UK https://www.amazon.co.uk/HyperX-HX316C10FW-memory-1600MHz-240-pin/dp/B00J8E9... $42.99 https://www.newegg.ca/p/0RM-001W-000A1 $38.16 US https://www.newegg.com/hyperx-4gb-240-pin-ddr3-sdram/p/N82E16820104449 -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/03/2020 23.57, Dave Howorth wrote:

On Sat, 7 Mar 2020 17:15:25 -0500 James Knott wrote:

...

On 2020-03-06 05:21 PM, Dave Howorth wrote:

...

...

may be ask kingston for a dealer? Amazon says the product has a replacement, so maybe ask Kingston if the replacement will work with his hardware will be a better question?

The replacement is out of stock.

PS Since when has memory had a colour? (especially one that affects the price?!)

Ha ha! :-D You refer to those LED colours? Programmable. Beautiful they say, so that you need computer boxes with glass sides. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 2020-03-07 06:08 PM, Carlos E. R. wrote:

Beautiful they say, so that you need computer boxes with glass sides.

You mean the ones that would likely fail the radio interference tests? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/03/2020 14.43, James Knott wrote:

On 2020-03-07 06:08 PM, Carlos E. R. wrote:

...

Beautiful they say, so that you need computer boxes with glass sides.

You mean the ones that would likely fail the radio interference tests?

YES! I wonder how they are allowed to sell them :-/ -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Carlos E. R. wrote:

On 05/03/2020 20.48, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 05/03/2020 14.54, Anton Aylward wrote:

...

On 05/03/2020 06:34, Carlos E. R. wrote:

...

And yes, your system bogs down as more swap is used, because modern swap can not cope when set on rotating rust. You need to move it to an SSD disk.

No.

Yes.

I have to side with Anton, there is no absolute need. If your system is running out of memory, buy more memory, not swap space.

Sure. IF the machine can accept more memory modules. Mine will not.

...

If you are memory-constrained and dependent on swap, then using an SSD for swap will no doubt help. That is the only situation, otherwise it is not necessary.

Which is the case. I recognize the symptoms James sees because I saw them in my machine.

I dunno if that is the case, I haven't followed this thread. I just disagree with your claim that "modern swap can not cope when set on rotating rust. You need to move it to an SSD disk.". It is just not true. -- Per Jessen, Zürich (6.2°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

* Carlos E. R. [03-05-20 15:25]:

On 05/03/2020 21.13, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 05/03/2020 20.48, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 05/03/2020 14.54, Anton Aylward wrote:

...

On 05/03/2020 06:34, Carlos E. R. wrote: > And yes, your system bogs down as more swap is used, because > modern swap can not cope when set on rotating rust. You need to > move it to an SSD disk.

No.

Yes.

I have to side with Anton, there is no absolute need. If your system is running out of memory, buy more memory, not swap space.

Sure. IF the machine can accept more memory modules. Mine will not.

...

If you are memory-constrained and dependent on swap, then using an SSD for swap will no doubt help. That is the only situation, otherwise it is not necessary.

Which is the case. I recognize the symptoms James sees because I saw them in my machine.

I dunno if that is the case, I haven't followed this thread. I just disagree with your claim that "modern swap can not cope when set on rotating rust. You need to move it to an SSD disk.". It is just not true.

It is true. If you have a trashing situation. Try it. On 13.1 it worked well, on Leap 42 it did not. Same machine, same load.

He says that the machine does not respond. That's what happened to me, till I set the swap on ssd.

your thrashing is now just less noticeable. You put a bandaid on a broken bone, nothing healed. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

...

I just disagree with your claim that "modern swap can not cope when set on rotating rust. You need to move it to an SSD disk.". It is just not true.

It is true. If you have a trashing situation.

Aha, conditions. That is possible. But "modern swap can not cope when set on rotating rust" is simply not unconditionally true. -- Per Jessen, Zürich (8.2°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 2020-03-05 05:02 PM, Carlos E. R. wrote:

Well, in the context of the situation James was describing in the thread. Not for hibernation, but when a system doesn't have enough RAM and "swaps". :-)

--

Except it does have enough.  I've never seen all 16 GB used, at least according to System Monitor. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020/03/05 05:54, Anton Aylward wrote:

On 05/03/2020 06:34, Carlos E. R. wrote:

...

And yes, your system bogs down as more swap is used, because modern swap can not cope when set on rotating rust. You need to move it to an SSD disk.

No. If it is happening then it is symptomatic of something wrong. A faster swap with SSD wont fix it. It just speeds up the IO rate of the thrashing. Just like a faster CPU will speed up the rate at which the memory gets scanned for scheduling the IO. So what?

---- Like a ramdisk wouldn't fix it either, right..., in fact probably not memory either. Hrmph. Well saying 'fix' it, is a bit of a misnomer when the OS isn't broken. But if your swap is as fast as memory at a good 2-3GB/s, its defintely gonna help -- alot. A PCIe (sits in a motherboard slot instead in harddisk form) would help drastically, but better would be to increase main memory.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-05 06:34 AM, Carlos E. R. wrote:

Which means that your system *really* needs swap. The thread is long, I still have not seen your figures.

But as far as I can see from what I have read so far, attempts to reduce swapines will make the situation worse in your case.

And yes, your system bogs down as more swap is used, because modern swap can not cope when set on rotating rust. You need to move it to an SSD disk.

I have mentioned memory & swap usage a couple of times.  When I posted yesterday, with: "I'm running 15.1 & KDE.  One thing I've noticed is swap use increases through time, even though I'm not even using all the real memory.  Eventually, it gets to the point where my system bogs down and can become unusable.  At the moment, I'm running 13.6 GiB of 15.6 memory and 4.1 of 24 swap.  Why should swap be used at all, when there's still a significant amount of free memory? " I was runnig VirtualBox, which is configured to use 8 GB.  At the moment, I'm not running it and seeing 6.9 GiB of memory and 0.5 swap.  Last night, after rebooting, it was less than 4 GiB memory and no swap.  So, just sitting there overnight, both memory and swap increased.  If I leave things running, both will climb. As for browsers, I use both Chromium and Firefox, as I find one or the other is often better for certain things.  That said, I will often open and close Firefox windows several times over thc course of the day.  I also have several sites I leave up all the time, in both browsers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-05 02:42 PM, Carlos E. R. wrote:

...

I have mentioned memory & swap usage a couple of times.  When I posted yesterday, with: Yes, you have mentioned it. I want to see command output instead of your words.

From top?  If so, you'll have to remind me of the command.

...

"I'm running 15.1 & KDE.  One thing I've noticed is swap use increases through time, even though I'm not even using all the real memory. Eventually, it gets to the point where my system bogs down and can become unusable.  At the moment, I'm running 13.6 GiB of 15.6 memory and 4.1 of 24 swap.  Why should swap be used at all, when there's still a significant amount of free memory? "

I was runnig VirtualBox, which is configured to use 8 GB. So, your system had 8 GiB available, not 16. Similar status to my system with 8 GiB available and swapping heavily.

I don't run VirtualBox all the time, though I was running it yesterday.  This problem happens even when I'm not running VB. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-05 03:13 PM, Carlos E. R. wrote:

...

Then, copy and paste here the first dozen lines.

 2689 root      20   0 2735400 2.047g 2.011g    388 S 0.664 13.16 59:26.39 X  6429 jknott    20   0 6929668 1.666g  79636      0 S 0.000 10.71 10:56.17 chromium  6383 jknott    20   0 5174852 1.002g 518716  66224 S 1.661 6.443 91:15.78 firefox  7533 jknott    20   0 3763544 510912 223876   8092 S 1.661 3.133 15:03.56 Web Content 16432 jknott    20   0 3500248 473988 172168  26096 S 0.664 2.907 180:46.57 Web Content  2722 jknott    20   0 2899032 467184 112704      0 S 1.661 2.865 0:17.00 seamonkey-bin 16455 jknott    20   0 3311108 377300 158768   2720 S 1.329 2.314 25:51.38 Web Content  6416 jknott    20   0 5260464 342428  91016      8 S 0.000 2.100 5:18.55 chromium  7429 jknott    20   0 9424920 342424  48252  33488 S 0.000 2.100 3:07.85 WebExtensions 16511 jknott    20   0 3066376 296760 168196  11560 S 0.332 1.820 5:24.45 Web Content 16483 jknott    20   0 3176516 292752 149048   9516 S 1.329 1.795 24:19.16 Web Content  5752 jknott    20   0 1450596 288200  94344     16 S 0.332 1.768 12:17.20 chromium -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-05 03:46 PM, Carlos E. R. wrote:

On 05/03/2020 21.34, James Knott wrote:

...

On 2020-03-05 03:13 PM, Carlos E. R. wrote:

...

...

Then, copy and paste here the first dozen lines.

And the other six missing lines? Why did you remove them?

You mean these? top - 15:33:22 up 22:54,  4 users,  load average: 0.27, 0.43, 0.44 Tasks: 271 total,   1 running, 270 sleeping,   0 stopped,   0 zombie %Cpu(s):  1.4 us,  0.6 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st MiB Mem : 15923.24+total, 2351.809 free, 6603.551 used, 6967.883 buff/cache MiB Swap: 16383.68+total, 15989.43+free,  394.250 used. 6000.145 avail Mem -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-05 03:56 PM, Carlos E. R. wrote:

Sigh, it seems you have to pay per post. Why not post it all at once? I'll have to assume they are both from the same screenshot of top. Joining your two posts:

Yes they were from the same capture.  I had to stop top for it to be stable enough to capture the lines.  Here's the whole thing. %Cpu(s):  1.4 us,  0.6 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st MiB Mem : 15923.24+total, 2351.809 free, 6603.551 used, 6967.883 buff/cache MiB Swap: 16383.68+total, 15989.43+free,  394.250 used. 6000.145 avail Mem   PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM     TIME+ COMMAND  2689 root      20   0 2735400 2.047g 2.011g    388 S 0.664 13.16 59:26.39 X  6429 jknott    20   0 6929668 1.666g  79636      0 S 0.000 10.71 10:56.17 chromium  6383 jknott    20   0 5174852 1.002g 518716  66224 S 1.661 6.443 91:15.78 firefox  7533 jknott    20   0 3763544 510912 223876   8092 S 1.661 3.133 15:03.56 Web Content 16432 jknott    20   0 3500248 473988 172168  26096 S 0.664 2.907 180:46.57 Web Content  2722 jknott    20   0 2899032 467184 112704      0 S 1.661 2.865 0:17.00 seamonkey-bin 16455 jknott    20   0 3311108 377300 158768   2720 S 1.329 2.314 25:51.38 Web Content  6416 jknott    20   0 5260464 342428  91016      8 S 0.000 2.100 5:18.55 chromium  7429 jknott    20   0 9424920 342424  48252  33488 S 0.000 2.100 3:07.85 WebExtensions 16511 jknott    20   0 3066376 296760 168196  11560 S 0.332 1.820 5:24.45 Web Content 16483 jknott    20   0 3176516 292752 149048   9516 S 1.329 1.795 24:19.16 Web Content  5752 jknott    20   0 1450596 288200  94344     16 S 0.332 1.768 12:17.20 chromium  3309 jknott    20   0 4341556 276532 111164      0 S 0.664 1.696 9:41.22 plasmashell  6736 jknott    20   0 5114568 235144  89184     20 S 0.000 1.442 2:24.57 chromium 16567 jknott    20   0 3233528 230640 111980   7988 S 0.332 1.415 7:43.07 Web Content 16539 jknott    20   0 3166252 214480 121516   7796 S 0.000 1.315 11:11.28 Web Content  7345 jknott    20   0 2843108 205760  89784  11936 S 0.664 1.262 4:12.01 Web Content  6046 jknott    20   0 5099932 191180  39152     60 S 0.332 1.172 1:24.37 chromium 16998 jknott    20   0  875120 174932 122868      0 S 0.000 1.073 2:48.27 chromium  6415 jknott    20   0 3439784 154840  61624  17748 S 4.983 0.950 21:46.71 amarok 22963 jknott    20   0 5039856 149444  89704      0 S 0.332 0.917 0:30.28 chromium  3305 jknott    20   0 2503644 131844  69844      0 S 0.000 0.809 0:42.11 krunner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/03/2020 21.58, James Knott wrote:

On 2020-03-05 03:56 PM, Carlos E. R. wrote:

...

Sigh, it seems you have to pay per post. Why not post it all at once? I'll have to assume they are both from the same screenshot of top. Joining your two posts:

Yes they were from the same capture.  I had to stop top for it to be stable enough to capture the lines.  Here's the whole thing.

Thanks :-)

%Cpu(s):  1.4 us,  0.6 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si, 0.0 st MiB Mem : 15923.24+total, 2351.809 free, 6603.551 used, 6967.883 buff/cache MiB Swap: 16383.68+total, 15989.43+free,  394.250 used. 6000.145 avail Mem

So, this moment there is little swap in use. Then you have 6 gigs available, which is good. Almost 7 used in buffers/cache, which is good, the kernel likes that. "Only" 2 gigs free - the kernel tries to keep just a bit free, not much. 6603.551 used 6967.883 buff/cache 2351.809 free + ----------------- 15923,243 close enough to 16.

  PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM TIME+ COMMAND  2689 root      20   0 2735400 2.047g 2.011g    388 S 0.664 13.16 59:26.39 X

Well, your X is using a lot of RAM. 2 gigs. Mine take about 150 megs. Why that difference? :-? Maybe your display has very high resolution. Or many colours. Or something.

 6429 jknott    20   0 6929668 1.666g  79636      0 S 0.000 10.71 10:56.17 chromium

1.6 gigs for chromium, but there are other chromium processes.

 6383 jknott    20   0 5174852 1.002g 518716  66224 S 1.661 6.443 91:15.78 firefox

1 gig for firefox, then add the "Web Content". So far we have 4.5 gigs in use. You can continue adding the other lines, you should get 6.6. (not being preciss, there is also shared memory).

 7533 jknott    20   0 3763544 510912 223876   8092 S 1.661 3.133 15:03.56 Web Content 16432 jknott    20   0 3500248 473988 172168  26096 S 0.664 2.907 180:46.57 Web Content  2722 jknott    20   0 2899032 467184 112704      0 S 1.661 2.865 0:17.00 seamonkey-bin 16455 jknott    20   0 3311108 377300 158768   2720 S 1.329 2.314 25:51.38 Web Content  6416 jknott    20   0 5260464 342428  91016      8 S 0.000 2.100 5:18.55 chromium  7429 jknott    20   0 9424920 342424  48252  33488 S 0.000 2.100 3:07.85 WebExtensions 16511 jknott    20   0 3066376 296760 168196  11560 S 0.332 1.820 5:24.45 Web Content 16483 jknott    20   0 3176516 292752 149048   9516 S 1.329 1.795 24:19.16 Web Content  5752 jknott    20   0 1450596 288200  94344     16 S 0.332 1.768 12:17.20 chromium  3309 jknott    20   0 4341556 276532 111164      0 S 0.664 1.696 9:41.22 plasmashell  6736 jknott    20   0 5114568 235144  89184     20 S 0.000 1.442 2:24.57 chromium 16567 jknott    20   0 3233528 230640 111980   7988 S 0.332 1.415 7:43.07 Web Content 16539 jknott    20   0 3166252 214480 121516   7796 S 0.000 1.315 11:11.28 Web Content  7345 jknott    20   0 2843108 205760  89784  11936 S 0.664 1.262 4:12.01 Web Content  6046 jknott    20   0 5099932 191180  39152     60 S 0.332 1.172 1:24.37 chromium 16998 jknott    20   0  875120 174932 122868      0 S 0.000 1.073 2:48.27 chromium  6415 jknott    20   0 3439784 154840  61624  17748 S 4.983 0.950 21:46.71 amarok 22963 jknott    20   0 5039856 149444  89704      0 S 0.332 0.917 0:30.28 chromium  3305 jknott    20   0 2503644 131844  69844      0 S 0.000 0.809 0:42.11 krunner

You see the method... now you have to capture when there is much more swap in use. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 05/03/2020 22.35, James Knott wrote:

On 2020-03-05 04:27 PM, Carlos E. R. wrote:

...

Well, your X is using a lot of RAM. 2 gigs. Mine take about 150 megs. Why that difference? :-? Maybe your display has very high resolution. Or many colours. Or something.

No idea.  I don't play with that sort of thing, so it's whatever is default KDE on a 1080p monitor.  I have 4 virtual desktops enabled. I have noticed some unusual behaviour.  For example, the task bar will occasionally disappear and come back several seconds later. Using Alt-F2 is often slow, etc..

Well, other KDE users will have to say and compare with their systems. Me, I use XFCE (1920*1080p), with 12 desktops. I don't know what Alt-F2 does on KDE, here it does nothing. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 2020-03-05 04:47 PM, Carlos E. R. wrote:

I don't know what Alt-F2 does on KDE, here it does nothing.

It's for krunner, a box where you can type commands. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Here's another capture.  I see X is high again and I had a lot of disk activity. Tasks: 263 total,   1 running, 262 sleeping,   0 stopped,   0 zombie %Cpu(s):  3.3 us,  2.9 sy,  0.0 ni, 80.6 id, 13.1 wa,  0.0 hi, 0.0 si,  0.0 st MiB Mem : 15923.24+total,  430.297 free, 14000.02+used, 1492.918 buff/cache MiB Swap: 16383.68+total, 15117.98+free, 1265.699 used.  847.727 avail Mem   PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM     TIME+ COMMAND  2551 root      20   0 1048948 450312 419688   6680 S 0.664 2.762   4:55.34 X  3792 jknott    20   0 11.004g 365188 311904  53712 S 25.25 2.240 329:00.40 VirtualBox  4409 jknott    20   0 4932256 715296 298580 127832 S 1.329 4.387 21:48.76 firefox  4442 jknott    20   0 4582208 1.200g 120740 223340 S 11.63 7.716 176:10.14 seamonkey-bin  7284 jknott    20   0 3072196 345236 115592  60796 S 1.993 2.117 14:18.84 Web Content  7542 jknott    20   0 2979808 184904  86880   9424 S 0.332 1.134   5:12.24 Web Content  7013 jknott    20   0 3052704 262532  74572  30904 S 1.661 1.610 13:18.59 Web Content  4479 jknott    20   0  846720 119936  74452     40 S 0.000 0.736   1:02.80 chromium 23761 jknott    20   0 5039640 128700  72840      0 S 0.000 0.789   0:26.27 chromium  5272 jknott    20   0 5743384 676308  70536  35212 S 0.000 4.148   3:04.28 chromium 23746 jknott    20   0 4991144 109928  70012      0 S 0.000 0.674   0:08.37 chromium 23802 jknott    20   0 4977648  88392  69756      0 S 0.000 0.542   0:00.25 chromium  5783 jknott    20   0 5020888 107856  67436    484 S 0.000 0.661   0:03.09 chromium  6898 jknott    20   0 3313052 283668  66012  13992 S 1.661 1.740 22:40.69 Web Content  7318 jknott    20   0 2723776  80460  64748  47240 S 0.000 0.493   2:12.28 Web Content  4400 jknott    20   0 1345748 228048  63328   1900 S 0.332 1.399   7:38.35 chromium  3254 jknott    20   0 3935188 202992  62452   1124 S 0.664 1.245   4:24.32 plasmashell  7458 jknott    20   0 3264376 207640  61068  69560 S 1.993 1.273 27:07.63 Web Content  5773 jknott    20   0 9347640 222528  56532  10044 S 0.000 1.365   4:21.46 chromium  5259 jknott    20   0 5073072 167636  56232   1932 S 0.332 1.028   5:02.24 chromium  6767 jknott    20   0 2916264 285972  56120  34364 S 0.000 1.754   3:08.22 Web Content  5001 jknott    20   0 5008820  91324  47660     52 S 0.000 0.560   0:16.06 chromium On 2020-03-05 04:27 PM, Carlos E. R. wrote:

On 05/03/2020 21.58, James Knott wrote:

...

On 2020-03-05 03:56 PM, Carlos E. R. wrote:

...

Sigh, it seems you have to pay per post. Why not post it all at once? I'll have to assume they are both from the same screenshot of top. Joining your two posts: Yes they were from the same capture.  I had to stop top for it to be stable enough to capture the lines.  Here's the whole thing. Thanks :-)

...

%Cpu(s):  1.4 us,  0.6 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si, 0.0 st MiB Mem : 15923.24+total, 2351.809 free, 6603.551 used, 6967.883 buff/cache MiB Swap: 16383.68+total, 15989.43+free,  394.250 used. 6000.145 avail Mem So, this moment there is little swap in use.

Then you have 6 gigs available, which is good. Almost 7 used in buffers/cache, which is good, the kernel likes that. "Only" 2 gigs free - the kernel tries to keep just a bit free, not much.

6603.551 used 6967.883 buff/cache 2351.809 free + ----------------- 15923,243 close enough to 16.

...

  PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM TIME+ COMMAND  2689 root      20   0 2735400 2.047g 2.011g    388 S 0.664 13.16 59:26.39 X Well, your X is using a lot of RAM. 2 gigs. Mine take about 150 megs. Why that difference? :-? Maybe your display has very high resolution. Or many colours. Or something.

...

 6429 jknott    20   0 6929668 1.666g  79636      0 S 0.000 10.71 10:56.17 chromium 1.6 gigs for chromium, but there are other chromium processes.

...

 6383 jknott    20   0 5174852 1.002g 518716  66224 S 1.661 6.443 91:15.78 firefox 1 gig for firefox, then add the "Web Content".

So far we have 4.5 gigs in use. You can continue adding the other lines, you should get 6.6. (not being preciss, there is also shared memory).

...

 7533 jknott    20   0 3763544 510912 223876   8092 S 1.661 3.133 15:03.56 Web Content 16432 jknott    20   0 3500248 473988 172168  26096 S 0.664 2.907 180:46.57 Web Content  2722 jknott    20   0 2899032 467184 112704      0 S 1.661 2.865 0:17.00 seamonkey-bin 16455 jknott    20   0 3311108 377300 158768   2720 S 1.329 2.314 25:51.38 Web Content  6416 jknott    20   0 5260464 342428  91016      8 S 0.000 2.100 5:18.55 chromium  7429 jknott    20   0 9424920 342424  48252  33488 S 0.000 2.100 3:07.85 WebExtensions 16511 jknott    20   0 3066376 296760 168196  11560 S 0.332 1.820 5:24.45 Web Content 16483 jknott    20   0 3176516 292752 149048   9516 S 1.329 1.795 24:19.16 Web Content  5752 jknott    20   0 1450596 288200  94344     16 S 0.332 1.768 12:17.20 chromium  3309 jknott    20   0 4341556 276532 111164      0 S 0.664 1.696 9:41.22 plasmashell  6736 jknott    20   0 5114568 235144  89184     20 S 0.000 1.442 2:24.57 chromium 16567 jknott    20   0 3233528 230640 111980   7988 S 0.332 1.415 7:43.07 Web Content 16539 jknott    20   0 3166252 214480 121516   7796 S 0.000 1.315 11:11.28 Web Content  7345 jknott    20   0 2843108 205760  89784  11936 S 0.664 1.262 4:12.01 Web Content  6046 jknott    20   0 5099932 191180  39152     60 S 0.332 1.172 1:24.37 chromium 16998 jknott    20   0  875120 174932 122868      0 S 0.000 1.073 2:48.27 chromium  6415 jknott    20   0 3439784 154840  61624  17748 S 4.983 0.950 21:46.71 amarok 22963 jknott    20   0 5039856 149444  89704      0 S 0.332 0.917 0:30.28 chromium  3305 jknott    20   0 2503644 131844  69844      0 S 0.000 0.809 0:42.11 krunner

You see the method... now you have to capture when there is much more swap in use.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/03/2020 20.15, Patrick Shanahan wrote:

* James Knott [03-07-20 13:45]:

...

Here's another capture.  I see X is high again and I had a lot of disk activity.

Tasks: 263 total,   1 running, 262 sleeping,   0 stopped,   0 zombie %Cpu(s):  3.3 us,  2.9 sy,  0.0 ni, 80.6 id, 13.1 wa,  0.0 hi, 0.0 si,  0.0 st MiB Mem : 15923.24+total,  430.297 free, 14000.02+used, 1492.918 buff/cache MiB Swap: 16383.68+total, 15117.98+free, 1265.699 used.  847.727 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM     TIME+ COMMAND  2551 root      20   0 1048948 450312 419688   6680 S 0.664 2.762   4:55.34 X  3792 jknott    20   0 11.004g 365188 311904  53712 S 25.25 2.240 329:00.40 VirtualBox

please, please turn off wrap when you include information as above. Or provide a location where the information may be viewed ("unwrapped").

It is not wrapped here. It is when I try to answer that thunderbird or pine wraps it. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

* Patrick Shanahan [03-07-20 14:23]:

* Carlos E. R. [03-07-20 14:21]:

...

On 07/03/2020 20.15, Patrick Shanahan wrote:

...

* James Knott [03-07-20 13:45]:

...

Here's another capture.  I see X is high again and I had a lot of disk activity.

Tasks: 263 total,   1 running, 262 sleeping,   0 stopped,   0 zombie %Cpu(s):  3.3 us,  2.9 sy,  0.0 ni, 80.6 id, 13.1 wa,  0.0 hi, 0.0 si,  0.0 st MiB Mem : 15923.24+total,  430.297 free, 14000.02+used, 1492.918 buff/cache MiB Swap: 16383.68+total, 15117.98+free, 1265.699 used.  847.727 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM     TIME+ COMMAND  2551 root      20   0 1048948 450312 419688   6680 S 0.664 2.762   4:55.34 X  3792 jknott    20   0 11.004g 365188 311904  53712 S 25.25 2.240 329:00.40 VirtualBox

please, please turn off wrap when you include information as above. Or provide a location where the information may be viewed ("unwrapped").

It is not wrapped here. It is when I try to answer that thunderbird or pine wraps it.

I even opened the post in my editor with ww off and it was still wrapped.

but only the data from "top". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/03/2020 20.31, James Knott wrote:

On 2020-03-07 02:25 PM, Patrick Shanahan wrote:

...

...

I even opened the post in my editor with ww off and it was still wrapped. but only the data from "top".

I just compared my email, as sent, with top in Konsole and there is no difference at all in the layout.  Since Carlos is also not seeing it, it must be something at your end.

Maybe it is "soft" wrapped. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 07/03/2020 20.40, James Knott wrote:

On 2020-03-07 02:33 PM, Carlos E. R. wrote:

...

...

I just compared my email, as sent, with top in Konsole and there is no difference at all in the layout.  Since Carlos is also not seeing it, it must be something at your end.

Maybe it is "soft" wrapped.

I only see 2 things in preferences related to wrap.  In Message Display, "Wrap text to fix window width" is selected and in Composition, "Wrap plain text messages at" is set to 72.

mail.wrap_long_lines;true mailnews.wraplength;72 plain_text.wrap_long_lines;true mailnews.send_plaintext_flowed;true http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird 6 Advanced 6.1 Flowed format Then, I suppose you use this addon: http://git.kiszka.org/togglewordwrap.git/ (Toggle Word Wrap by Jan Kiszka) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

James Knott composed on 2020-03-07 15:06 (UTC-0500):

Carlos E. R. wrote:

...

http://git.kiszka.org/togglewordwrap.git/  (Toggle Word Wrap by Jan Kiszka)

Never heard of it.

Mine's apparently different, by Kaspar Brand, Toggle Word Wrap 1.10: http://fm.no-ip.com/SS/Moz/toggleWordWrapSM249x.jpg http://fm.no-ip.com/Share/toggle-word-wrap-110.xpi -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/03/2020 21.54, Patrick Shanahan wrote:

* Carlos E. R. [03-07-20 14:36]:

...

On 07/03/2020 20.31, James Knott wrote:

...

On 2020-03-07 02:25 PM, Patrick Shanahan wrote:

...

...

I even opened the post in my editor with ww off and it was still wrapped. but only the data from "top".

I just compared my email, as sent, with top in Konsole and there is no difference at all in the layout.  Since Carlos is also not seeing it, it must be something at your end.

Maybe it is "soft" wrapped.

no.

Well, it is certainly not hard wrapped. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

* Carlos E. R. [03-07-20 16:11]:

On 07/03/2020 21.54, Patrick Shanahan wrote:

...

* Carlos E. R. [03-07-20 14:36]:

...

On 07/03/2020 20.31, James Knott wrote:

...

On 2020-03-07 02:25 PM, Patrick Shanahan wrote:

...

...

I even opened the post in my editor with ww off and it was still wrapped. but only the data from "top".

I just compared my email, as sent, with top in Konsole and there is no difference at all in the layout.  Since Carlos is also not seeing it, it must be something at your end.

Maybe it is "soft" wrapped.

no.

It is.

00002810 3a 35 35 2e 33 34 20 58 0d 0a 20 c2 a0 33 37 39 |:55.34 X.. ..379| 00002820 32 20 6a 6b 6e 6f 74 74 c2 a0 c2 a0 c2 a0 20 32 |2 jknott...... 2| 00002830 30 c2 a0 c2 a0 20 30 20 31 31 2e 30 30 34 67 20 |0.... 0 11.004g | 00002840 33 36 35 31 38 38 20 33 31 31 39 30 34 c2 a0 20 |365188 311904.. | 00002850 35 33 37 31 32 20 53 20 32 35 2e 32 35 20 32 2e |53712 S 25.25 2.| 00002860 32 34 30 20 0d 0a 33 32 39 3a 30 30 2e 34 30 20 |240 ..329:00.40 | .....................****** 00002870 56 69 72 74 75 61 6c 42 6f 78 0d 0a 20 c2 a0 34 |VirtualBox.. ..4| 00002880 34 30 39 20 6a 6b 6e 6f 74 74 c2 a0 c2 a0 c2 a0 |409 jknott......|

Now see the photo how it displays here:

https://susepaste.org/93886157

No wrap. That is called "soft wrap". It is a setting on your end which is displaying that soft wrap as wrapped. Your client chooses to wrap at that soft wrap point (which is a carriage return encoded but ignored by other clients).

Carlso, I opened the text message in joe with word wrap OFF, the lines were still wrapped. here is what I received raw: Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on wahoo.wahoo.no-ip.org X-Spam-Level: X-Spam-Status: No X-Original-To: paka Delivered-To: paka@wahoo.wahoo.no-ip.org Received: by wahoo.wahoo.no-ip.org (Postfix, from userid 1000) id 881BE6184E; Sat, 7 Mar 2020 13:45:20 -0500 (EST) X-Apparently-To: ptilopteri@att.net; Sat, 07 Mar 2020 18:43:10 +0000 Authentication-Results: mta4076.sbc.mail.bf1.yahoo.com; dkim=permerror (bad sig) header.i=@jknott-net.20150623.gappssmtp.com header.s=20150623; spf=none smtp.mailfrom=@opensuse.org; dmarc=NULL(p=NULL sp=NULL dis=NULL) header.from=jknott.net; Received-SPF: none (domain of opensuse.org does not designate permitted sender hosts) X-YMailISG: i894N1IWLDsIghHq8zCTiWRS6CjMUL3dRRtJi0HfCqFj7Vft jI1by3Ssuwnl4uYAUEJJV7xUgRo36z2wkfyIQWzKxCuFfXZd40hggMG8am6H FdKT5bsSiDGBIY4W8Ga09wxoqXl.OaBSgW1mDn6mnH9a5T.jVmMfGt06fkPH 5tPxC5Nx6y0v4eYVlGaFzzmXqm8x4kFePcRB6w6ucVu7F4OvLsj80IV5czTk Gcvao5XEa5fw7z8UrXI5i.u5T9bVSxmC7.iHtLmImP49O0zlmBDwp1_Ui8cN TbQ5y17r3SbNR4Z8ahjhBt.tVo.hNJCMogT7ROHaL1uabAcyPnsGuuGVSv6R Zs45ppWDkqZuTZfiFLYAf1Jjv_XilSmB1TDVgu8z3VU97WHnnsY2E1WhXASc pWwHxggix36H9obpzDT0AB8hQbrtmukwi6shRTiRHCIMGpd.7Yzm3w0VbIph M6ZxXDMP8pquCm2GJLFfZzcgceM5kJD6l_r5nr99ACkLz8IPU.LlD_RBlzsq TURH4ih2AF0aqLTvvo64tAgtr_qZMGIFlxQFQ.uCNRvLfM4JkudXC4Syw5gX e1v_KUoiEzqjUBJdtFyTSOlFV.XtY244PJe_iVjXMjruWnsMHP7u5CeemvvI CkIGl1RpXby428DJ4jk.e6nGCYnXgKQtnrLcGI.BTq.awxgjfZnfajw.eebQ JR5xkGPWGZkIypLulUR3eDJON1mI5szjdOewQzsCZDBVi_dmD_5JQjGC0.w2 E5wK50Bok8fKOBOP8ajYVxmH3_UgXaGAfSnh9EUhDVPUPv4PumJgFia87zpk 80vC0uzyhQFlhJqayF6TRBAe8LmPz_QUqFWKTQMqr4bnXz9vHZdNPT9e_H7M jxcmCt09EfbhrwAjUVDu0Es33aK3DeIrIxOFLG1TlLov5Q9BIrCQLLRO5KM6 O2C123X6.eaUI4jS557rpMkSZbA29YUPndmP1UCetwoZ_hLfxesFh9FZd5TX HdHmpUcFSRbuoen2i1Wv2dih9b.oX1_T6Y4XrafIliFulIXLEnzvefiqeD19 YxxynguUg5EO6CJNWVZ_euR9yO5C X-Originating-IP: [195.135.220.15] Received: from internal.imap.mail.g03.yahoodns.net [98.137.159.41] by wahoo.wahoo.no-ip.org with IMAP (fetchmail-6.3.26) for (single-drop); Sat, 07 Mar 2020 13:45:20 -0500 (EST) Received: from 10.194.221.232 (EHLO alph754.enaf.aldc.att.com) (144.160.244.124) by mta4076.sbc.mail.bf1.yahoo.com with SMTPS; Sat, 07 Mar 2020 18:43:10 +0000 X-Header-Overseas: Mail.from.Overseas.source.195.135.220.15 X-Originating-IP: [195.135.220.15] Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alph754.enaf.aldc.att.com (Inbound 8.15.2/8.15.2) with ESMTPS id 027Ih7ob110647 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 7 Mar 2020 13:43:09 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from hydra.opensuse.org (proxy-nue1.opensuse.org [195.135.221.145]) by mx2.suse.de (Postfix) with ESMTP id 55709B398 for ; Sat, 7 Mar 2020 18:43:07 +0000 (UTC) Received: from lists5.opensuse.org (baloo.infra.opensuse.org [192.168.47.38]) by hydra.opensuse.org (Postfix) with ESMTP id 21F6024360 for ; Sat, 7 Mar 2020 18:43:00 +0000 (UTC) Received: from baloo.infra.opensuse.org (localhost [127.0.0.1]) by lists5.opensuse.org (Postfix) with ESMTP id 2D83111BEE; Sat, 7 Mar 2020 18:42:59 +0000 (UTC) X-Original-To: opensuse@lists5.opensuse.org Delivered-To: opensuse@lists5.opensuse.org Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 48C5B2C148 for ; Sat, 7 Mar 2020 18:42:57 +0000 (UTC) Received: from mail-qv1-f68.google.com (mail-qv1-f68.google.com [209.85.219.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTPS id CDBE1B394 for ; Sat, 7 Mar 2020 18:42:56 +0000 (UTC) Received: by mail-qv1-f68.google.com with SMTP id u17so2559222qvv.7 for ; Sat, 07 Mar 2020 10:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jknott-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=JX4NcIqvBQeHX/Clr9gjQ8mzgyrDW90vlH6mHv52OCs=; b=tdRHK+lOWCtUcAt2ZL7l2+rVVNpz+ei3qMUDUaMNp4G0k/tvlAcxU1tokW5VK0gb10 kSM5rjJ6TUoMEsKKEPGXICfMNAguhCNJS75wRI+wFV2xZofb1IP3ZS3JnwqGDPrc7Aes daSHphfd2w2vWJE33w/11R4xhXgrwU7ybJ6lJB1KMTkBn3R4ua3MMcxbCIoEle9iIWf0 vHZ5cL+KiKTi/cdirtloyut3xNC+8bmZYxPqJEMl+ogiLaoz9S9J9D+KQXk0fVRdd8g8 renvkGxqtWqECidn8mYsupFEHyXapCP4A25if4oVxhbci237BtoNeEETQq39Ylnt+icK +Y5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=JX4NcIqvBQeHX/Clr9gjQ8mzgyrDW90vlH6mHv52OCs=; b=qtpfiK3rc4D3gtiXgo/XIKw2bJKR650UZTUVXoT4hw5iSqBJ63ItgQWfQfFKjiYSjb nVjAc8Xb91RN4JZWZ5YT0nXlz0P7wWFDSSZuUEfSYmM7Eh5WLc9pesCMRTrbPn16BcRF tXQrNmomAUCeL2ERQQzcLDzAce6mxGzSHOAE8pWMLpVbW6M3jFm9nja1QLTiW76rbMR/ Pj1Ezzkj36AKMAIqFRY+b6RtrGHlcX6YV76QqUwBirGlKwojcZAArekIvgytR4QvtCs4 3c599guPpDi/V7JA7aiNJc6gupNKokFNNnAwuxeU/F1ytfR4b5OOmb3CI/XtrR9Q0hx/ xf/g== X-Gm-Message-State: ANhLgQ3CSNpxAaB/6ah0tM/0PleYKYJO7U+hab+MCL2+yVe1O8ktO8GU vbmJT76knmO2uC2WXJOYkEobGMlkLyRwZw== X-Google-Smtp-Source: ADFU+vtc3mMmYkH0efPssVqk41npyAhkGtscH1taoL56uHAG96YeiLa8okz0ltMWEGVi5hWJVJ4M/A== X-Received: by 2002:ad4:58ea:: with SMTP id di10mr8399892qvb.101.1583606574685; Sat, 07 Mar 2020 10:42:54 -0800 (PST) Received: from ?IPv6:2607:fea8:4c80:b00:76d4:35ff:fe5b:f5fa? ([2607:fea8:4c80:b00:76d4:35ff:fe5b:f5fa]) by smtp.gmail.com with ESMTPSA id b2sm19179322qkj.9.2020.03.07.10.42.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Mar 2020 10:42:54 -0800 (PST) Subject: Re: [opensuse] Why swap? To: opensuse@opensuse.org References: <20200304161401.GU25664@wahoo.no-ip.org> <20200304164800.GW25664@wahoo.no-ip.org> <552836be-44df-ba0c-7ba9-5bf0931119e1@jknott.net> <20200304170029.GY25664@wahoo.no-ip.org> <96e190d2-b6eb-f8b5-6aca-9ec09fb4c09a@telefonica.net> <7b279dc6-0911-8cc7-3ee0-d3f2703435e4@jknott.net> <40055d6e-6b5b-7593-7bda-846402cf2503@telefonica.net> <14c12465-94fd-d706-339c-bd59c6397477@telefonica.net> <4bd4588e-f06d-7939-daa6-bea52a79e8fe@jknott.net> <8193fd4a-bedf-7f1d-afa2-47735000ddfb@telefonica.net> From: James Knott Message-ID: <03b5a86e-3bfc-3297-289e-4c0ac21ae338@jknott.net> Date: Sat, 7 Mar 2020 13:42:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 Precedence: bulk Mailing-List: contact opensuse+help@opensuse.org; run by mlmmj X-Mailinglist: opensuse List-Post: mailto:opensuse@opensuse.org List-Help: mailto:opensuse+help@opensuse.org List-Subscribe: mailto:opensuse+subscribe@opensuse.org List-Unsubscribe: mailto:opensuse+unsubscribe@opensuse.org List-Owner: mailto:opensuse+owner@opensuse.org List-Archive: http://lists.opensuse.org/opensuse/ X-MIME-Notice: attachments may have been removed from this message MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Envelope-From: opensuse+bounces-224070-paka=opensuse.org@opensuse.org Content-Length: 6681 Lines: 121 Here's another capture.  I see X is high again and I had a lot of disk activity. Tasks: 263 total,   1 running, 262 sleeping,   0 stopped,   0 zombie %Cpu(s):  3.3 us,  2.9 sy,  0.0 ni, 80.6 id, 13.1 wa,  0.0 hi, 0.0 si,  0.0 st MiB Mem : 15923.24+total,  430.297 free, 14000.02+used, 1492.918 buff/cache MiB Swap: 16383.68+total, 15117.98+free, 1265.699 used.  847.727 avail Mem   PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM     TIME+ COMMAND  2551 root      20   0 1048948 450312 419688   6680 S 0.664 2.762   4:55.34 X  3792 jknott    20   0 11.004g 365188 311904  53712 S 25.25 2.240 329:00.40 VirtualBox  4409 jknott    20   0 4932256 715296 298580 127832 S 1.329 4.387 21:48.76 firefox  4442 jknott    20   0 4582208 1.200g 120740 223340 S 11.63 7.716 176:10.14 seamonkey-bin  7284 jknott    20   0 3072196 345236 115592  60796 S 1.993 2.117 14:18.84 Web Content  7542 jknott    20   0 2979808 184904  86880   9424 S 0.332 1.134   5:12.24 Web Content  7013 jknott    20   0 3052704 262532  74572  30904 S 1.661 1.610 13:18.59 Web Content  4479 jknott    20   0  846720 119936  74452     40 S 0.000 0.736   1:02.80 chromium 23761 jknott    20   0 5039640 128700  72840      0 S 0.000 0.789   0:26.27 chromium  5272 jknott    20   0 5743384 676308  70536  35212 S 0.000 4.148   3:04.28 chromium 23746 jknott    20   0 4991144 109928  70012      0 S 0.000 0.674   0:08.37 chromium 23802 jknott    20   0 4977648  88392  69756      0 S 0.000 0.542   0:00.25 chromium  5783 jknott    20   0 5020888 107856  67436    484 S 0.000 0.661   0:03.09 chromium  6898 jknott    20   0 3313052 283668  66012  13992 S 1.661 1.740 22:40.69 Web Content  7318 jknott    20   0 2723776  80460  64748  47240 S 0.000 0.493   2:12.28 Web Content  4400 jknott    20   0 1345748 228048  63328   1900 S 0.332 1.399   7:38.35 chromium  3254 jknott    20   0 3935188 202992  62452   1124 S 0.664 1.245   4:24.32 plasmashell  7458 jknott    20   0 3264376 207640  61068  69560 S 1.993 1.273 27:07.63 Web Content  5773 jknott    20   0 9347640 222528  56532  10044 S 0.000 1.365   4:21.46 chromium  5259 jknott    20   0 5073072 167636  56232   1932 S 0.332 1.028   5:02.24 chromium  6767 jknott    20   0 2916264 285972  56120  34364 S 0.000 1.754   3:08.22 Web Content  5001 jknott    20   0 5008820  91324  47660     52 S 0.000 0.560   0:16.06 chromium On 2020-03-05 04:27 PM, Carlos E. R. wrote:

On 05/03/2020 21.58, James Knott wrote:

...

On 2020-03-05 03:56 PM, Carlos E. R. wrote:

...

Sigh, it seems you have to pay per post. Why not post it all at once? I'll have to assume they are both from the same screenshot of top. Joining your two posts: Yes they were from the same capture.  I had to stop top for it to be stable enough to capture the lines.  Here's the whole thing. Thanks :-)

...

%Cpu(s):  1.4 us,  0.6 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si, 0.0 st MiB Mem : 15923.24+total, 2351.809 free, 6603.551 used, 6967.883 buff/cache MiB Swap: 16383.68+total, 15989.43+free,  394.250 used. 6000.145 avail Mem So, this moment there is little swap in use.

Then you have 6 gigs available, which is good. Almost 7 used in buffers/cache, which is good, the kernel likes that. "Only" 2 gigs free - the kernel tries to keep just a bit free, not much.

6603.551 used 6967.883 buff/cache 2351.809 free + ----------------- 15923,243 close enough to 16.

...

  PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM TIME+ COMMAND  2689 root      20   0 2735400 2.047g 2.011g    388 S 0.664 13.16 59:26.39 X Well, your X is using a lot of RAM. 2 gigs. Mine take about 150 megs. Why that difference? :-? Maybe your display has very high resolution. Or many colours. Or something.

...

 6429 jknott    20   0 6929668 1.666g  79636      0 S 0.000 10.71 10:56.17 chromium 1.6 gigs for chromium, but there are other chromium processes.

...

 6383 jknott    20   0 5174852 1.002g 518716  66224 S 1.661 6.443 91:15.78 firefox 1 gig for firefox, then add the "Web Content".

So far we have 4.5 gigs in use. You can continue adding the other lines, you should get 6.6. (not being preciss, there is also shared memory).

...

 7533 jknott    20   0 3763544 510912 223876   8092 S 1.661 3.133 15:03.56 Web Content 16432 jknott    20   0 3500248 473988 172168  26096 S 0.664 2.907 180:46.57 Web Content  2722 jknott    20   0 2899032 467184 112704      0 S 1.661 2.865 0:17.00 seamonkey-bin 16455 jknott    20   0 3311108 377300 158768   2720 S 1.329 2.314 25:51.38 Web Content  6416 jknott    20   0 5260464 342428  91016      8 S 0.000 2.100 5:18.55 chromium  7429 jknott    20   0 9424920 342424  48252  33488 S 0.000 2.100 3:07.85 WebExtensions 16511 jknott    20   0 3066376 296760 168196  11560 S 0.332 1.820 5:24.45 Web Content 16483 jknott    20   0 3176516 292752 149048   9516 S 1.329 1.795 24:19.16 Web Content  5752 jknott    20   0 1450596 288200  94344     16 S 0.332 1.768 12:17.20 chromium  3309 jknott    20   0 4341556 276532 111164      0 S 0.664 1.696 9:41.22 plasmashell  6736 jknott    20   0 5114568 235144  89184     20 S 0.000 1.442 2:24.57 chromium 16567 jknott    20   0 3233528 230640 111980   7988 S 0.332 1.415 7:43.07 Web Content 16539 jknott    20   0 3166252 214480 121516   7796 S 0.000 1.315 11:11.28 Web Content  7345 jknott    20   0 2843108 205760  89784  11936 S 0.664 1.262 4:12.01 Web Content  6046 jknott    20   0 5099932 191180  39152     60 S 0.332 1.172 1:24.37 chromium 16998 jknott    20   0  875120 174932 122868      0 S 0.000 1.073 2:48.27 chromium  6415 jknott    20   0 3439784 154840  61624  17748 S 4.983 0.950 21:46.71 amarok 22963 jknott    20   0 5039856 149444  89704      0 S 0.332 0.917 0:30.28 chromium  3305 jknott    20   0 2503644 131844  69844      0 S 0.000 0.809 0:42.11 krunner

You see the method... now you have to capture when there is much more swap in use.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org as one can plainly see, the upper portion containing the information from "top" is wrapped while the lower portion is not. afaik, "joe" still does not soft wrap anyway. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [03-07-20 18:18]:

On 07/03/2020 23.25, Patrick Shanahan wrote:

...

* Carlos E. R. [03-07-20 16:11]:

...

On 07/03/2020 21.54, Patrick Shanahan wrote:

...

* Carlos E. R. [03-07-20 14:36]:

...

On 07/03/2020 20.31, James Knott wrote:

...

On 2020-03-07 02:25 PM, Patrick Shanahan wrote: > > I even opened the post in my editor with ww off and it was still > > wrapped. > but only the data from "top".

I just compared my email, as sent, with top in Konsole and there is no difference at all in the layout.  Since Carlos is also not seeing it, it must be something at your end.

Maybe it is "soft" wrapped.

no.

It is.

00002810 3a 35 35 2e 33 34 20 58 0d 0a 20 c2 a0 33 37 39 |:55.34 X.. ..379| 00002820 32 20 6a 6b 6e 6f 74 74 c2 a0 c2 a0 c2 a0 20 32 |2 jknott...... 2| 00002830 30 c2 a0 c2 a0 20 30 20 31 31 2e 30 30 34 67 20 |0.... 0 11.004g | 00002840 33 36 35 31 38 38 20 33 31 31 39 30 34 c2 a0 20 |365188 311904.. | 00002850 35 33 37 31 32 20 53 20 32 35 2e 32 35 20 32 2e |53712 S 25.25 2.| 00002860 32 34 30 20 0d 0a 33 32 39 3a 30 30 2e 34 30 20 |240 ..329:00.40 | .....................****** 00002870 56 69 72 74 75 61 6c 42 6f 78 0d 0a 20 c2 a0 34 |VirtualBox.. ..4| 00002880 34 30 39 20 6a 6b 6e 6f 74 74 c2 a0 c2 a0 c2 a0 |409 jknott......|

Now see the photo how it displays here:

https://susepaste.org/93886157

No wrap. That is called "soft wrap". It is a setting on your end which is displaying that soft wrap as wrapped. Your client chooses to wrap at that soft wrap point (which is a carriage return encoded but ignored by other clients).

Carlso, I opened the text message in joe with word wrap OFF, the lines were still wrapped.

I know.

...

here is what I received raw:

I know.

...

...

Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ...   PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM TIME+ COMMAND  2551 root      20   0 1048948 450312 419688   6680 S 0.664 2.762 4:55.34 X  3792 jknott    20   0 11.004g 365188 311904  53712 S 25.25 2.240 329:00.40 VirtualBox

I insist: that is soft-end-of-line, despite the appearances.

but the client which in my case is joe must support "soft wrap" and joe does not. why are *only* the data from top wrapped? who inserted the wrap? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-07 03:44 PM, Patrick Shanahan wrote:

...

What are you using to read the message?  I'm using Seamonkey. Konsole is set for 80 x 24. konsole at 50x148

data from "top" is wrapped.

I have no idea why that is.  It looks fine in 80 x 24. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 7 Mar 2020 23:00:06 +0100 "Carlos E. R." wrote:

On 07/03/2020 22.44, James Knott wrote:

...

On 2020-03-07 03:44 PM, Patrick Shanahan wrote:

...

...

What are you using to read the message?  I'm using Seamonkey. Konsole is set for 80 x 24. konsole at 50x148

data from "top" is wrapped.

I have no idea why that is.  It looks fine in 80 x 24.

See my previous post, it explains that your post contains "soft" returns, which are optional for the client to render or not. It is in fact a "0d 0a", but it is the "context" which makes it soft. It is the best I can describe, I don't know what that context is exactly.

Reference to whichever email standard you think is appropriate please. I see wrapped lines too, in the source as well as the display and $ file 38953 38953: SMTP mail, UTF-8 Unicode text, with very long lines nothing about wrapping conventions. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [03-07-20 18:18]:

On 08/03/2020 00.05, Dave Howorth wrote:

...

On Sat, 7 Mar 2020 23:00:06 +0100 "Carlos E. R." wrote:

...

On 07/03/2020 22.44, James Knott wrote:

...

On 2020-03-07 03:44 PM, Patrick Shanahan wrote:

...

...

What are you using to read the message?  I'm using Seamonkey. Konsole is set for 80 x 24. konsole at 50x148

data from "top" is wrapped.

I have no idea why that is.  It looks fine in 80 x 24.

See my previous post, it explains that your post contains "soft" returns, which are optional for the client to render or not. It is in fact a "0d 0a", but it is the "context" which makes it soft. It is the best I can describe, I don't know what that context is exactly.

Reference to whichever email standard you think is appropriate please.

It was explained to me in an NNTP thread where I participated. maybe I can locate it later.

This thread:

Message-ID: From: Frank Slootweg Newsgroups: comp.mobile.android Subject: Re: How to find REAL Android version? Date: 2 Jan 2020 13:29:40 GMT

I think the explanation is here:

http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird 6 Advanced 6.1 Flowed format

+++................ Flowed format

By default, support for flowed plain-text format is enabled. Incoming messages with the "format=flowed" attribute set are rewrapped to utilize the full width of the message window. Outgoing messages are still wrapped regularly, but the receiving e-mail client is allowed to rewrap the message for display. There are separate preferences to disable flowed message display (mailnews.display.disable_format_flowed_support) and sending flowed e-mails (mailnews.send_plaintext_flowed). You can use mailnews.wraplength to change the line length for messages you compose (defaults to 72 characters), mail.compose.wrap_to_window_width to wrap to the window width when composing a message (defaults to false) and mail.wrap_long_lines to control the wrapping of long lines (defaults to true).

Most webmail implementations, Outlook, Evolution, and Mac OS X Mail don't support it. Thunderbird, SeaMonkey, PostBox, Eudora, Pine, M2 (Opera mail program) and LuxSci webmail do. It is a interesting standard that just didn't catch on.

When replying in plain text, quotes may appear as a single line per paragraph (see this forum thread). Use Edit -> Rewrap to restore wrapping for those quotes.

Flowed text can cause problems with OpenPGP signatures. [1] [2] . The Enigmail add-on automatically replaces ">" in quoted messages with "|" and leading spaces with "~" to workaround this unless you set mailnews.send_plaintext_flowed false. There are also potential problems sending and saving patches [3] [4] if you use Enigmail. If you do not use "gpg --clearsign --not-dash-escaped ..." to disable dash-escaping all lines beginning with a dash are prefixed by a dash and a space. This is the reason you might notice an extra space and dash on any signature. [5].

Flowed text doesn't apparently cause problems with S/MIME (the built-in support for digital signatures and encrypted messages in Thunderbird). ................++-

...

I see wrapped lines too, in the source as well as the display and

$ file 38953 38953: SMTP mail, UTF-8 Unicode text, with very long lines

nothing about wrapping conventions.

Well, there are. Depends on the client.

then why are not the rest of the lines wrapped? header does contain "Content-Type: text/plain; charset=UTF-8; format=flowed" and aiui, format=flowed makes text fit the display screen with ?smart? wrapping so if the display screen is wider than the "wrapped" lines, why are they still wrapped and why only part of the post? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [03-07-20 21:09]:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Saturday, 2020-03-07 at 18:28 -0500, Patrick Shanahan wrote:

...

* Carlos E. R. <> [03-07-20 18:18]:

...

On 08/03/2020 00.05, Dave Howorth wrote:

...

...

...

Well, there are. Depends on the client.

then why are not the rest of the lines wrapped?

Because they are shorter than the assumed limit (perhaps 72 chars).

no, they definitely are not. Look at the text I sent.

...

header does contain "Content-Type: text/plain; charset=UTF-8; format=flowed"

Yes.

...

and aiui, format=flowed makes text fit the display screen with ?smart? wrapping so if the display screen is wider than the "wrapped" lines, why are they still wrapped and why only part of the post?

Because it is up to the client. The client has two choices: ignore the soft returns and wrap at screen size, like mine, or obey the soft returns, as does yours.

Joe is not a mail client, by the way; it is an editor that understand *some* mail nuances.

again you are not reading what I wrote. I opened the "raw" email text in a terminal wider than 140 chars with joe, not as an email but as TEXT.

And when going into edit/reply mode, the returns are obeyed, anyway.

you are not considering the facts. I opened the "raw" email text in both an editor (joe), less and most, all in terminals 140+ chars wide. there was absolutely no reason for them to wrap and no reason for *only* part of the text to wrap. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-07 02:15 PM, Patrick Shanahan wrote:

please, please turn off wrap when you include information as above. Or provide a location where the information may be viewed ("unwrapped").

I am sure that I am not alone in not being interested in editing the data you provide in order to read it.

I just checked what I sent and it's not wrapped.  It's nicely formatted in columns, just as it appears in Konsole -- 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 Saturday, 2020-03-07 at 13:42 -0500, James Knott wrote:

Here's another capture.  I see X is high again and I had a lot of disk activity.

Tasks: 263 total,   1 running, 262 sleeping,   0 stopped,   0 zombie %Cpu(s):  3.3 us,  2.9 sy,  0.0 ni, 80.6 id, 13.1 wa,  0.0 hi, 0.0 si,  0.0 st MiB Mem : 15923.24+total,  430.297 free, 14000.02+used, 1492.918 buff/cache

Notice that you have only 430 MB of free ram, which makes the kernel to try free some more. That's the inmediate cause of disk activity (swap activity). And being mechanical disk, the impact is huge.

MiB Swap: 16383.68+total, 15117.98+free, 1265.699 used.  847.727 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU %MEM     TIME+ COMMAND  2551 root      20   0 1048948 450312 419688   6680 S 0.664 2.762   4:55.34 X  3792 jknott    20   0 11.004g 365188 311904  53712 S 25.25 2.240 329:00.40 VirtualBox

Both X and VB eat large chunk of RAM. VB is also using a large chunk of virtual memory. I do not know why your X uses so much, but it is not as much as 2 days ago.

 4409 jknott    20   0 4932256 715296 298580 127832 S 1.329 4.387 21:48.76 firefox  4442 jknott    20   0 4582208 1.200g 120740 223340 S 11.63 7.716 176:10.14 seamonkey-bin

Seamonkey has 1.2 gigs, firefox 715 megs, chromium 700*7 megs. Then the several "Web Content" processes. It is your 3 browsers who are eating your ram. Restart them. Or better, exit one, and make sure you don't have them configured to automatically reload all tabs: only reload when you click on each tab.

 7284 jknott    20   0 3072196 345236 115592  60796 S 1.993 2.117 14:18.84 Web Content  7542 jknott    20   0 2979808 184904  86880   9424 S 0.332 1.134   5:12.24 Web Content  7013 jknott    20   0 3052704 262532  74572  30904 S 1.661 1.610 13:18.59 Web Content  4479 jknott    20   0  846720 119936  74452     40 S 0.000 0.736   1:02.80 chromium 23761 jknott    20   0 5039640 128700  72840      0 S 0.000 0.789   0:26.27 chromium  5272 jknott    20   0 5743384 676308  70536  35212 S 0.000 4.148   3:04.28 chromium 23746 jknott    20   0 4991144 109928  70012      0 S 0.000 0.674   0:08.37 chromium 23802 jknott    20   0 4977648  88392  69756      0 S 0.000 0.542   0:00.25 chromium  5783 jknott    20   0 5020888 107856  67436    484 S 0.000 0.661   0:03.09 chromium  6898 jknott    20   0 3313052 283668  66012  13992 S 1.661 1.740 22:40.69 Web Content  7318 jknott    20   0 2723776  80460  64748  47240 S 0.000 0.493   2:12.28 Web Content  4400 jknott    20   0 1345748 228048  63328   1900 S 0.332 1.399   7:38.35 chromium  3254 jknott    20   0 3935188 202992  62452   1124 S 0.664 1.245   4:24.32 plasmashell  7458 jknott    20   0 3264376 207640  61068  69560 S 1.993 1.273 27:07.63 Web Content  5773 jknott    20   0 9347640 222528  56532  10044 S 0.000 1.365   4:21.46 chromium  5259 jknott    20   0 5073072 167636  56232   1932 S 0.332 1.028   5:02.24 chromium  6767 jknott    20   0 2916264 285972  56120  34364 S 0.000 1.754   3:08.22 Web Content  5001 jknott    20   0 5008820  91324  47660     52 S 0.000 0.560   0:16.06 chromium

- -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXmP4Sxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVlW8Ani+tYLucmUZUPRk9qfJz HxOr8HXbAJ4/xpVQI0ig+T+R/9SYwgPMBtZDjA== =y1Yl -----END PGP SIGNATURE-----

On 07/03/2020 20.46, James Knott wrote:

On 2020-03-07 02:38 PM, Carlos E. R. wrote:

...

Or better, exit one, and make sure you don't have them configured to automatically reload all tabs: only reload when you click on each tab.

I'm not familiar with that setting and don't see it in Firefox.

I don't remember where it is or its name, and I can't find it now. But it is easy to notice: when you start firefox, only the current tab of each window displays. When you click on another tab, it is blank and then it starts to load. But there is one setting you can adjust: Performance. Reduce the "content process limit" number. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 2020-03-07 03:10 PM, Carlos E. R. wrote:

But there is one setting you can adjust: Performance. Reduce the "content process limit" number.

Did something change with Leap that might affect this?  I don't recall these issues prior to Leap.  I've been using SuSE since 9.3 and possibly earlier (I still have the 9.3 boxed set on my shelf, along with the SUSE Linux 9 Bible). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/03/2020 21.38, Carlos E. R. wrote:

On 07/03/2020 21.36, James Knott wrote:

...

On 2020-03-07 03:10 PM, Carlos E. R. wrote:

...

But there is one setting you can adjust: Performance. Reduce the "content process limit" number.

Did something change with Leap that might affect this?  I don't recall these issues prior to Leap.  I've been using SuSE since 9.3 and possibly earlier (I still have the 9.3 boxed set on my shelf, along with the SUSE Linux 9 Bible).

Well, this setting is new. And of course, using several child processes is also new. It makes FF much faster, but it uses more memory.

And there is another issue, of which I have no hard proof: swap suffers of fragmentation and consequently more disk head movement in Leap compared to 13.1 -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 07/03/2020 22.51, James Knott wrote:

On 2020-03-07 03:43 PM, Carlos E. R. wrote:

...

And there is another issue, of which I have no hard proof: swap suffers of fragmentation and consequently more disk head movement in Leap compared to 13.1

That could be it. :-\

I installed an SSD disk and the issue improved dramatically. After two years or so I bought another computer, but it is still waiting for assembly in the table behind me. So the SSD bought me some years of time. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On Sun, 8 Mar 2020 23:26:13 -0400 James Knott wrote:

On 2020-03-07 05:02 PM, Carlos E. R. wrote:

...

On 07/03/2020 22.51, James Knott wrote:

...

On 2020-03-07 03:43 PM, Carlos E. R. wrote:

...

And there is another issue, of which I have no hard proof: swap suffers of fragmentation and consequently more disk head movement in Leap compared to 13.1

That could be it. :-\

I installed an SSD disk and the issue improved dramatically. After two years or so I bought another computer, but it is still waiting for assembly in the table behind me. So the SSD bought me some years of time.

One other thing, the heavy disk activity is on an occasional basis. It can go hours without it happening, with the computer running find the rest of the time.  For example, right now it's running 13.5 GB of memory and 4.4 swap.  Yet, the computer is properly responsive. I just fired up a couple more Firefox windows and I don't notice any difference in response.  So, I'm thinking it's something other than swap, that occurs at long time intervals.

One of the disk indexing thingies? Or some filesystem cleanup activity? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/03/2020 04.26, James Knott wrote:

On 2020-03-07 05:02 PM, Carlos E. R. wrote:

...

On 07/03/2020 22.51, James Knott wrote:

...

On 2020-03-07 03:43 PM, Carlos E. R. wrote:

...

And there is another issue, of which I have no hard proof: swap suffers of fragmentation and consequently more disk head movement in Leap compared to 13.1

That could be it. :-\

I installed an SSD disk and the issue improved dramatically. After two years or so I bought another computer, but it is still waiting for assembly in the table behind me. So the SSD bought me some years of time.

One other thing, the heavy disk activity is on an occasional basis. It can go hours without it happening, with the computer running find the rest of the time.  For example, right now it's running 13.5 GB of memory and 4.4 swap.  Yet, the computer is properly responsive. I just fired up a couple more Firefox windows and I don't notice any difference in response.  So, I'm thinking it's something other than swap, that occurs at long time intervals.

If "top" at the moment shows "free" to be way less than 1G, like it did the second time, when you posted:

Here's another capture. I see X is high again and I had a lot of disk activity.

Tasks: 263 total, 1 running, 262 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.3 us, 2.9 sy, 0.0 ni, 80.6 id, 13.1 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 15923.24+total, 430.297 free, 14000.02+used, 1492.918 buff/cache MiB Swap: 16383.68+total, 15117.98+free, 1265.699 used. 847.727 avail Mem

That moment the problem was trashing. If currently you have four GB in swap, be assured that _your_ system needs it now and works better with it. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.0 x86_64 (Minas Tirith))

On 2020-03-05 03:56 PM, Carlos E. R. wrote:

Sigh, it seems you have to pay per post. Why not post it all at once? I'll have to assume they are both from the same screenshot of top. Joining your two posts:

BTW, I have an eye infection, which is making it difficult for me to focus on what I'm doing.  Even reading is difficult. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/03/2020 11:21, James Knott wrote:

On 2020-03-04 11:14 AM, Patrick Shanahan wrote:

...

sysctl vm.swappiness vm.swappiness = 60

isn't google amazing!

If you know what you're looking for.

One thing I've noticed is there's a lot of disk activity when the system bogs down.  What value of swapiness would you recommend?

It depends on your application mix. And your 'normal usage' might be different from the specific conditions that trigger this phenomena. Maybe something started in cron, maybe starting another interactive process, maybe creating another Firefox window or having firefox render a full screen graphic in YouTube. maybe ... As i said, using vmstat with a 10-15 second interval lets you look back and see the burst of activity. -- 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 03/04/2020 10:21 AM, James Knott wrote:

On 2020-03-04 11:14 AM, Patrick Shanahan wrote:

...

sysctl vm.swappiness vm.swappiness = 60

isn't google amazing!

If you know what you're looking for.

One thing I've noticed is there's a lot of disk activity when the system bogs down.  What value of swapiness would you recommend?

I put: vm.swappiness = 10 in /etc/sysctl.conf -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* James Knott [03-04-20 11:36]:

On 2020-03-04 11:25 AM, Simon Becherer wrote:

...

2) if you noticed over time it fills and fills and fills, maybe you have a application who has a memory problem. you should check what software is using your memory. -> bugreport

I find browsers, both Firefox and Chromium, take a lot of swap.

I would suggest watching Chromium. I utilize Firefox on Tw and have noticed no memory problems and I currently have 11 windows all with many tabs. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-04 08:45 PM, Michael Hamilton wrote:

On Thursday 05 March 2020, James Knott wrote:

...

I'm running 15.1 & KDE.  One thing I've noticed is swap use increases through time, even though I'm not even using all the real memory. Eventually, it gets to the point where my system bogs down and can become unusable.  At the moment, I'm running 13.6 GiB of 15.6 memory and 4.1 of 24 swap.  Why should swap be used at all, when there's still a significant amount of free memory?

No matter how you've set up swap and swappiness, bogging down only happens if a system is actually running out of memory, no amount of setting changes is going to fix running out of memory.

Our home desktops run chrome and firefox quite intensively. They have 8 and 16 GB respectively. They never get into a bogged down situation. I suspect you are running something that is leaking memory or some long run process that refuses to release memory it has accumulated.

Previously in such situation I would keep an eye on the memory usage. Perhaps in KsysGuard and watch for a gradual increase in usage after starting some program or starting some activity. Or perhaps in htop with processes sorted by memory usage.

The last time I had this sort of issue was when running chrome, the Android IDE, and and some Android emulators all at the same time with only 8 GB of RAM.

Michael

I have been watching the memory and this is why I know swap keeps on climbing, even when almost half of the memory is still available. When it climbs and I kill those browsers, memory and swap drop. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/03/2020 22:22, Patrick Shanahan wrote:

* James Knott [03-04-20 21:09]:

...

I have been watching the memory and this is why I know swap keeps on climbing, even when almost half of the memory is still available. When it climbs and I kill those browsers, memory and swap drop.

try running one or the other rather than both at the same time. both are probably not contributing to you running out of memory.

Maybe hey both are if it is a leaky plug-in. -- 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-03-05 08:47 AM, Patrick Shanahan wrote:

...

Maybe hey both are if it is a leaky plug-in. the same version of a plug-in on both browsers which utilize different api's ?? doubtful. but one must logically approach and elemination is a

I'm not running any plugins that I'm aware of on Chromium.  I have only the H264 video CODEC plugin on Firefox. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

I have been watching the memory and this is why I know swap keeps on climbing, even when almost half of the memory is still available. When it climbs and I kill those browsers, memory and swap drop.

Once it's swapped out it will stay there until it is needed. If it's not needed (job idle/sleeping) why should it be pulled back to memory? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/03/2020 20:45, Michael Hamilton wrote:

On Thursday 05 March 2020, James Knott wrote:

...

I'm running 15.1 & KDE.  One thing I've noticed is swap use increases through time, even though I'm not even using all the real memory.  Eventually, it gets to the point where my system bogs down and can become unusable.  At the moment, I'm running 13.6 GiB of 15.6 memory and 4.1 of 24 swap.  Why should swap be used at all, when there's still a significant amount of free memory?

No matter how you've set up swap and swappiness, bogging down only happens if a system is actually running out of memory, no amount of setting changes is going to fix running out of memory.

I'll give that a qualified yes and a qualified no. Bogging down due to running out of memory on a virtual memory system and hitting swap intensively is termed 'thrashing'. It is characterised by heavy activity to the swap disk, as opposed to heavy file activity that happens with a file IO intensive application such as some database activities. Please note that there are other file system oriented activities that can bog down a system. A disk-to-disk backup involving a file system tree walker (find feeding cpio, for example or generating the list for rsync). There are also other ways to bog down a system using IO. Backup across a network might be one. Then there are the CPU intensive ways to bog down a system.

Our home desktops run chrome and firefox quite intensively. They have 8 and 16 GB respectively. They never get into a bogged down situation.

Depending on your meaning of 'bogged down'. There are going to be cases where rendering of graphics by the CPU alone will consume all the CPU bandwidth. OK, very fringe and hardware dependent...

I suspect you are running something that is leaking memory or some long run process that refuses to release memory it has accumulated.

Possibly some plug-in for Firefox?

Previously in such situation I would keep an eye on the memory usage. Perhaps in KsysGuard and watch for a gradual increase in usage after starting some program or starting some activity. Or perhaps in htop with processes sorted by memory usage.

The last time I had this sort of issue was when running chrome, the Android IDE, and and some Android emulators all at the same time with only 8 GB of RAM.

I've had it easily running Chromium, and also multiple active overlapping windows in Firefox each running multiple YouTube videos and switching back and forth. The CPU grew warm ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-03-05 09:37 AM, Peter Suetterlin wrote:

James Knott wrote:

...

I'm running 15.1 & KDE.  One thing I've noticed is swap use increases through time, even though I'm not even using all the real memory. Eventually, it gets to the point where my system bogs down and can become unusable.  At the moment, I'm running 13.6 GiB of 15.6 memory and 4.1 of 24 swap.  Why should swap be used at all, when there's still a significant amount of free memory? What is actually using all this memory? If it is a *single* process, the issue likely is that parts of KDE/Plasma are swapped out (and rapidly pulled back again).

I have been unable to identify a problem app.

I encountered that with heavy image processing. The machine would be *completely* dead for half an hour or so, and once the processing finished, it was back healthy as before.

So if you really use that much memory regularly (and don't have a memory leak somewhere) then you have two options: - more RAM

I have 16 GB and the memory I need is no longer available.

- limit the amount of physical RAM a *single* program can occupy, to help the DE not being pushed to swap.

I wrote a post here about a year ago describing this second option, using memory cgroups. On my 32G laptop I create a group limited to 30G and add the voracious process to that group. So this will make that process start swapping when it needs more than 30G, leaving 2G RAM for the system to 'survive'. I could easily process 45G data cubes that way, without noticing much reduction in response of the GUI. Quick description (adapt names and sizes):

mkdir /sys/fs/cgroup/memory/30G echo 32212254720 > /sys/fs/cgroup/memory/30G/memory.limit_in_bytes chown root.users /sys/fs/cgroup/memory/30G/cgroup.procs chmod 775 /sys/fs/cgroup/memory/30G/cgroup.procs

Then, to add a process there, echo $PID > /sys/fs/cgroup/memory/30G/cgroup.procs

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

In summary, this is such a massive oversimplification that it i misleading. There's a large chink of 'yes it used to be but we changed all that', principally because this describes a roll-in/roll-out mindset of the UNIX V7 of the early 1980s. On 05/03/2020 13:12, Richmond wrote:

When linux detects that you haven't used a program for some time, it will swap it out and use the memory for buffers.

No, no, ten thousand times no! Linux does not think of 'programs' when it comes to virtual memory, it thinks of pages. It manages memory by having a linked list of pages. The position on the queue is indicative of how long since the page was last accessed. Actually the are two LRU queues: one is for immutable pages the other is for mutable pages. Code is immutable. I don't think Linux has any self-modifying code, but who knows :-) Mutable pages are for data. I'm not sure how 'constants' are handled.

The increased use of buffers supposedly makes the system more efficient.

That's an old programming axiom, but what makes 'buffers' in this setup is 'otherwise usable' memory. In reality there is one big linked list of memory and the Tw0-LRU is done by pointers. So not all memory needs to be on those two lists. How much goes there? Well there are about 40 other vm 'tuning' settings to play with. And there is a sophisticated algorithm.

How much linux will swap out will depend on swappiness, NO! 'Swappiness' controls how aggressive the swapping is compared to actual memory. This is a setting which control what some people call Linux's "predictive swapping". Again, it gets into the swap algorithms. Set to high (even the default of 60 is high enough to case predictive/pre-emptive swapping) and it swaps everything out to start with, and then has to swap back in to run!

and also on the amount of swap available. Linux is aiming to have buffers, but also to have free memory in case it suddenly needs to do something. This is why you see it swapping when there is memory available.

No. In one sense the buffers are 'available' memory. They can be consumed if needed, but how much memory is kept for the operation system to use (the purpose of buffers) is again a VM tunable parameter. Swap-out of a page happens when a data page that has been modified ('marked as dirty') ages out. There's no point swapping out a code page, you can just drop old ones. The startup code that processes the command line is a good example of aged code that is no longer needed.

Whether you change swappiness depends on what you are doing. If you have two programs running and you are occasionally switching between them with alt-tab, then there will be long pauses while it swaps back in the program it swapped out while you were not using it.

No. You are describing a roll-in/roll-out approach. A virtual memory system is concerned with the 'working set' of code that is involved in the running of the system. In addition, Linux uses shared libraries! For a simple switching such as you describe to cause paging in a VM system there must be very little memory to start with.

You can check which programs are using memory by running 'top' and pressing M, then the highest memory users will be at the top. Shared memory doesn't necessarily count though.

Most people solve the problem by buying so much memory it doesn't matter.

Nonsense! "Virtual memory means virtual performance" was the idiom from the 1960s when IBM and others fist implemented virtual memory with little understanding for the algorithms! Back the a IBM/370 with 256K of memory was typical. Linux is more sophisticated and can always use the memory, somehow. -- 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-03-05 09:24 PM, James Knott wrote:

On 2020-03-05 04:48 PM, Anton Aylward wrote:

...

Nonsense!  "Virtual memory means virtual performance" was the idiom from the 1960s when IBM and others fist implemented virtual memory with little understanding for the algorithms!  Back the a IBM/370  with 256K of memory was typical.  Linux is more sophisticated and can always use the memory, somehow.

My first experience with virtual memory was with DEC VAX 11/780 systems.  Prior to that, we had overlays, where portions of code were swapped into memory.  This was used with head per track disks.

Forgot to mention, between overlays and virtual memory, we had systems with paged memory, which had more memory than could be addressed by the CPU.  Blocks of memory were switched into the CPU address range as needed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/03/2020 03.24, James Knott wrote:

On 2020-03-05 04:48 PM, Anton Aylward wrote:

...

Nonsense! "Virtual memory means virtual performance" was the idiom from the 1960s when IBM and others fist implemented virtual memory with little understanding for the algorithms! Back the a IBM/370 with 256K of memory was typical. Linux is more sophisticated and can always use the memory, somehow.

My first experience with virtual memory was with DEC VAX 11/780 systems. Prior to that, we had overlays, where portions of code were swapped into memory. This was used with head per track disks.

I used overlays with MsDOS. Actually, a library of the compiler. At some point, we could create ramdisks with the memory beyond the first megabyte, that the system and programs could not use, and copy the overlay there. That was *fast* :-D -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 06/03/2020 11.27, Richmond wrote:

Anton Aylward <> writes:

...

No. In one sense the buffers are 'available' memory. They can be consumed if needed, but how much memory is kept for the operation system to use (the purpose of buffers) is again a VM tunable parameter.

No they are not available, they are occupied, they are being used as buffers, and it takes time to release them, during which the disk in use light comes on and there are delays.

I think (read) disk buffers are dropped instantly. It just means that the next disk read comes from disk, not from memory. But write buffer has to be written first. Or is it cache? -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 01/04/2020 21:29, James Knott wrote:

...

I'm going my both System Monitor and Top. 

I consider using swapon -s to be authoritative :-)

The thing is no matter how much swap is used, it runs fine, then suddenly the CPUs max out and the system bogs down.

There isa a fundamental difference between firefox and Chromium and and a side effect of how they handle data. Firstly, FF is a single process therefore a single allocation in the process table, whereas Chromium has a process per page. In terms of code &mapping that doesn't make any difference, but the way scheduling works and the way paging allocation buffer tables work it does. Sometimes, I suspect some long-lived images, Linux can re-map pages into BigPages. but these are unswapable. To much of that and the system will og down. I'm sure this is tunable. -- 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. [04-01-20 23:33]:

On 02/04/2020 03.55, Anton Aylward wrote:

...

On 01/04/2020 21:29, James Knott wrote:

...

There isa a fundamental difference between firefox and Chromium and and a side effect of how they handle data.

Firstly, FF is a single process

Was. Is no longer. By default nowdays it is 8.

I believe it is one per cpu unit. I have 12. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-04-02 05:04 AM, Dave Howorth wrote:

...

I believe it is one per cpu unit. I have 12. According tohttps://support.mozilla.org/en-US/kb/performance-settings and to the preference s on my browser, the default is 8.

Edit preferences. Scroll to Performance. Uncheck Use recommended performance settings You can then see how Content process limit is set and what the default is.

I just set it to 1.  I'll see if it makes a difference. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [04-02-20 07:36]:

On 02/04/2020 06.11, Patrick Shanahan wrote:

...

* Carlos E. R. [04-01-20 23:33]:

...

On 02/04/2020 03.55, Anton Aylward wrote:

...

On 01/04/2020 21:29, James Knott wrote:

...

There isa a fundamental difference between firefox and Chromium and and a side effect of how they handle data.

Firstly, FF is a single process

Was. Is no longer. By default nowdays it is 8.

I believe it is one per cpu unit. I have 12.

No... I had 4 cpu cores, and ff used 8, per configuration.

I have 6 cup cores and ff is using 12 pid USER PID %CPU %MEM VSZ RSS TTY paka 11213 13.5 5.6 5917384 2105752 ? paka 11395 2.0 3.5 4054872 1322064 ? paka 11502 1.8 2.3 3573100 885896 ? paka 11527 0.7 1.1 2986848 421124 ? paka 11555 27.2 6.5 7447324 2437448 ? _ paka 11583 0.8 1.5 3209148 584916 ? paka 11611 4.2 1.2 3193676 445400 ? paka 11639 0.8 1.1 3151424 423240 ? paka 11666 0.3 1.1 3099596 428564 ? paka 11800 0.6 1.0 28104472 405532 ? paka 12669 0.0 0.0 252740 35520 ? paka 10760 0.0 0.3 2461632 120516 ? MozillaFirefox-74.0-2.1.x86_64 openSUSE Tumbleweed 20200331 CPU: 6-Core: Intel Core i7 970 type: MT MCP arch: Nehalem speed: 1713 MHz min/max: 1596/3193 MHz -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Patrick Shanahan [04-02-20 07:57]:

* Carlos E. R. [04-02-20 07:36]:

...

On 02/04/2020 06.11, Patrick Shanahan wrote:

...

* Carlos E. R. [04-01-20 23:33]:

...

On 02/04/2020 03.55, Anton Aylward wrote:

...

On 01/04/2020 21:29, James Knott wrote:

...

There isa a fundamental difference between firefox and Chromium and and a side effect of how they handle data.

Firstly, FF is a single process

Was. Is no longer. By default nowdays it is 8.

I believe it is one per cpu unit. I have 12.

No... I had 4 cpu cores, and ff used 8, per configuration.

I have 6 cup cores and ff is using 12 pid

USER PID %CPU %MEM VSZ RSS TTY paka 11213 13.5 5.6 5917384 2105752 ? paka 11395 2.0 3.5 4054872 1322064 ? paka 11502 1.8 2.3 3573100 885896 ? paka 11527 0.7 1.1 2986848 421124 ? paka 11555 27.2 6.5 7447324 2437448 ? _ paka 11583 0.8 1.5 3209148 584916 ? paka 11611 4.2 1.2 3193676 445400 ? paka 11639 0.8 1.1 3151424 423240 ? paka 11666 0.3 1.1 3099596 428564 ? paka 11800 0.6 1.0 28104472 405532 ? paka 12669 0.0 0.0 252740 35520 ? paka 10760 0.0 0.3 2461632 120516 ?

MozillaFirefox-74.0-2.1.x86_64 openSUSE Tumbleweed 20200331 CPU: 6-Core: Intel Core i7 970 type: MT MCP arch: Nehalem speed: 1713 MHz min/max: 1596/3193 MHz

and FF Performance set to "Use recommended ..." unsetting "Use recommended ..." indeed indicates "content process limit" of 8, but my system is definitely using 12 pids. Unset "Use recommended ... ", issued "kill -9 $(pidof firefox)", restarted FF with "Use recommended ... " unset and FF utilizes 11 pids and doesn't seem to change with starting 10 new FF windows. Set "Use recommended ... ", killed current pids and restarted FF. FF is now utilizing 11 pids. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/04/2020 15.26, James Knott wrote:

On 2020-04-02 07:31 AM, Carlos E. R. wrote:

...

...

I believe it is one per cpu unit.  I have 12.

No... I had 4 cpu cores, and ff used 8, per configuration.

What about hyper-threading?

I don't know. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 02/04/2020 15.23, James Knott wrote:

On 2020-04-02 12:11 AM, Patrick Shanahan wrote:

...

...

Was. Is no longer. By default nowdays it is 8. I believe it is one per cpu unit.  I have 12.  My CPU has 4 real cores, with hyper-threading, 8.

As I mentioned, every now and then, something is pegging the CPUs and everything bogs down.  After that clears, it's back to normal. I leave System Monitor running, but sometimes I can't even switch to it.

You can have "top" dump the content periodically to a file, so that you can examine what happened after the event. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

* Carlos E. R. [04-02-20 09:50]:

On 02/04/2020 15.23, James Knott wrote:

...

On 2020-04-02 12:11 AM, Patrick Shanahan wrote:

...

...

Was. Is no longer. By default nowdays it is 8. I believe it is one per cpu unit.  I have 12.  My CPU has 4 real cores, with hyper-threading, 8.

As I mentioned, every now and then, something is pegging the CPUs and everything bogs down.  After that clears, it's back to normal. I leave System Monitor running, but sometimes I can't even switch to it.

You can have "top" dump the content periodically to a file, so that you can examine what happened after the event.

and/or test for a longer time with only ff or chrom running, not both. me-thinks chrom is *the* problem, but ... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-04-02 10:07 AM, Carlos E. R. wrote:

...

me-thinks chrom is *the* problem, but ...

I think the problem is using both at the same time (or more than two). They simply use a lot of memory and he doesn't have enough for that use. Thus restarting them works.

I have 2 Chromium browsers, 6 pages up all the time.  I have 7-8 Firefox browsers open, perhaps a dozen pages up most of the time, but over the day, I'll open and close several others. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-04-02 11:34 AM, Dave Howorth wrote:

...

I have 2 Chromium browsers, 6 pages up all the time.  I have 7-8 Firefox browsers open, perhaps a dozen pages up most of the time, but over the day, I'll open and close several others. What do you mean by a [firefox] browser? Do you mean an independently started instance, using a different profile, or do you just mean a separate window rather than a separate tab?

Separate windows.  I've never used profiles. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org