Date: Mon, 29 Jun 2020 06:17:31 -0700 From: Donald Wilde <dwilde1@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-stable@freebsd.org, ericbsd <ericbsd@freebsd.org>, bdrewery@freebsd.org Subject: Re: swap space issues Message-ID: <CAEC7393eRE9DaUq1P_KoEPBtUQoi%2BsQa6QtbNyNFS-nv04sX3g@mail.gmail.com> In-Reply-To: <EEE87A3D-5E15-4D88-AF7D-E48F9440CF54@yahoo.com> References: <EEE87A3D-5E15-4D88-AF7D-E48F9440CF54.ref@yahoo.com> <EEE87A3D-5E15-4D88-AF7D-E48F9440CF54@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000a789cb05a938e1c6 Content-Type: text/plain; charset="UTF-8" [adding maintainers of synth and ccache] On 6/29/20, Mark Millard <marklmi@yahoo.com> wrote: > Based on "small arm system" context experiments > mostly . . . > > If your console messasges do not include > messages about "swap_pager_getswapspace(...): failed", > then it is unlikely that being out of swap space > is the actual issue even when it reports: "was killed: > out of swap space" messages. For such contexts, making > the swap area bigger does not help. > It did not show those getswapspace messages. > In other words, "was killed: out of swap space" > is frequently a misnomer and not to be believed > for "why" the kill happened or what should be > done about it --without other evidence also being > present anyway. > > Other causes include: > > Sustained low free RAM (via stays-runnable processes). > A sufficiently delayed pageout. > The swap blk uma zone was exhausted. > The swap pctrie uma zone was exhausted. > > (stays-runnable processes are not swapped out > [kernel stacks are not swapped out] but do actively > compete for RAM via paging activity. In such a > context, free RAM can stay low.) > > The below material does not deal with the > the "exhausted" causes but does deal with > the other 2. > > Presuming that you are getting "was killed: out > of swap space" notices but are not getting > "swap_pager_getswapspace failed" notices and > that kern.maxswzone vs. system load has not > been adjusted in a way that leads to bad > memory tradeoffs . . . > > I recommend attempting use of, say, (from > my /etc/sysctl.conf ): > Attached is what I tried, but when I ran synth again, I got a corrupted HDD that fsck refuses to fix, whether in 1U mode or with fs mounted. It just will not SALVAGE even when I add the -y flag. What got corrupted was one of the /usr/.ccache directories, but 'ccache -C' doesn't clear it. I restored the original /etc/sysctl.conf, but I can't add packages or ports any more, so I'm afraid I'm going to have to dd if=/dev/zero the disk and reload from 12.1R and start over again. I can't even 'rm -Rf /usr/.ccache'. It says 'Directory not empty'. I don't need this system up and running, so I'm not going to make any more changes until I see if any of you have suggestions to try first. -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** --000000000000a789cb05a938e1c6 Content-Type: application/octet-stream; name="sysctl.conf.new" Content-Disposition: attachment; filename="sysctl.conf.new" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 IyAkRnJlZUJTRDogc3RhYmxlLzEyL3NiaW4vc3lzY3RsL3N5c2N0bC5jb25mIDMzNzYyNCAyMDE4 LTA4LTExIDEzOjI4OjAzWiBicmQgJAojCiMgIFRoaXMgZmlsZSBpcyByZWFkIHdoZW4gZ29pbmcg dG8gbXVsdGktdXNlciBhbmQgaXRzIGNvbnRlbnRzIHBpcGVkIHRocnUKIyAgYGBzeXNjdGwnJyB0 byBhZGp1c3Qga2VybmVsIHZhbHVlcy4gIGBgbWFuIDUgc3lzY3RsLmNvbmYnJyBmb3IgZGV0YWls cy4KIwoKIyBVbmNvbW1lbnQgdGhpcyB0byBwcmV2ZW50IHVzZXJzIGZyb20gc2VlaW5nIGluZm9y bWF0aW9uIGFib3V0IHByb2Nlc3NlcyB0aGF0CiMgYXJlIGJlaW5nIHJ1biB1bmRlciBhbm90aGVy IFVJRC4KI3NlY3VyaXR5LmJzZC5zZWVfb3RoZXJfdWlkcz0wCnNlY3VyaXR5LmJzZC5zZWVfb3Ro ZXJfdWlkcz0wCnNlY3VyaXR5LmJzZC5zZWVfb3RoZXJfZ2lkcz0wCnNlY3VyaXR5LmJzZC5zZWVf amFpbF9wcm9jPTAKCiMKIyBEZWxheSB3aGVuIHBlcnNpc3RlbnQgbG93IGZyZWUgUkFNIGxlYWRz IHRvCiMgT3V0IE9mIE1lbW9yeSBraWxsaW5nIG9mIHByb2Nlc3Nlcy4gVGhlCiMgZGVsYXkgaXMg YSBjb3VudCBvZiBrZXJuZWwtYXR0ZW1wdHMgdG8gZ2FpbgojIGZyZWUgUkFNIChzbyBub3QgdGlt ZSB1bml0cykuCiN2bS5wYWdlb3V0X29vbV9zZXE9MTIgIyBkZWZhdWx0CiN2bS5wYWdlb3V0X29v bV9zZXE9LTEgIyBpbmZpbml0ZSAobm90IHN1cmUgZXhpc3RzID8/PykKdm0ucGFnZW91dF9vb21f c2VxPTEyMAojCiMgRm9yIHBsdW50eSBvZiBzd2FwL3BhZ2luZyBzcGFjZSAod2lsbCBub3QKIyBy dW4gb3V0KSwgYXZvaWQgcGFnZW91dCBkZWxheXMgbGVhZGluZyB0bwojIE91dCBPZiBNZW1vcnkg a2lsbGluZyBvZiBwcm9jZXNzZXM6CiN2bS5wZmF1bHRfb29tX2F0dGVtcHRzPS0xICMgaW5maW5p dGUKIwojIEZvciBwb3NzaWJseSBpbnN1ZmZpY2llbnQgc3dhcC9wYWdpbmcgc3BhY2UKIyAobWln aHQgcnVuIG91dCksIGluY3JlYXNlIHRoZSBwYWdlb3V0IGRlbGF5CiMgdGhhdCBsZWFkcyB0byBP dXQgT2YgTWVtb3J5IGtpbGxpbmcgb2YKIyBwcm9jZXNzZXM6CnZtLnBmYXVsdF9vb21fYXR0ZW1w dHM9IDEwCnZtLnBmYXVsdF9vb21fd2FpdD0gMQojIChUaGUgbXVsdGlwbGljYXRpb24gaXMgdGhl IHRvdGFsIGJ1dCB0aGVyZQojIGFyZSBvdGhlciBwb3RlbnRpYWwgdHJhZG9mZnMgaW4gdGhlIGZh Y3RvcnMKIyBtdWx0aXBsaWVkIGZvciB0aGUgc2FtZSB0b3RhbC4pCgojTm90ZTogQXMgb2Ygc3Rh YmxlLzEyIC1yMzUxNzc2ICwgc3RhYmxlIGdvdAojc3VwcG9ydCBmb3Igdm0ucGZhdWx0X29vbV9h dHRlbXB0cyBhbmQKI3ZtLnZtLnBmYXVsdF9vb21fd2FpdCB2aWEgYW4gTUZDLiBTdGFibGUgaGFz CiNoYWQgc3VwcG9ydCBmb3Igdm0ucGFnZW91dF9vb21fc2VxIGZvcgojbXVjaCBsb25nZXIgdGhh biB0aGF0LgojCiNOb3RlOiBMYXJnZXIgdmFsdWVzIG9mIHZtLnBhZ2VvdXRfb29tX3NlcQojd2ls bCB3YWl0IGV2ZW4gbG9uZ2VyLiBUaGUgZGVmYXVsdCB2YWx1ZSBpcwojMTIgKGxhc3QgSSBjaGVj a2VkKS4gTm8gZmlndXJlIHR1cm5zIG9mZgojdGhlIHNwZWNpZmljIG1lY2hhbmlzbSBhcyBmYXIg YXMgSSBrbm93LgojCg== --000000000000a789cb05a938e1c6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEC7393eRE9DaUq1P_KoEPBtUQoi%2BsQa6QtbNyNFS-nv04sX3g>