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? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* James Knott <james.knott@jknott.net> [03-04-20 10:49]:
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?
perhaps you need to adjust swappiness cat /proc/sys/vm/swappiness Swappiness is the kernel parameter that defines how much (and how often) your Linux kernel will copy RAM contents to swap. This parameter's default value is “60” and it can take anything from “0” to “100”. The higher the value of the swappiness parameter, the more aggressively your kernel will swap. sysctl vm.swappiness vm.swappiness = 60 isn't google amazing! -- (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 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
* James Knott <james.knott@jknott.net> [03-04-20 11:23]:
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 guess you need to re-read my previous post. I made/make no recommendation. I have no swap but do have 36G system memory: total used free shared buff/cache available Mem: 36945868 10509404 2578052 678908 23858412 25247156 Swap: 0 0 0 -- (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 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
Am 04.03.20 um 17:52 schrieb James Knott:
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?
i do not think so: again, if i read your first post correct, you reached it: 1) 13.6+4.1=17.7 17.7 > 15.6 and if i remember correct some other posts, if you do not have swap and you reach memory limit, kernel will kill some running programms, and this will lead into unusable system, if you have bad luck. simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* James Knott <james.knott@jknott.net> [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
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 -- 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 04/03/2020 18.04, James Knott wrote:
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
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. [...] Ok, read the entire post, no figures. Please do this. Open "top" in a terminal. Press 'f'. Make sure that the "SWAP" column is enabled. Move to the line "SWAP = Swapped Size (KiB)", press the "SPACE BAR" to activate, then "right arrow" to highlight, then up arrow to move to a suitable place, like just below "SHR = Shared Memory (KiB)". Then go to the " RES = Resident Size (KiB)" line and press "s" (changes sort order). 'q' returns to the normal display. "W" writes the configuration changes (to .config/procps/toprc; just delete to restore defaults). That way, top will display heavy memory users. Then, copy and paste here the first dozen lines. My guess: you are simply using a lot of memory. The system frees ram by sending it to swap, so that you "see" free ram. You are using Mozilla apps, more than one. They use LOTS of ram. Simply restart them at least once a day. You also use Chrome. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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
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.
If it is happening then it is symptomatic of something wrong. A faster swap with SSD wont fix it.
It does. I'm using it. The system changed the day I did. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 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. He has 16 GiB, but 8 of them are tied with Virtualbox. So he has 8, same as me. Three browsers and Thunderbird? Machine trashes. Yet he sees free ram, but this is not what it seems because "swap off" fails because there is not enough ram. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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
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? I use mostly old machines and I always could find ram, sometime second hand jdd -- http://dodin.org -- 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
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? jdd -- http://dodin.org -- 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" <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 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. -- 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 <james.knott@jknott.net> 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 2020-03-07 05:55 PM, Dave Howorth wrote:
On Sat, 7 Mar 2020 17:15:25 -0500 James Knott <james.knott@jknott.net> 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.. -- 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 <james.knott@jknott.net> wrote:
On 2020-03-07 05:55 PM, Dave Howorth wrote:
On Sat, 7 Mar 2020 17:15:25 -0500 James Knott <james.knott@jknott.net> 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
On 2020-03-07 06:23 PM, 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. -- 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/B00J8E90NW/ref=dp_ob_title_wld?pldnSite=1> $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 Sat, 7 Mar 2020 17:15:25 -0500 James Knott <james.knott@jknott.net> 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?!) -- 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 <james.knott@jknott.net> 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 Sun, 8 Mar 2020 00:08:57 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 07/03/2020 23.57, Dave Howorth wrote:
On Sat, 7 Mar 2020 17:15:25 -0500 James Knott <james.knott@jknott.net> 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.
No I mean the body colour of the product as shown on the page I linked. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
* James Knott <james.knott@jknott.net> [03-08-20 09:52]:
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?
no, so you can see the Christmas lights -- (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 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)
On 2020-03-07 05:57 PM, Dave Howorth wrote:
The replacement is out of stock. PS Since when has memory had a colour? (especially one that affects the price?!)
I also wondered about that. With WD disks, the colour indicates intended application. -- 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 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
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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [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
On 05/03/2020 21.28, Patrick Shanahan wrote:
* 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.
Can you give any solution? Using the same applications, the same machine, the same ram. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 05/03/2020 22.53, Per Jessen wrote:
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.
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". :-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 05/03/2020 23.34, James Knott wrote:
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.
No, it doesn't have enough. You tried "swap off" and it failed with "Cannot allocate memory", which proves that at that instant you did not have enough RAM and it was using swap because it really needed it. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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
Hey, long time no see :-) On 02/04/2020 01.38, L A Walsh wrote:
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.
Right. That's the idea.
A PCIe (sits in a motherboard slot instead in harddisk form) would help drastically, but better would be to increase main memory.
Ah, that I just did :-) I bought a new motherboard with 32 gigs. Know what? It uses swap, this afternoon 3.5 gigs. Tracker something was using 1.5 gigs. Then I had to zypper up and reboot. Well, it uses swap because I hibernate it. And when it wakes up, things that are not used remain in swap, for days if need be. Even if there are 22 free gigs of RAM. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 05/03/2020 16.41, James Knott wrote:
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:
Yes, you have mentioned it. I want to see command output instead of your words.
"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. top display sorted by "SWAP": top - 20:33:58 up 12 days, 6:48, 1 user, load average: 0,62, 0,81, 0,76 Tasks: 479 total, 2 running, 476 sleeping, 0 stopped, 1 zombie %Cpu(s): 2,1 us, 0,8 sy, 0,3 ni, 96,2 id, 0,6 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161256 total, 1960292 free, 5420404 used, 780560 buff/cache KiB Swap: 25165820 total, 20751732 free, 4414088 used. 2129424 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 11223 cer 20 0 3883488 511440 93280 202884 S 3,274 6,267 84:14.16 Web Content 4992 cer 39 19 963220 26644 3252 190496 S 0,000 0,326 0:55.20 tracker-miner-f 5927 vscan 20 0 1113320 704716 4492 181520 S 0,000 8,635 9:07.82 clamd 11145 cer 20 0 3452964 228804 65024 174048 S 1,190 2,804 31:08.62 Web Content 5844 cer 20 0 4990712 1,708g 81260 170336 S 0,000 21,94 63:51.95 thunderbird-bin 11198 cer 20 0 3752028 325884 64352 154768 S 1,190 3,993 192:53.42 Web Content 2255 named 20 0 501180 33632 5268 134612 S 0,000 0,412 0:17.07 named 8921 cer 20 0 3658964 188504 56576 129396 S 0,298 2,310 10:12.05 firefox 11180 cer 20 0 3240976 228932 42308 91500 S 0,000 2,805 5:13.81 Web Content 3948 root 20 0 214388 2936 2340 85976 S 0,000 0,036 0:00.20 spamd child 3949 root 20 0 214388 2968 2340 85944 S 0,000 0,036 0:00.16 spamd child 3944 root 20 0 214388 6736 5260 85096 S 0,000 0,083 0:22.90 spamd 11031 cer 20 0 4115616 461260 138548 80988 S 0,595 5,652 50:54.62 firefox 9060 cer 20 0 2967568 153376 56080 79528 S 0,893 1,879 24:02.97 Web Content 2280 mysql 20 0 1885328 4644 4644 73132 S 0,000 0,057 0:54.37 mysqld 9006 cer 20 0 2949816 89724 25816 71244 S 0,298 1,099 24:47.55 Web Content 9085 cer 20 0 2847372 101404 29228 69504 S 0,595 1,243 20:31.11 Web Content 9042 cer 20 0 2848780 79296 35912 68052 S 0,595 0,972 15:57.69 Web Content 4974 cer 39 19 2846584 21156 4564 60904 S 0,000 0,259 0:21.43 tracker-extract 5990 vscan 20 0 192460 5944 5044 59724 S 0,000 0,073 0:02.53 /usr/sbin/amavi 4082 root 20 0 661460 153056 120272 57828 S 0,595 1,875 19:47.05 X 4400 cer 20 0 1048084 49404 9984 44764 S 0,298 0,605 5:41.71 xfce4-terminal 9123 cer 20 0 2659232 23960 8560 40436 S 0,000 0,294 0:18.12 WebExtensions 5263 cer 20 0 679968 8888 4220 39492 S 0,000 0,109 0:15.12 gnote 2480 vscan 20 0 193900 29588 5860 36920 S 0,000 0,363 0:00.76 /usr/sbin/amavi 2576 vscan 20 0 193996 29612 5816 36872 S 0,000 0,363 0:00.35 /usr/sbin/amavi 9459 cer 20 0 2639636 4712 3540 35184 S 0,000 0,058 0:00.91 Web Content 4097 colord 20 0 340960 2452 2452 34832 S 0,000 0,030 0:00.86 colord 11277 cer 20 0 26,724g 103100 20304 34180 S 0,000 1,263 3:18.31 WebExtensions top display sorted by "RES": top - 20:37:57 up 12 days, 6:52, 1 user, load average: 0,56, 0,60, 0,68 Tasks: 487 total, 1 running, 485 sleeping, 0 stopped, 1 zombie %Cpu(s): 3,5 us, 0,7 sy, 0,0 ni, 89,5 id, 6,4 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161256 total, 1872216 free, 5398892 used, 890148 buff/cache KiB Swap: 25165820 total, 20745332 free, 4420488 used. 2087988 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5844 cer 20 0 4990712 1,713g 82796 170404 S 0,298 22,01 64:00.01 thunderbird-bin 5927 vscan 20 0 1113320 701420 4492 184816 S 0,000 8,595 9:07.82 clamd 11223 cer 20 0 3879392 510844 95548 202936 S 1,190 6,259 84:23.94 Web Content 11031 cer 20 0 4118688 474464 144216 80992 S 0,298 5,814 50:59.23 firefox 11198 cer 20 0 3752028 329944 65484 154792 S 1,190 4,043 192:56.10 Web Content 11145 cer 20 0 3452964 239920 73076 174056 S 1,190 2,940 31:11.80 Web Content 11180 cer 20 0 3240976 233540 44904 91496 S 0,000 2,862 5:14.11 Web Content 8921 cer 20 0 3658964 191868 58384 129408 S 0,298 2,351 10:12.59 firefox 4082 root 20 0 661460 150836 120168 59944 S 1,190 1,848 19:50.69 X 9060 cer 20 0 2967568 142576 56012 79532 S 0,595 1,747 24:05.13 Web Content 5088 cer 20 0 3977920 132752 296 0 S 0,000 1,627 0:18.41 java 11277 cer 20 0 26,724g 105024 20572 34180 S 0,000 1,287 3:18.55 WebExtensions 9006 cer 20 0 2949816 92776 25864 71256 S 0,893 1,137 24:49.66 Web Content 9042 cer 20 0 2848780 83036 35932 68052 S 0,595 1,017 15:59.07 Web Content 9085 cer 20 0 2847372 64452 28980 69512 S 2,679 0,790 20:33.06 Web Content 4400 cer 20 0 1048084 49400 9980 44764 S 1,190 0,605 5:42.40 xfce4-terminal 4374 cer 20 0 676856 46988 15836 16092 S 0,298 0,576 0:23.72 xfdesktop 4395 cer 20 0 1362308 40748 17136 32396 S 0,000 0,499 1:36.40 pidgin 2255 named 20 0 501180 33632 5268 134612 S 0,000 0,412 0:17.09 named 31650 news 20 0 39612 33576 1920 312 S 0,000 0,411 0:00.19 leafnode 2576 vscan 20 0 193996 29600 5816 36884 S 0,000 0,363 0:00.35 /usr/sbin/amavi 2480 vscan 20 0 193900 29588 5860 36920 S 0,000 0,363 0:00.76 /usr/sbin/amavi 4992 cer 39 19 963220 26628 3252 190512 S 0,000 0,326 0:55.23 tracker-miner-f 4333 cer 20 0 719040 25408 12536 22156 S 0,000 0,311 0:14.11 Thunar 4405 cer 20 0 1651656 25404 8884 25904 S 0,000 0,311 0:12.57 keepassxc 9123 cer 20 0 2659232 23952 8560 40444 S 0,000 0,293 0:18.15 WebExtensions 9880 cer 20 0 169700 22796 6636 21484 S 0,000 0,279 0:53.31 alpine 31651 news 20 0 28956 22736 1936 388 S 0,000 0,279 0:00.12 leafnode 5013 cer 20 0 573352 22076 2352 0 S 0,000 0,270 0:00.57 xfce4-appfinder As you can see, I have about 4.4 GiB of swap in use, while 2 GiB of ram are "available" (different "available meaning than I used above). A bit less is free, 800MiB in buffers/cache, thanks to the kernel sending unused portions to swap. You can see that this instant Thunderbird has 1.7 GiB of RAM, a huge application. BUT, my machine is perfectly usable, thanks to swap being in SSD, not rotating rust - simply because searching for the chunks of memory swapped out means moving the disk head a lot. Now post yours. Data, not your interpretations, please :-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 05/03/2020 21.08, James Knott wrote:
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.
The comand is "top", and I posted detailed instructions this morning.
Please do this.
Open "top" in a terminal. Press 'f'. Make sure that the "SWAP" column is enabled. Move to the line "SWAP = Swapped Size (KiB)", press the "SPACE BAR" to activate, then "right arrow" to highlight, then up arrow to move to a suitable place, like just below "SHR = Shared Memory (KiB)".
Then go to the " RES = Resident Size (KiB)" line and press "s" (changes sort order).
'q' returns to the normal display. "W" writes the configuration changes (to .config/procps/toprc; just delete to restore defaults).
That way, top will display heavy memory users.
Then, copy and paste here the first dozen lines.
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 05/03/2020 21.48, James Knott wrote:
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
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: 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 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 I still miss lines, sorry. Where are the headers? Please, just do it like I did: top display sorted by "RES": top - 20:37:57 up 12 days, 6:52, 1 user, load average: 0,56, 0,60, 0,68 Tasks: 487 total, 1 running, 485 sleeping, 0 stopped, 1 zombie %Cpu(s): 3,5 us, 0,7 sy, 0,0 ni, 89,5 id, 6,4 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161256 total, 1872216 free, 5398892 used, 890148 buff/cache KiB Swap: 25165820 total, 20745332 free, 4420488 used. 2087988 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5844 cer 20 0 4990712 1,713g 82796 170404 S 0,298 22,01 64:00.01 thunderbird-bin 5927 vscan 20 0 1113320 701420 4492 184816 S 0,000 8,595 9:07.82 clamd 11223 cer 20 0 3879392 510844 95548 202936 S 1,190 6,259 84:23.94 Web Content 11031 cer 20 0 4118688 474464 144216 80992 S 0,298 5,814 50:59.23 firefox 11198 cer 20 0 3752028 329944 65484 154792 S 1,190 4,043 192:56.10 Web Content 11145 cer 20 0 3452964 239920 73076 174056 S 1,190 2,940 31:11.80 Web Content 11180 cer 20 0 3240976 233540 44904 91496 S 0,000 2,862 5:14.11 Web Content 8921 cer 20 0 3658964 191868 58384 129408 S 0,298 2,351 10:12.59 firefox 4082 root 20 0 661460 150836 120168 59944 S 1,190 1,848 19:50.69 X 9060 cer 20 0 2967568 142576 56012 79532 S 0,595 1,747 24:05.13 Web Content 5088 cer 20 0 3977920 132752 296 0 S 0,000 1,627 0:18.41 java 11277 cer 20 0 26,724g 105024 20572 34180 S 0,000 1,287 3:18.55 WebExtensions 9006 cer 20 0 2949816 92776 25864 71256 S 0,893 1,137 24:49.66 Web Content 9042 cer 20 0 2848780 83036 35932 68052 S 0,595 1,017 15:59.07 Web Content 9085 cer 20 0 2847372 64452 28980 69512 S 2,679 0,790 20:33.06 Web Content 4400 cer 20 0 1048084 49400 9980 44764 S 1,190 0,605 5:42.40 xfce4-terminal 4374 cer 20 0 676856 46988 15836 16092 S 0,298 0,576 0:23.72 xfdesktop 4395 cer 20 0 1362308 40748 17136 32396 S 0,000 0,499 1:36.40 pidgin 2255 named 20 0 501180 33632 5268 134612 S 0,000 0,412 0:17.09 named 31650 news 20 0 39612 33576 1920 312 S 0,000 0,411 0:00.19 leafnode 2576 vscan 20 0 193996 29600 5816 36884 S 0,000 0,363 0:00.35 /usr/sbin/amavi 2480 vscan 20 0 193900 29588 5860 36920 S 0,000 0,363 0:00.76 /usr/sbin/amavi 4992 cer 39 19 963220 26628 3252 190512 S 0,000 0,326 0:55.23 tracker-miner-f 4333 cer 20 0 719040 25408 12536 22156 S 0,000 0,311 0:14.11 Thunar 4405 cer 20 0 1651656 25404 8884 25904 S 0,000 0,311 0:12.57 keepassxc 9123 cer 20 0 2659232 23952 8560 40444 S 0,000 0,293 0:18.15 WebExtensions 9880 cer 20 0 169700 22796 6636 21484 S 0,000 0,279 0:53.31 alpine 31651 news 20 0 28956 22736 1936 388 S 0,000 0,279 0:00.12 leafnode 5013 cer 20 0 573352 22076 2352 0 S 0,000 0,270 0:00.57 xfce4-appfinder -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 2020-03-05 03:58 PM, 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.
Try again 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 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 -- 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 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.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 05/03/2020 22.47, Carlos E. R. wrote:
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.
Ah, application finder. It was hidden behind the post I was writing to you. No, that is fast here. It is Thunderbird which is slow. Not surprising as it eats 1.7 gigs this moment. -- 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
On 06/03/2020 03.21, James Knott wrote:
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.
Yes, I get the equivalent, I had forgotten. And for some reason, it pops behind other windows, so I momentarily thought it did not work. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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
* James Knott <james.knott@jknott.net> [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"). I am sure that I am not alone in not being interested in editing the data you provide in order to read it. tldnr -- (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.15, Patrick Shanahan wrote:
* James Knott <james.knott@jknott.net> [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)
* Carlos E. R. <robin.listas@telefonica.net> [03-07-20 14:21]:
On 07/03/2020 20.15, Patrick Shanahan wrote:
* James Knott <james.knott@jknott.net> [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. -- (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 <paka@opensuse.org> [03-07-20 14:23]:
* Carlos E. R. <robin.listas@telefonica.net> [03-07-20 14:21]:
On 07/03/2020 20.15, Patrick Shanahan wrote:
* James Knott <james.knott@jknott.net> [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 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. What are you using to read the message? I'm using Seamonkey. Konsole is set for 80 x 24. -- 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 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
On 2020-03-07 03:02 PM, Carlos E. R. wrote:
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
If that's what those settings result in, then yes.
http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird 6 Advanced 6.1 Flowed format
Actually, I use Seamonkey for most of my email. I prefer it to Thunderbird.
Then, I suppose you use this addon:
<http://git.kiszka.org/togglewordwrap.git/> (Toggle Word Wrap by Jan Kiszka)
Never heard of it. -- 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 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
* Carlos E. R. <robin.listas@telefonica.net> [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. -- (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 21.54, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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)
On 07/03/2020 21.54, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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). -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [03-07-20 16:11]:
On 07/03/2020 21.54, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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: <opensuse+bounces-224070-paka=opensuse.org@opensuse.org> 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 <paka@localhost> (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 <ptilopteri@att.net>; 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 <paka@opensuse.org>; 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 <paka@opensuse.org>; 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 <opensuse@lists5.opensuse.org>; 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 <opensuse@opensuse.org>; Sat, 7 Mar 2020 18:42:56 +0000 (UTC) Received: by mail-qv1-f68.google.com with SMTP id u17so2559222qvv.7 for <opensuse@opensuse.org>; 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 <opensuse@opensuse.org> (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: <af41cfd6-57e4-c47c-80f6-04993ada2361@jknott.net> <20200304161401.GU25664@wahoo.no-ip.org> <d909061a-27df-3656-289a-169eded96cf9@jknott.net> <20200304164800.GW25664@wahoo.no-ip.org> <552836be-44df-ba0c-7ba9-5bf0931119e1@jknott.net> <20200304170029.GY25664@wahoo.no-ip.org> <a7da08aa-3162-3600-1c4d-4b2ecc9f09fc@jknott.net> <96e190d2-b6eb-f8b5-6aca-9ec09fb4c09a@telefonica.net> <7b279dc6-0911-8cc7-3ee0-d3f2703435e4@jknott.net> <40055d6e-6b5b-7593-7bda-846402cf2503@telefonica.net> <fb257d56-c581-0f5f-cfeb-17efc62959bd@jknott.net> <baa948ca-d698-856d-3cbc-7a34c9efc648@telefonica.net> <ce3b531b-666e-e3c4-f7aa-c2150eb96c3b@jknott.net> <14c12465-94fd-d706-339c-bd59c6397477@telefonica.net> <4bd4588e-f06d-7939-daa6-bea52a79e8fe@jknott.net> <8193fd4a-bedf-7f1d-afa2-47735000ddfb@telefonica.net> <bd275f3c-53ce-10f8-be06-2a5be6c3ad03@jknott.net> <ed9079f0-7872-c107-f0e7-c9617826c64c@telefonica.net> From: James Knott <james.knott@jknott.net> 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: <ed9079f0-7872-c107-f0e7-c9617826c64c@telefonica.net> 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
On 07/03/2020 23.25, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [03-07-20 16:11]:
On 07/03/2020 21.54, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [03-07-20 18:18]:
On 07/03/2020 23.25, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [03-07-20 16:11]:
On 07/03/2020 21.54, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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
* James Knott <james.knott@jknott.net> [03-07-20 14:33]:
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.
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. -- (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 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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sat, 7 Mar 2020 23:00:06 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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
On 08/03/2020 00.05, Dave Howorth wrote:
On Sat, 7 Mar 2020 23:00:06 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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: <qukunv.r7o.1@ID-201911.user.individual.net> From: Frank Slootweg <this@ddress.is.invalid> 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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [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." <robin.listas@telefonica.net> 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: <qukunv.r7o.1@ID-201911.user.individual.net> From: Frank Slootweg <this@ddress.is.invalid> 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
-----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).
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. And when going into edit/reply mode, the returns are obeyed, anyway. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXmRTAxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVqX0AnRVF2XKLLyGn3MnTuSnr 1Myqfw9AAJ96U3STWQNIY317omOtg7NDYpDOVA== =vZUL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Carlos E. R. <robin.listas@telefonica.net> [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 08/03/2020 03.33, Patrick Shanahan wrote:
* Carlos E. R. <> [03-07-20 21:09]:
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 it has lines wrapped, yes, I know.
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.
Again, it wraps because it has line returns in the middle of the long lines, and not on the short lines. The point is that thunderbird *ignores* those carriage returns when it displays the post, and the text displays *not* wrapped, precisely because it was sent "flowed". That's the thing, the text is "flowed" but it contains returns. In a "clever" program, the returns in the middle of the lines are ignored and the "top" ouput shows correctly. On a client that does not understand this feature, the lines are cut at the return chars. The text is "sent" like this: ............ .... ............ .... ......... But in a clever client, it displays : ................ ................ ......... as you saw in the photo I posted. But your client is *not* clever. How does it know that ............S ....H ............S ....H .........H some returns are soft and others are hard, I do not know. And this was not done by James, it simply is the default for Thunderbird and apparently Seamonkey. Just read http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird 6 Advanced 6.1 Flowed format for more info. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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
On 2020-03-07 02:25 PM, James Knott wrote:
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
Also, in Send Format, I have opensuse.org in the list of plain text domains, as I do with other mail lists. -- 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 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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.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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 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. :-\ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 8 Mar 2020 23:26:13 -0400 James Knott <james.knott@jknott.net> 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-09 06:55 AM, Carlos E. R. wrote:
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.
At the moment top shows 624 MiB free and System Monitor shows 13.1 GiB memory and 5.5 swap used.. System is responsive and there's little disk activity. It will continue on like this for some time, at which point there will be a lot of disk activity and CPU will be pretty much pegged. At the moment CPU activity, on all 8 cores, is about 15-20%, with peaks to 25%. The disk LED flashes occasionally. This is with VirtualBox running, along with several browser windows, a couple of PDFs in Okular, email and Amarok playing music.. In short, a normally functioning computer. -- 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:
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 05/03/2020 22.02, 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:
BTW, I have an eye infection, which is making it difficult for me to focus on what I'm doing. Even reading is difficult.
Oh, sorry. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 2020-03-04 12:21 PM, Anton Aylward wrote:
As i said, using vmstat with a 10-15 second interval lets you look back and see the burst of activity.
It just happened and when I was finally able to switch to it, I didn't see anything out of the ordinary. However the system monitor showed the CPU pegged. -- 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
Am 04.03.20 um 16:46 schrieb James Knott:
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?
1) 13.6+4.1=17.7 17.7 > 15.6 i GUESS, kernel will let a amount of ram free to be fast, with other words, kernel will copy more to disk to have for next time some apps need memory some free space in ram. 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 simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* James Knott <james.knott@jknott.net> [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 04/03/2020 11:34, James Knott wrote:
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.
It is rendering that takes memory=swap You see the same with Dolphin rendering (slightly larger) thumbnails or Gwenview stepping through your MyGraphics folder -- 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 04/03/2020 10:46, 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?
Check out articles on Linux doing 'pre-emptive swap", that is swapping ahead of time "just in case it is needed at some time". I find the concept a bit somewhere on the spectrum between 'stupid' and 'obnoxious'. Of course, adjusting 'swappiness' and other VM tuning an prevent it. You might also try running vmstat in a xterm. vmstat -SM -a 15 Adjust the internal to suit. When there is a problem, switch to the window to see what the VM was and the disk was doing prior. It's the activity, perpendicularly the disk activity, particularly VM thrashing, that kills system performance. My personal experience: I've been running with a lot of thunderbird accounts, a couple of Firefox windows, half a dozen console shell. Intermittently I run Librre Office. All is well until ... a) I do things that require a LOT of RENDERING that may be due to graphics in Dolphin thumbnails, a lot of FF pages with graphics, a third FF window with YouTube or photo-processing applications. b) some things (such as the above) that require a lot of caching. At that point, a 'reluctance to swap' works against performance. PLEASE DO NOT CONFUSE VM PAGING WITH ROLL-IN/ROLL-OUT SWAP !!! We've inherited the term 'swap' and the allocation of 'swap space' on the disk from the old UNIX V6/V7 days when the system did swap in and out whole processes. A really smart and well equipped PDP-11 just did Do_bulk_DMA(pointer to memory, pointer to disk starting block, number of 512 blocks). Since the DMA was built into the disk controller and the control blocks for this were in memory and could be chained, a series of such operations could be set up and run on the alternative memory access bus while the CPU was off running some other memory resident process. No wonder we could get 40 shell user doing development on a PDP-11/45 with 4meg of memory. I kid you not. But doing graphics with the CPU is a killer. Off-loading that to a really smart rendering engine and having a really smart protocol (which I'm far from convinced we don't have!) will also affect performance. But under normal circumstances, turning down swappiness helps. # grep swap /etc/sysctl.conf # See https://unix.stackexchange.com/questions/88693/why-is-swappiness-set-to-60-b... vm.swappiness = 10 Or you could have it set in the kernel by means of Dracut, but that's another, less visible can of worms. -- 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 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 -- 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
* James Knott <james.knott@jknott.net> [03-04-20 21:09]:
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.
try running one or the other rather than both at the same time. both are probably not contributing to you running out of memory. -- (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 04/03/2020 22:22, Patrick Shanahan wrote:
* James Knott <james.knott@jknott.net> [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
* Anton Aylward <opensuse@antonaylward.com> [03-05-20 08:42]:
On 04/03/2020 22:22, Patrick Shanahan wrote:
* James Knott <james.knott@jknott.net> [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.
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 handy tool. -- (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-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 <james.knott@jknott.net> [03-05-20 10:50]:
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.
and you will not be able to identify if one or the other of your browsers is causing you concern until you eliminate one from the equastion. Is it too difficult to run only one for a while? no one can help you unless you accept and follow suggestions designed to determine the cause of your problem. repeat, repeat ... repeat ... -- (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
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 2020-03-05 09:23 AM, Peter Suetterlin wrote:
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?
According to the System Monitor, both drop. I'll wait until I'm using significant swap to verify. -- 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 08:37 AM, Anton Aylward wrote:
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.
I know what thrashing is. This heavy disk activity seems to happen after several hours, runs for a few minutes and then back to normal. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/03/2020 16.46, 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?
Usually, you still have free memory thanks to be using swap. Or, you have more free memory thanks to sending unused chunks to swap. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 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 - 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
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
James Knott <james.knott@jknott.net> writes:
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 looked into this some time ago, and will probably doing so again as I am now reduced to using a system with 1.5G of RAM. When linux detects that you haven't used a program for some time, it will swap it out and use the memory for buffers. The increased use of buffers supposedly makes the system more efficient. How much linux will swap out will depend on swappiness, 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. 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. 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. -- 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 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. -- 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 Thu, 5 Mar 2020 21:28:09 -0500 James Knott <james.knott@jknott.net> wrote:
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.
There's a pretty good summary of the history of virtual memory and thrashing at http://denninginstitute.com/pjd/PUBS/bvm.pdf
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.
If you're thinking of the same thing as me, we usually called that 'banked' memory. -- 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)
Anton Aylward <opensuse@antonaylward.com> writes:
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.
I didn't mean all of the program, obviously.
How much linux will swap out will depend on swappiness, NO! 'Swappiness' controls how aggressive the swapping is compared to actual
That's what I meant, how much it swaps, as in how much swapping it does.
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.
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.
Well yes there was very little memory. Not enough, hence the swapping. How much memory do you have in your system? I have 1.5G. There is enough to run firefox, but not enough to run firefox and thunderbird at the same time. So I watch it swapping, see it happening, see what it's like to use a system when it is swapping. See what it's like to press alt-tab and then wait for the disk light to go out. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 06/03/2020 05:27, Richmond wrote:
Anton Aylward <opensuse@antonaylward.com> writes:
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.
I didn't mean all of the program, obviously.
And I didn't mean ANY of the program, Linux does NOT swap out code pages. Of course your definition of 'program' might include non-initialized data. My idea of a 'program' is something that manipulates the data.
How much linux will swap out will depend on swappiness, NO! 'Swappiness' controls how aggressive the swapping is compared to actual
That's what I meant, how much it swaps, as in how much swapping it does.
No, the degree of swapping, once it is initiated, when it will stop, is another parameter. The threshold at which it is triggered by the number of 'dirty' (that is modified and hence need to be 'preserved') pages are all factors. The algorithms that Linux uses for VM are quite sophisticated.
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.
That's not what I'm seeing when I run vmstat to watch watch the activity you describe.
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.
How much memory do you have in your system? I have 1.5G. There is enough to run firefox, but not enough to run firefox and thunderbird at the same time.
If you run 'top' and alter the display you can show, in additional, for each process, how much it's working set is, how much code and data it is actually using, what its dirty page (modified data) is, and what's swapping. This is not the default, you have to set it up to specifically display these items. Asking me is not relevant. My TB has 19 remote imap accounts, two gmail accounts, and two local dovecot accounts. What's yours? My firefox has three windows each with between 200 and 500 tabs. What's yours?
So I watch it swapping, see it happening, see what it's like to use a system when it is swapping.
It's not that my system doesn't freeze. But it's not because of the above. It freezes on network activity. I run vmstat and netstat and see that there is no swapping during those freezes. Remember, network includes sockets that are for IPC between programs, controlling them over dbus and the like as well.
See what it's like to press alt-tab and then wait for the disk light to go out.
When I run 'top' I see that both FF and TB have the top residency as well as the top working set. -- "Your time is the grestest gift you can give someone" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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?
It was used at some point, but although there is now free memory, the applications have not had reason to access the swapped out memory, so it remains in use. -- Per Jessen, Zürich (8.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/03/2020 02:55, Per Jessen 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?
It was used at some point, but although there is now free memory, the applications have not had reason to access the swapped out memory, so it remains in use.
That makes sense. It would help in this sort of explanation if you used the term 'pages' instead of 'memory'. It would also help if you remembered that only data and not code pages were ever swapped out. -- 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/04 07:46, 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?
On 2020/03/04 07:46, 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?
How are you calculating free memory? I.e. on my server right now shows 96M free out of 165G, but almost 160 of that memory is file system cache. (using free command). If you are actively swapping, you are trying to put more in memory that wants to fit. I keep swap around at linus's suggestion because there are something that are used at boot time, but not really used again, so they can be moved to swap freeing up real memory. Right now with uptime:
uptime 16:27pm up 47 days 1:16, 3 users, load average: 0.19, 0.20, 0.18 free shows: free total used free shared buff/cache available Mem: 165050452 4300396 960160 2588 159789896 159551156 Swap: 8393924 13836 8380088
And that's stable for my usage, I don't really use more swap than that. But it's 13.8MB memory that is freed up for file cache usually. Load:0.69 Threads: 526 Cpu: 5.8% -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-04-01 07:33 PM, L A Walsh wrote:
On 2020/03/04 07:46, 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?
On 2020/03/04 07:46, 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? How are you calculating free memory? I.e. on my server right now shows 96M free out of 165G, but almost 160 of that memory is file system cache.
(using free command). If you are actively swapping, you are trying to put more in memory that wants to fit.
I keep swap around at linus's suggestion because there are something that are used at boot time, but not really used again, so they can be moved to swap freeing up real memory. Right now with uptime:
uptime 16:27pm up 47 days 1:16, 3 users, load average: 0.19, 0.20, 0.18 free shows: free total used free shared buff/cache available Mem: 165050452 4300396 960160 2588 159789896 159551156 Swap: 8393924 13836 8380088
And that's stable for my usage, I don't really use more swap than that. But it's 13.8MB memory that is freed up for file cache usually. Load:0.69 Threads: 526 Cpu: 5.8%
I'm going my both System Monitor and Top. What I've noticed is every now and then, the CPUs max out for a few minutes. It seems to have something to do with Firefox and Chromium browsers, though I can't say for certain. Killing them certainly reduces swap and memory use. This system has an i7 CPU, with 8 cores (4 virtual). The thing is no matter how much swap is used, it runs fine, then suddenly the CPUs max out and the system bogs down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [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 Thu, 2 Apr 2020 00:11:17 -0400 Patrick Shanahan <paka@opensuse.org> wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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.
According to https://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. -- 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
On 02/04/2020 06.11, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [04-02-20 07:36]:
On 02/04/2020 06.11, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2020-04-02 at 07:54 -0400, Patrick Shanahan wrote:
* 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
You probably changed the configuration and then forgot about it :-)
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 currently I have 12 cores, and still 4 firefox childs. <https://support.mozilla.org/en-US/kb/performance-settings?as=u&utm_source=inproduct> - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXoXT9Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVNO8Ani/YhAN5XlQ/nfyaWFVj DRc2hZlFAJ911bOG1b7dcqJQYuTOibN19CFdBw== =Xp4p -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [04-02-20 07:57]:
* Carlos E. R. <robin.listas@telefonica.net> [04-02-20 07:36]:
On 02/04/2020 06.11, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [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 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? -- 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 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
On 2020-04-02 09:36 AM, Carlos E. R. wrote:
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.
As I mentioned, the problem appears to be caused by Firefox and Chromium. By killing them, I can restore performance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Carlos E. R. <robin.listas@telefonica.net> [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 02/04/2020 15.53, Patrick Shanahan wrote:
* 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 ...
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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 Thu, 2 Apr 2020 10:33:23 -0400 James Knott <james.knott@jknott.net> wrote:
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.
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? -- 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
On Thu, 2 Apr 2020 11:35:54 -0400 James Knott <james.knott@jknott.net> wrote:
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.
Ah, OK. It makes no difference whether you use separate windows or tabs, AFAIK. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-04-02 12:02 PM, Dave Howorth wrote:
Separate windows. I've never used profiles. Ah, OK. It makes no difference whether you use separate windows or tabs, AFAIK.
I use tabs when I have related pages open. For example, in Chromium, I have Google Mail, Calendar, Contacts and Messenger all on the same windows, but different tabs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* James Knott <james.knott@jknott.net> [04-02-20 10:36]:
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.
You are trying to solve a problem. Remove ONE variable and observe. Divide and conquer. Has been suggested several times but you continue to "dance around" rather than taking an objective approach. Apparently problem solving is not your forte. -- (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 01/04/2020 23:32, Carlos E. R. wrote:
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 run 'ps' (as root) and only find one occurence. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2020-04-02 at 07:42 -0400, Anton Aylward wrote:
On 01/04/2020 23:32, Carlos E. R. wrote:
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 run 'ps' (as root) and only find one occurence.
ps afxu | grep -i firefox | less -S cer 6461 Sl ... | | \_ /usr/lib64/firefox/firefox cer 6614 Sl ... | | \_ /usr/lib64/firefox/firefox -contentproc -childID 1 -i ... cer 6703 Sl ... | | \_ /usr/lib64/firefox/firefox -contentproc -childID 3 -is ... cer 6756 Sl ... | | \_ /usr/lib64/firefox/firefox -contentproc -childID 4 -isF ... cer 6794 Sl ... | | \_ /usr/lib64/firefox/firefox -contentproc -childID 5 -isFo ... cer 6816 Sl ... | | \_ /usr/lib64/firefox/firefox -contentproc -childID 6 -isFor ... I have four. I had eight and I changed the configuration to four. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXoXR8Bwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVFr4AoIz1vbj/MH4pN6d77hPx fNJaHBvcAJ9Oa1KWXZKPsbmzwxqusekPvwlnjg== =Xq9k -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/04/2020 07:52, Carlos E. R. wrote:
I have four. I had eight and I changed the configuration to four.
"Obviously" mine is set to 1. and what you are showing are what I would consider 'threads' rather than forked&detached processes. Yes, I can, from a shell or my KDE menu, start up any number of forked&detached versions of firefox, ... but that's not the same thing as threads. Those threads sharwe the one address space, they are really an artefact of sheduling: <quote src="https://www.extremetech.com/internet/250930-firefox-54-finally-supports-multithreading-claims-higher-ram-efficiency-chrome"> Chrome and Firefox now both support multithreading, but they do it in different ways. In Chrome, each and every tab you open gets its own content process. Ten tabs, 10 processes. One hundred tabs, 100 processes. This approach maximizes performance, but you pay a hefty penalty in memory consumption and (when applicable) battery life. Firefox doesn’t take this approach to the problem, but instead spins up to four content process threads by default. “[Y]our first 4 tabs each use those 4 processes,” Pollack writes, “And additional tabs run using threads within those processes. Multiple tabs within a process share the browser engine that already exists in memory, instead of each creating their own.” </quote> So having one firefox process along with a few widows and each having a gazzilion tabs ... yes, that's different from having the gazzilion tabs in Chrome(ium). -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 02/04/2020 07:52, Carlos E. R. wrote:
I have four. I had eight and I changed the configuration to four.
"Obviously" mine is set to 1.
and what you are showing are what I would consider 'threads' rather than forked&detached processes.
On linux, there is virtually no difference.
Yes, I can, from a shell or my KDE menu, start up any number of forked&detached versions of firefox, ... but that's not the same thing as threads.
In essence, yes they are. -- Per Jessen, Zürich (12.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2020-04-02 at 08:20 -0400, Anton Aylward wrote:
On 02/04/2020 07:52, Carlos E. R. wrote:
I have four. I had eight and I changed the configuration to four.
"Obviously" mine is set to 1.
and what you are showing are what I would consider 'threads' rather than forked&detached processes.
Yes, I can, from a shell or my KDE menu, start up any number of forked&detached versions of firefox, ... but that's not the same thing as threads.
Those threads sharwe the one address space, they are really an artefact of sheduling:
<quote src="https://www.extremetech.com/internet/250930-firefox-54-finally-supports-multithreading-claims-higher-ram-efficiency-chrome"> Chrome and Firefox now both support multithreading, but they do it in different ways. In Chrome, each and every tab you open gets its own content process. Ten tabs, 10 processes. One hundred tabs, 100 processes. This approach maximizes performance, but you pay a hefty penalty in memory consumption and (when applicable) battery life. Firefox doesn’t take this approach to the problem, but instead spins up to four content process threads by default. ... </quote>
That information is obsolete. It was 4 about 2 years ago, when they started developing this. Yes, that link is about version 54, and we are on version 68. Now the default is 8 childs. They have their own pid, they are proceses, with separate command line: ps axms UID PID PENDING BLOCKED IGNORED CAUGHT STAT TTY TIME COMMAND 1000 8735 0000000000000000 - - - - ? 0:38 /usr/lib64/firefox/firefox 1000 8879 0000000000000000 - - - - ? 0:05 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 202003051> 1000 8918 0000000000000000 - - - - ? 0:01 /usr/lib64/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 137 -prefMapSize 185825 -parentBuildID 2020030> If I use "ps -eLf" to display threads, I get way more: UID PID PPID LWP C NLWP STIME TTY TIME CMD cer 8735 4221 8735 0 71 14:05 ? 00:00:18 /usr/lib64/firefox/firefox cer 8735 4221 8799 0 71 14:06 ? 00:00:00 /usr/lib64/firefox/firefox cer 8735 4221 8800 0 71 14:06 ? 00:00:00 /usr/lib64/firefox/firefox cer 8735 4221 8816 0 71 14:06 ? 00:00:02 /usr/lib64/firefox/firefox cer 8735 4221 8817 0 71 14:06 ? 00:00:00 /usr/lib64/firefox/firefox cer 8735 4221 8818 0 71 14:06 ? 00:00:00 /usr/lib64/firefox/firefox ... cer 8735 4221 9586 0 71 14:10 ? 00:00:00 /usr/lib64/firefox/firefox cer 8735 4221 10981 0 71 14:42 ? 00:00:00 /usr/lib64/firefox/firefox cer 8879 8735 8879 0 36 14:06 ? 00:00:03 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > cer 8879 8735 8882 0 36 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > cer 8879 8735 8883 0 36 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > cer 8879 8735 8884 0 36 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > cer 8879 8735 8885 0 36 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > cer 8879 8735 8886 0 36 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > cer 8879 8735 8887 0 36 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > cer 8879 8735 8888 0 36 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > cer 8879 8735 8889 0 36 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.ja > ... cer 9149 8735 9189 0 31 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 9 -isForBrowser -prefsLen 5942 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.> cer 9149 8735 9190 0 31 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 9 -isForBrowser -prefsLen 5942 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.> cer 9149 8735 9191 0 31 14:06 ? 00:00:00 /usr/lib64/firefox/firefox -contentproc -childID 9 -isForBrowser -prefsLen 5942 -prefMapSize 185825 -parentBuildID 20200305175243 -greomni /usr/lib64/firefox/omni.> They are too many to count. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXoXfFxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVddQAn0TTKJYWIPWgbTlYwUC0 D5ndMRNXAJ9uwA2f8Wxst1s/OKlLphGRrx7Omg== =s+JV -----END PGP SIGNATURE-----
* Anton Aylward <opensuse@antonaylward.com> [04-02-20 07:44]:
On 01/04/2020 23:32, Carlos E. R. wrote:
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 run 'ps' (as root) and only find one occurence.
and your distro version and FF version and CPU, otherwise your statement is akin to "the sky is blue". -- (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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2020-04-02 at 07:57 -0400, Patrick Shanahan wrote:
* Anton Aylward <> [04-02-20 07:44]:
On 01/04/2020 23:32, Carlos E. R. wrote:
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 run 'ps' (as root) and only find one occurence.
and your distro version and FF version and CPU, otherwise your statement is akin to "the sky is blue".
Read the link, it shows the default is 8. It is documented. As I said, I had a cpu with 4 cores and firefox had 8 childs. I changed that to 4. Then I upgraded to 12 cpu cores, and still have 4 childs. And now I have changed the configuration to automatic optimization, which is not the default, and I get 9 childs. system version you see in my signature. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXoXV5Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVMiwAoIHUayBEC56GQr7KuCd+ PUO9+fhQAJ9vFokd1VnF0JqAdYeA1OWA4Bp/PQ== =2+jH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (15)
-
Anton Aylward
-
Carlos E. R.
-
Carlos E.R.
-
Dave Howorth
-
David C. Rankin
-
Felix Miata
-
James Knott
-
jdd@dodin.org
-
L A Walsh
-
Michael Hamilton
-
Patrick Shanahan
-
Per Jessen
-
Peter Suetterlin
-
Richmond
-
Simon Becherer