5 Dec
2017
5 Dec
'17
8:12 a.m.
On Mon, 04 Dec 2017 10:19:19 -0700 Warner Losh <imp(a)bsdimp.com> wrote:
Warner Losh writes:
On Mon, Dec 4, 2017 at 9:36 AM, <arnold(a)skeeve.com> wrote:
Conceptually they are somewhat different cases.
1) In the no-swap case *no* pages will be available once all
the phys pages are used up. To recover, the kernel must
free up space by killing some process.
2) In the swap case pages will eventually be available. The
paging rate becomes the bottleneck but no need to kill
any process.
In case 1) there may be other disk traffic to confuse things.
But eventually that should die down. However I am not sure
FreeBSD has a clean way to indicate there are no free pages.
It calls OOM logic as a last resort. In case 2) OOM should
never be called.
I think the issue is that the kernel is unable to kill a
process that is waiting for a free page. Since all of them are
doing the same thing, the system hangs. I think this wait has
to be made interruptable to be able to kill a process. Of
course that may break something else....
May be better to avoid the whole issue in the first place for
a service latency sensitive production machine. By providing
a way for a process to ask that there is enough backing store
for any mmaped pages (and thus avoid swapping or running out
of memory). Not sure if originally BSD did provide such a
guarantee...
Larry McVoy <lm(a)mcvoy.com> wrote:
The deployed systems in the field have swap space configured. But if we're
not careful we can still run out. Larry's tests are at the extreme limits,
to be sure, and not having swap exacerbates the bad behavior at the limit. So I have 10 processes, they all run until the
system starts to
thrash, then they are all in wait mode for memory but there isn't
any (and there is no swap configured).
Um, pardon me for asking the obvious question, but why not just configure
a few gigs of swap to give the OS some breathing room?
Most modern systems let you use a regular old file in the filesystem
for swap space, instead of having to repartition your disk and using a
dedicated partition. I'd be suprised if your *BSD box didn't let you do
that too. It's a little slower, but a gazillion times more convenient. If he's trying to ameliorate bad effects, doing
it on worst case scenario
certainly helps. The BSD box allows for it, and it's not that much slower,
but it kinda misses the point of the exercise.
Also, the systems in questions often operate at the
limits of the disk
subsystem, so additional write traffic is undesirable. They are also SSDs,
so doubly undesirable where avoidable.
This can be tested by writing some custom logic: instead of
writing out a page, compress it and stash in memory (or
ramdisk). The test can write highly compressable patterns.