From owner-freebsd-stable@freebsd.org Fri Jun 26 10:58:03 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CD12C354C88 for ; Fri, 26 Jun 2020 10:58:03 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49tYkz523Tz4Ryh; Fri, 26 Jun 2020 10:58:03 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MacBook-Pro-449.fritz.box (p200300cd5f203300bcc962682cf2cf29.dip0.t-ipconnect.de [IPv6:2003:cd:5f20:3300:bcc9:6268:2cf2:cf29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 212F415292; Fri, 26 Jun 2020 10:58:03 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: swap space issues To: freebsd-stable@freebsd.org References: <20200625000410.GA10210@eureka.lemis.com> <20200625025248.GB10210@eureka.lemis.com> <20200626102331.GA6406@server.rulingia.com> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Cc: Peter Jeremy Message-ID: <52753cf4-57db-93d9-d217-c8f812d6bc7c@freebsd.org> Date: Fri, 26 Jun 2020 12:58:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626102331.GA6406@server.rulingia.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 10:58:03 -0000 Am 26.06.20 um 12:23 schrieb Peter Jeremy: > On 2020-Jun-25 11:30:31 -0700, Donald Wilde wrote: >> Here's 'pstat -s' on the i3 (which registers as cpu HAMMER): >> >> Device 1K-blocks Used Avail Capacity >> /dev/ada0s1b 33554432 0 33554432 0% >> /dev/ada0s1d 33554432 0 33554432 0% >> Total 67108864 0 67108864 0% > > I strongly suggest you don't have more than one swap device on spinning > rust - the VM system will stripe I/O across the available devices and > that will give particularly poor results when it has to seek between the > partitions. This used to be beneficial, when disk read and write bandwidth was limited and whole processes had to be swapped in or out due to RAM pressure. (This changed due to more RAM and a different ratio of seek to transfer times for a given amount of data.) An idea for a better strategy: It might be better to use an allocation algorithm that assigns a swap device to each running process that needs pages written to the swap device and only assign another swap device (and use if from then on for that process) if there is no free space left on the one used until then. Such a strategy would at least reduce the number of processes that need all configured swap devices at the same time in a striped configuration. If all processes start with the first configured swap device assigned to them, this will lead to only one of them being used until it fills up, then progressing to the next one. The strategy of whether the initial swap device assigned to a process is always the first one configured in the system, or whether after that could not be used by some process is moved on to the next one (typically the one assigned to that process for further page-outs) is not obvious to me. The behavior could be controlled by a sysctl to allow to adapt the strategy to the hardware (e.g. rotating vs. flash disks for swap). > As a further piece of arcana, vm.pageout_oom_seq is a count that controls > the number of passes before the pageout daemon gives up and starts killing > processes when it can't free up enough RAM. "out of swap space" messages > generally mean that this number is too low, rather than there being a > shortage of swap - particularly if your swap device is rather slow. I'm not sure that this specific sysctl is documented in such a way that it is easy to find by people suffering from out-of-memory kills. Perhaps it could be mentioned as a parameter that may need tuning in the OOM message? And while it does not come up that often in the mail list, it might be better for many kinds of application if the default was increased (a longer wait for resources might be more acceptable than the loss of all results of a long running computation). Regards, STefan