From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50F2CCD11C2 for ; Fri, 5 Apr 2024 09:05:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A76116B0123; Fri, 5 Apr 2024 05:05:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A26806B0125; Fri, 5 Apr 2024 05:05:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8ED8F6B0126; Fri, 5 Apr 2024 05:05:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6C3026B0123 for ; Fri, 5 Apr 2024 05:05:06 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E4046406C7 for ; Fri, 5 Apr 2024 09:05:05 +0000 (UTC) X-FDA: 81974893770.20.DD5F886 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf14.hostedemail.com (Postfix) with ESMTP id 0C54C100018 for ; Fri, 5 Apr 2024 09:05:03 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CPAOk74G; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of frits.hoogland@gmail.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=frits.hoogland@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712307904; a=rsa-sha256; cv=none; b=baJVfujDucGH1RjNEtJXmtOf8WGg6PLjsdSA775OXjbWgXuVYIaxevXLWlmz4Xuzp2h/qz FWoIXAHDX56NQL6goh6uKwUzZOFZKKdj91xJ+mg/qcWYx91YttA8IUsa6KvUeJZ/MSaOTf syU0GLF/R1fF6hhCKNe2AMO01NsUY40= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CPAOk74G; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of frits.hoogland@gmail.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=frits.hoogland@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712307904; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=2iHi7QIxmd0kXkAwzSBM5Lo2yevXKBhnjp4sWH/C/WI=; b=nqtR/fooQFK6MZTE93KALmNNzgh9lFTZKiNQvef8HAD5DBgSCgl7Q7nlrNsqaZlC4Ggped Ecgg6lcFyER4bmGtt+SNoBTbgLXmIM0xWUv0fvHRQe1Ys0oFer9TkVuJPLEBFiooffIZSQ 2qCqJ8wVQN+CdXhHHk4IBwPypXZomgE= Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-56e2ac1c16aso1083659a12.0 for ; Fri, 05 Apr 2024 02:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712307902; x=1712912702; darn=kvack.org; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=2iHi7QIxmd0kXkAwzSBM5Lo2yevXKBhnjp4sWH/C/WI=; b=CPAOk74GtNqUBv48aNJB5kZM543+Ka4XQtklzLR3xgHN/nzsd1KQxNNEZPndcy1mk2 atnjNNgDs+tmjWRKKJmzr9mG6inQsfJZuQ+ftkEpDVQo2HQp7p7AsoVpNiL4c8EjRHaW sutuey8Nj9pbJDrYhw482zZG4dglWbXO2A6TnGP63GqUaludMwdqbDpSzFW+hNuRKktM YA/UTvUasx4XiO/Z1HY7DG4/bUjDeESe43MCzL7HzyzI/K6hRHNUuarwywblhYkVy2/K bBUufoeQIO1LLgVzY1UD4OMQYu/Cl80Tlk9sFmrVXzXwcTTEGtBJGk7+oHA46eTM3LwS 2CHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712307902; x=1712912702; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=2iHi7QIxmd0kXkAwzSBM5Lo2yevXKBhnjp4sWH/C/WI=; b=Cf6IYcPUCjlS1k4iUhon7+b4E9OgT7z5313tUXw+QJWkI2kEet2idUXA8Vk4y4aqNm 1Rok1DSLLuMh1iOhYd1X4t/RJ6vdi5muXIXH1vVj+F/2FUVP2m8kChi46FHVJ7uNJ4rs nlOEtJj2FJ/SRNT+xEsI8likSez5BJgy8MOQh6q8SfsieZDla5Kg1Iz2NwAvHFxvHkVs gL8y9cA478Hu3xZzMCVepNX6QjSKO8mjyybhDUho9a00wpdYwgB8YKovUIc/BhTZTGRn 2QxEG/Huku5qEEDraQo/vz4qzrKChJOEo9FeyPEYo9H/4bzXMEJQ+aAgn5U2dPGIDCUh xJlw== X-Gm-Message-State: AOJu0YxcWWlbQHblq8kMlZkknYNjSibAJ5+C7yIfG2cZd5leSvWDhcm+ YNqQnIDfZinttiAk43q2nkTBk1SD2m2C+LRKrxSIwr11Zxpjm5ny7tzThrZb X-Google-Smtp-Source: AGHT+IHSMA/AVa7XEN6gXEUgmEgmiAj/i9WvOZ/yayweNIpd7nt3mm2uC264SrzmpxgjFnlZ/VSuCw== X-Received: by 2002:a17:906:3c16:b0:a51:9354:9362 with SMTP id h22-20020a1709063c1600b00a5193549362mr576792ejg.56.1712307902067; Fri, 05 Apr 2024 02:05:02 -0700 (PDT) Received: from smtpclient.apple (2001-1c04-0696-5900-5494-7046-b00d-00b4.cable.dynamic.v6.ziggo.nl. [2001:1c04:696:5900:5494:7046:b00d:b4]) by smtp.gmail.com with ESMTPSA id dp13-20020a170906c14d00b00a4a3580b215sm601942ejc.80.2024.04.05.02.05.01 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2024 02:05:01 -0700 (PDT) From: Frits Hoogland Content-Type: multipart/alternative; boundary="Apple-Mail=_F5A8F10F-E170-4E8F-906C-14201D337052" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Linux choosing to swap despite having 250G of file memory available Message-Id: Date: Fri, 5 Apr 2024 11:04:49 +0200 To: linux-mm@kvack.org X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0C54C100018 X-Stat-Signature: 6skp7az8gg63ud8c6o7ezcon6ahfjjc8 X-HE-Tag: 1712307903-508060 X-HE-Meta: U2FsdGVkX19c9LWKTbm5+JSVnWHu2hmcH9hADwOYme07S6oQZ6xifFnKWvGeVIVIrOtLuhlVMtV9DBRrIw2JMWsrvFwWjfF4tpdE2+LFN09P+IM3NNNw9HNnDVM/hTe5vKIRKWF4gEDrecGPZFMbPAEGnN/l6rfWXtdlGC73FqnFOycqde0Rq3CY/G4rJgt/J1u6felR482aArHvEnmm3J1qgL+V0BVRqXRw8PK27JQAiYvY70EystFBLUlOVKXx4Ysygwr9BPmGXnshg0kLp8b+f/beHkKcwSlfRBicFhciDmzOZwaq6UHj/xD1vnr31Ys/Mdy3nomEJlxDLCi+1VkN8wUr4Iubj2Nuw7Ci1X0TmDqJiQlwm7wcM0amccDsQso/ujlT1wvmUJUdDQ/SIpD+nFkwIW4qjD3S8HaQf1n/s9q9LItLchbmsLVOPUxfkI/5zRnKbcUwZQ8H3Cp1s1yxyIZSMDkc7idcffuLWNdoIUdDxoQFAa12AYTRrAP9+LO4YabaTbCVSL3ynPlzD7M3IJNzGZ6Xcp2qjmxWUAWNdHkM77X6s55UwGx8HQrH6f/lngqXqgLjrFD7ahbMSdkW8yrULQ5ILMF3ySLfto8pchcjJJpF2y0pmpljY6HCBj2yJ+bdb93GYTvrshvpeulS6lRGCPJAdpZVPDee4YEqZnTCyHQl6utpPSXLOmMxSdOhqojfHCkz78LkaWIEHNP60T2mepMMQrVOp9d291fp9wEfF8MjD+GCi55BUWpP/8Ovasl1/rDAOliL+kVDwP2jsJpFNbXAgH1OKDiUXJxlW/VRVozRl1g1Z5eExFKZvr2NQaPGSFv6wkVrOCR6P4MVASFY9VRbeTduiyxhwqkS4dL1xWY7SeO/UTBNUg9t7NvcAt+irhgSI4cjCT64jhW1njzu2edlQV7g9pEW5k6sWhm3lMeVXea5XLpEcKLZgN3jW1uWA0XJwRl0X58 BAs2QhaT RmjbKFkQvSues4xJNusdHa3+pYF/k6lSyX7iAoXvUgQEiFQ/bf9F0m99hKd8gQwushFzM1+v2QJ2524V+pFzF8irxxuCNQieFSyZVdaG2kH4kjDbRhUuBeemcfQ02Q2TAs2Vuwxa5nND1kP+yTE2BRbF8zWM1W8lHrMN2xm+HBhN1e5vPa+NDvkH9eDZNx7SHkn+MVlHQKdMthwSlpoXalV4yZyDrTS960zb9gvpkiUhhqR7pKTQyC/6almFLnljcEM6znkUHTR6z9d4inddnTF9JHYS+mmxnnfG3f9ZGNbXUzkZVjYw0txxkx+Th1XveYA8TZ3C4mZQpSgf06oYZe3A03LFApc1eLO4fwQrcu0TVTGGNdsMNhDmSdeMu2r0PsDQy93i/EoLz6z1eyHklAO5QF4l3DVSPfwqrIAF0SRDaJw6pLvEuhCAuqTE+feaglan8bQXXuVYfPqIt2ZzNwLPNME3lWPk44XormI8cYmgLwyoLfNmJiG9czaZwexTPA5rM+chPzNk8K09Q+Wq4L1so0QOuDfxc42YCl27eFXhtkiI5n/Bc58FVNjUfZtGjlK+x X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --Apple-Mail=_F5A8F10F-E170-4E8F-906C-14201D337052 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I got a question about the behavior of linux which I do not understand = currently. This is the situation: The server has 1T of memory, of which 700G of memory is allocated to = hugepages (hp size 1G). This leaves 300G of memory in smallpages, for which I assume linux will = apply it=E2=80=99s general memory behaviour.=20 =46rom the smallpages memory, I see > 250G being classified as file = memory, and roughly only about 15G allocated to anon (anonymous memory).=20= The load on the server is caused by a postgres database instance with on = average 80 sessions active, of which a varying number is performing read = and write IO. Postgres performs buffered reads and writes using the = pread64() and prwrite64() calls, and always performs IO using an IO size = of 8KB.=20 However, it should be noted that postgres can also use posix_fadvise() = to make the OS preread blocks using POSIX_FADV_WILLNEED.=20 There might be independent asynchronous IO via direct path, but I have = not been informed on how that exactly works. That IO might be on the = postgres files the regular pread64 and pwrite64 are executing, but these = calls are not part of open source postgres. The amount of IO that is taking place is also noteworthy: using the = iotop utility I can both total and actual disk reads and writes going up = to 3 GBPS for reads and up 500 MBPS for writes. The question I have is why linux chooses to swap, despite having lots of = file memory, for which it reports (via MemAvailable) that it=E2=80=99s = available. I need more tools on this machine, but I do not have the impression = it=E2=80=99s extremely influencing sessions, although top (with the swap = field added) shows that every postgres database process has swapped out = memory. It also does not seem healthy to have ongoing swapping in and out = continuously going on. Thank you. Frits Hoogland The filesystem is XFS, mount options noatime, inode64, nodiratime, = nodev. Operating system: Red Hat Enterprise Linux 8.9 Kernel: 4.18.0-513.5.1.el8_9.x86_64 #1 SMP /proc/meminfo MemTotal: 1055737556 kB MemFree: 2213440 kB MemAvailable: 298459084 kB Buffers: 1340 kB Cached: 286127736 kB SwapCached: 837032 kB Active: 29872372 kB Inactive: 269357644 kB Active(anon): 3788932 kB Inactive(anon): 8167304 kB Active(file): 26083440 kB Inactive(file): 261190340 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 16777212 kB SwapFree: 8386212 kB Dirty: 5311136 kB Writeback: 0 kB AnonPages: 12670468 kB Mapped: 138672 kB Shmem: 64104 kB KReclaimable: 11589948 kB Slab: 13762220 kB SReclaimable: 11589948 kB SUnreclaim: 2172272 kB KernelStack: 38240 kB PageTables: 266476 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 324791060 kB Committed_AS: 37860836 kB VmallocTotal: 34359738367 kB VmallocUsed: 481952 kB VmallocChunk: 0 kB Percpu: 97792 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 704 HugePages_Free: 366 HugePages_Rsvd: 2 HugePages_Surp: 0 Hugepagesize: 1048576 kB Hugetlb: 738197504 kB DirectMap4k: 17853212 kB DirectMap2M: 302462976 kB DirectMap1G: 752877568 kB vmstat 1 10 procs -----------memory---------- ---swap-- -----io---- -system-- = ------cpu----- r b swpd free buff cache si so bi bo in cs us sy = id wa st 42 6 8424412 1743776 1340 299215616 8 11 6786 911 0 0 = 13 3 82 2 0 29 12 8428456 2678092 1340 298592000 1220 6092 2149152 249176 466196 = 366703 27 6 62 5 0 32 8 8427984 1701916 1340 299545600 1788 1832 2020852 316652 366820 = 309808 23 5 67 5 0 41 4 8430328 1702864 1340 299411136 960 4136 2228240 263160 433730 = 368056 24 6 64 6 0 49 4 8402344 1724772 1340 299495040 1392 6320 2435296 303464 463479 = 368963 23 7 64 6 0 33 5 8401056 1757348 1340 299520960 1788 4088 2107472 248576 395061 = 350817 23 9 63 5 0 30 11 8403788 1721484 1340 299539776 560 4012 2237708 229508 426055 = 384332 25 6 65 5 0 36 10 8409792 1904800 1340 299274848 364 6772 2192364 294444 428661 = 390878 25 6 64 6 0 33 8 8415368 1804560 1340 299320800 616 7112 2195100 272072 447890 = 398957 26 6 61 6 0 39 3 8386444 1885732 1340 299333088 2032 7172 2163180 266672 459675 = 419805 26 7 61 7 0 swapon -s Filename Type Size Used = Priority /dev/dm-1 partition 16777212 = 8405472 -2 sysctl -a | grep ^vm vm.admin_reserve_kbytes =3D 8192 vm.block_dump =3D 0 vm.compact_unevictable_allowed =3D 1 vm.compaction_proactiveness =3D 0 vm.dirty_background_bytes =3D 0 vm.dirty_background_ratio =3D 10 vm.dirty_bytes =3D 0 vm.dirty_expire_centisecs =3D 3000 vm.dirty_ratio =3D 20 vm.dirty_writeback_centisecs =3D 500 vm.dirtytime_expire_seconds =3D 43200 vm.drop_caches =3D 0 vm.extfrag_threshold =3D 500 vm.force_cgroup_v2_swappiness =3D 0 vm.hugetlb_shm_group =3D 32022 vm.laptop_mode =3D 0 vm.legacy_va_layout =3D 0 vm.lowmem_reserve_ratio =3D 256 256 32 0 0 vm.max_map_count =3D 500000 vm.memory_failure_early_kill =3D 0 vm.memory_failure_recovery =3D 1 vm.min_free_kbytes =3D 71274 vm.min_slab_ratio =3D 5 vm.min_unmapped_ratio =3D 1 vm.mmap_min_addr =3D 4096 vm.mmap_rnd_bits =3D 28 vm.mmap_rnd_compat_bits =3D 8 vm.nr_hugepages =3D 704 vm.nr_hugepages_mempolicy =3D 704 vm.nr_overcommit_hugepages =3D 0 vm.numa_stat =3D 1 vm.numa_zonelist_order =3D Node vm.oom_dump_tasks =3D 1 vm.oom_kill_allocating_task =3D 0 vm.overcommit_kbytes =3D 0 vm.overcommit_memory =3D 2 vm.overcommit_ratio =3D 97 vm.page-cluster =3D 3 vm.page_lock_unfairness =3D 5 vm.panic_on_oom =3D 0 vm.percpu_pagelist_fraction =3D 0 vm.stat_interval =3D 1 vm.swappiness =3D 1 vm.user_reserve_kbytes =3D 131072 vm.vfs_cache_pressure =3D 100 vm.watermark_boost_factor =3D 15000 vm.watermark_scale_factor =3D 10 vm.zone_reclaim_mode =3D 0 --Apple-Mail=_F5A8F10F-E170-4E8F-906C-14201D337052 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I got a question about the behavior of linux = which I do not understand currently. This is the situation:

The = server has 1T of memory, of which 700G of memory is allocated to = hugepages (hp size 1G).
This leaves = 300G of memory in smallpages, for which I assume linux will apply it=E2=80= =99s general memory behaviour. 

=46rom the smallpages = memory, I see > 250G being classified as file memory, and roughly = only about 15G allocated to anon (anonymous memory). 

The = load on the server is caused by a postgres database instance with on = average 80 sessions active, of which a varying number is performing read = and write IO. Postgres performs buffered reads and writes using the = pread64() and prwrite64() calls, and always performs IO using an IO size = of 8KB. 

However, it should be noted that postgres can = also use posix_fadvise() to make the OS preread blocks using = POSIX_FADV_WILLNEED. 
There = might be independent asynchronous IO via direct path, but I have not = been informed on how that exactly works. That IO might be on the = postgres files the regular pread64 and pwrite64 are executing, but these = calls are not part of open source postgres.

The amount of IO that = is taking place is also noteworthy: using the iotop utility I can both = total and actual disk reads and writes going up to 3 GBPS for reads and = up 500 MBPS for writes.

The question I have is = why linux chooses to swap, despite having lots of file memory, for which = it reports (via MemAvailable) that it=E2=80=99s available.
I need more tools on this machine, but I do = not have the impression it=E2=80=99s extremely influencing sessions, = although top (with the swap field added) shows that every postgres = database process has swapped out memory.
It also does not seem healthy to have ongoing swapping in and out = continuously going on.

Thank you.

Frits = Hoogland


The filesystem is XFS, = mount options noatime, inode64, nodiratime, nodev.

Operating system: Red Hat Enterprise Linux 8.9
Kernel: 4.18.0-513.5.1.el8_9.x86_64 #1 = SMP

/proc/meminfo
MemTotal:       1055737556 = kB
MemFree:         2213440 = kB
MemAvailable:   298459084 kB
Buffers:   =          1340 kB
Cached:   =       286127736 kB
SwapCached:     =   837032 kB
Active:         29872372 = kB
Inactive:       269357644 = kB
Active(anon):    3788932 = kB
Inactive(anon):  8167304 kB
Active(file): =   26083440 kB
Inactive(file): 261190340 = kB
Unevictable:           0 = kB
Mlocked:               0 = kB
SwapTotal:      16777212 = kB
SwapFree:        8386212 = kB
Dirty:           5311136 = kB
Writeback:             0 = kB
AnonPages:      12670468 = kB
Mapped:           138672 = kB
Shmem:             64104 = kB
KReclaimable:   11589948 kB
Slab:   =         13762220 kB
SReclaimable:   = 11589948 kB
SUnreclaim:      2172272 = kB
KernelStack:       38240 = kB
PageTables:       266476 = kB
NFS_Unstable:          0 = kB
Bounce:               =  0 kB
WritebackTmp:          0 = kB
CommitLimit:    324791060 = kB
Committed_AS:   37860836 kB
VmallocTotal: =   34359738367 kB
VmallocUsed:      481952 = kB
VmallocChunk:          0 = kB
Percpu:            97792 = kB
HardwareCorrupted:     0 = kB
AnonHugePages:         0 = kB
ShmemHugePages:        0 = kB
ShmemPmdMapped:        0 = kB
FileHugePages:         0 = kB
FilePmdMapped:         0 = kB
HugePages_Total:     = 704
HugePages_Free:     =  366
HugePages_Rsvd:       =  2
HugePages_Surp:       =  0
Hugepagesize:    1048576 = kB
Hugetlb:        738197504 = kB
DirectMap4k:    17853212 = kB
DirectMap2M:    302462976 = kB
DirectMap1G:    752877568 kB

vmstat 1 10
procs = -----------memory---------- ---swap-- -----io---- -system-- = ------cpu-----
 r  b   swpd   free   = buff  cache   si   so    bi    bo =   in   cs us sy id wa st
42  6 8424412 1743776 =   1340 299215616    8   11  6786   911 =    0    0 13  3 82  2  0
29 = 12 8428456 2678092   1340 298592000 1220 6092 2149152 249176 466196 = 366703 27  6 62  5  0
32  8 8427984 = 1701916   1340 299545600 1788 1832 2020852 316652 366820 309808 23 =  5 67  5  0
41  4 8430328 1702864   = 1340 299411136  960 4136 2228240 263160 433730 368056 24  6 64 =  6  0
49  4 8402344 1724772   1340 = 299495040 1392 6320 2435296 303464 463479 368963 23  7 64  6 =  0
33  5 8401056 1757348   1340 299520960 1788 = 4088 2107472 248576 395061 350817 23  9 63  5 =  0
30 11 8403788 1721484   1340 299539776  560 = 4012 2237708 229508 426055 384332 25  6 65  5 =  0
36 10 8409792 1904800   1340 299274848  364 = 6772 2192364 294444 428661 390878 25  6 64  6 =  0
33  8 8415368 1804560   1340 299320800 =  616 7112 2195100 272072 447890 398957 26  6 61  6 =  0
39  3 8386444 1885732   1340 299333088 2032 = 7172 2163180 266672 459675 419805 26  7 61  7 =  0

swapon = -s
Filename Type = Size = Used = Priority
/dev/dm-1           =                   =   = partition = 16777212 = 8405472 = -2

sysctl -a | grep = ^vm
vm.admin_reserve_kbytes =3D 8192
vm.block_dump =3D= 0
vm.compact_unevictable_allowed =3D = 1
vm.compaction_proactiveness =3D = 0
vm.dirty_background_bytes =3D = 0
vm.dirty_background_ratio =3D 10
vm.dirty_bytes =3D = 0
vm.dirty_expire_centisecs =3D 3000
vm.dirty_ratio = =3D 20
vm.dirty_writeback_centisecs =3D = 500
vm.dirtytime_expire_seconds =3D = 43200
vm.drop_caches =3D 0
vm.extfrag_threshold =3D = 500
vm.force_cgroup_v2_swappiness =3D = 0
vm.hugetlb_shm_group =3D 32022
vm.laptop_mode =3D = 0
vm.legacy_va_layout =3D 0
vm.lowmem_reserve_ratio = =3D 256 = 256 = 32 = 0 = 0
vm.max_map_count =3D = 500000
vm.memory_failure_early_kill =3D = 0
vm.memory_failure_recovery =3D = 1
vm.min_free_kbytes =3D 71274
vm.min_slab_ratio =3D = 5
vm.min_unmapped_ratio =3D 1
vm.mmap_min_addr =3D = 4096
vm.mmap_rnd_bits =3D 28
vm.mmap_rnd_compat_bits = =3D 8
vm.nr_hugepages =3D = 704
vm.nr_hugepages_mempolicy =3D = 704
vm.nr_overcommit_hugepages =3D 0
vm.numa_stat =3D = 1
vm.numa_zonelist_order =3D Node
vm.oom_dump_tasks = =3D 1
vm.oom_kill_allocating_task =3D = 0
vm.overcommit_kbytes =3D 0
vm.overcommit_memory =3D = 2
vm.overcommit_ratio =3D 97
vm.page-cluster =3D = 3
vm.page_lock_unfairness =3D 5
vm.panic_on_oom =3D = 0
vm.percpu_pagelist_fraction =3D 0
vm.stat_interval = =3D 1
vm.swappiness =3D 1
vm.user_reserve_kbytes =3D = 131072
vm.vfs_cache_pressure =3D = 100
vm.watermark_boost_factor =3D = 15000
vm.watermark_scale_factor =3D = 10
vm.zone_reclaim_mode =3D 0





= --Apple-Mail=_F5A8F10F-E170-4E8F-906C-14201D337052--