* Cannot allocate memory despite buff/cache non-zero
@ 2021-06-04 11:36 Paul Menzel
2021-06-09 11:17 ` David Hildenbrand
0 siblings, 1 reply; 3+ messages in thread
From: Paul Menzel @ 2021-06-04 11:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, it+linux-mm
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
Dear Linux folks,
On a 1 TB RAM compute server with Linux 5.10.24 and memory
overcommitting disabled, we ran into a situation where processes like
SSH couldn’t allocate memory anymore.
$ more /proc/cmdline
BOOT_IMAGE=/boot/bzImage-5.10.24.mx64.375 root=LABEL=root ro
crashkernel=256M console=ttyS0,115200n8 console=tty0 init=/bin/systemd
audit=0 random.trust_cpu=on
2021-06-03T22:00:28+02:00 godsavethequeen sshd[89163]:
pam_systemd(sshd:session): Failed to create session: Unit
session-25654.scope not found.
2021-06-03T22:00:29+02:00 godsavethequeen sshd[89163]: error:
do_exec_no_pty: fork: Cannot allocate memory
2021-06-03T22:00:29+02:00 godsavethequeen sshd[89163]:
pam_unix(sshd:session): session closed for user root
2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error: fork:
Cannot allocate memory
2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error:
ssh_msg_send: write: Broken pipe
2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error:
send_rexec_state: ssh_msg_send failed
$ free -h
total used free shared buff/cache
available
Mem: 1.0T 606G 2.6G 2.2M 395G
391G
Swap: 0B 0B 0B
Looking at this, I would have expected, that the pages(?) in buff/cache
would be moved/deleted to make memory available.
Looking at `/proc/meminfo` (attached):
MemTotal: 1052411824 kB
MemFree: 2709976 kB
MemAvailable: 410847908 kB
[…]
CommitLimit: 1052411824 kB
Committed_AS: 1052455260 kB
[…]
Committed_AS is greater than the commit limit (total memory).
Is such behavior expected?
Kind regards,
Paul
[-- Attachment #2: 20210603-godsavethequeen-meminfo.txt --]
[-- Type: text/plain, Size: 1408 bytes --]
MemTotal: 1052411824 kB
MemFree: 2709976 kB
MemAvailable: 410847908 kB
Buffers: 3212 kB
Cached: 411083788 kB
SwapCached: 0 kB
Active: 303175824 kB
Inactive: 740080100 kB
Active(anon): 1448 kB
Inactive(anon): 632169724 kB
Active(file): 303174376 kB
Inactive(file): 107910376 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 632161948 kB
Mapped: 508880 kB
Shmem: 2248 kB
KReclaimable: 2357416 kB
Slab: 3119240 kB
SReclaimable: 2357416 kB
SUnreclaim: 761824 kB
KernelStack: 50512 kB
PageTables: 1715372 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1052411824 kB
Committed_AS: 1052455260 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 480508 kB
VmallocChunk: 0 kB
Percpu: 460800 kB
AnonHugePages: 509384704 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 5995344 kB
DirectMap2M: 483590144 kB
DirectMap1G: 579862528 kB
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Cannot allocate memory despite buff/cache non-zero
2021-06-04 11:36 Cannot allocate memory despite buff/cache non-zero Paul Menzel
@ 2021-06-09 11:17 ` David Hildenbrand
2021-06-10 5:58 ` Paul Menzel
0 siblings, 1 reply; 3+ messages in thread
From: David Hildenbrand @ 2021-06-09 11:17 UTC (permalink / raw)
To: Paul Menzel, Andrew Morton; +Cc: linux-mm, it+linux-mm
On 04.06.21 13:36, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On a 1 TB RAM compute server with Linux 5.10.24 and memory
> overcommitting disabled, we ran into a situation where processes like
> SSH couldn’t allocate memory anymore.
>
> $ more /proc/cmdline
> BOOT_IMAGE=/boot/bzImage-5.10.24.mx64.375 root=LABEL=root ro
> crashkernel=256M console=ttyS0,115200n8 console=tty0 init=/bin/systemd
> audit=0 random.trust_cpu=on
>
> 2021-06-03T22:00:28+02:00 godsavethequeen sshd[89163]:
> pam_systemd(sshd:session): Failed to create session: Unit
> session-25654.scope not found.
> 2021-06-03T22:00:29+02:00 godsavethequeen sshd[89163]: error:
> do_exec_no_pty: fork: Cannot allocate memory
> 2021-06-03T22:00:29+02:00 godsavethequeen sshd[89163]:
> pam_unix(sshd:session): session closed for user root
> 2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error: fork:
> Cannot allocate memory
> 2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error:
> ssh_msg_send: write: Broken pipe
> 2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error:
> send_rexec_state: ssh_msg_send failed
>
> $ free -h
> total used free shared buff/cache
> available
> Mem: 1.0T 606G 2.6G 2.2M 395G
> 391G
> Swap: 0B 0B 0B
>
> Looking at this, I would have expected, that the pages(?) in buff/cache
> would be moved/deleted to make memory available.
>
> Looking at `/proc/meminfo` (attached):
>
> MemTotal: 1052411824 kB
> MemFree: 2709976 kB
> MemAvailable: 410847908 kB
> […]
> CommitLimit: 1052411824 kB
> Committed_AS: 1052455260 kB
> […]
>
With memory overcommit disabled, each accountable mapping
(mm/mmap.c:accountable_mapping()) will count towards Committed_AS. So
you might still have plenty of free memory in the system reserved for
these mappings, yet Linux won't allow for more accountable mappings.
That's why you see the "Cannot allocate memory" messages. mmap() failed.
> Committed_AS is greater than the commit limit (total memory).
>
> Is such behavior expected?
We're talking about 43436 kB that exceed the CommitLimit.
The CommitLimit might change (grow/shrink) when
a) The number of hugetlb pages changes
b) Swap space is resized
If CommitLimit did not change, Committed_AS should actually not exceed
it. IIUC, it can only happen temporarily while trying creation of a new
mapping. We increase Committed_AS unconditionally and decrease it again
if we reject it.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Cannot allocate memory despite buff/cache non-zero
2021-06-09 11:17 ` David Hildenbrand
@ 2021-06-10 5:58 ` Paul Menzel
0 siblings, 0 replies; 3+ messages in thread
From: Paul Menzel @ 2021-06-10 5:58 UTC (permalink / raw)
To: David Hildenbrand, Andrew Morton; +Cc: linux-mm, it+linux-mm
Dear David,
Thank you for your reply.
Am 09.06.21 um 13:17 schrieb David Hildenbrand:
> On 04.06.21 13:36, Paul Menzel wrote:
>> On a 1 TB RAM compute server with Linux 5.10.24 and memory
>> overcommitting disabled, we ran into a situation where processes like
>> SSH couldn’t allocate memory anymore.
>>
>> $ more /proc/cmdline
>> BOOT_IMAGE=/boot/bzImage-5.10.24.mx64.375 root=LABEL=root ro crashkernel=256M console=ttyS0,115200n8 console=tty0 init=/bin/systemd audit=0 random.trust_cpu=on
>>
>> 2021-06-03T22:00:28+02:00 godsavethequeen sshd[89163]: pam_systemd(sshd:session): Failed to create session: Unit session-25654.scope not found.
>> 2021-06-03T22:00:29+02:00 godsavethequeen sshd[89163]: error: do_exec_no_pty: fork: Cannot allocate memory
>> 2021-06-03T22:00:29+02:00 godsavethequeen sshd[89163]: pam_unix(sshd:session): session closed for user root
>> 2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error: fork: Cannot allocate memory
>> 2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error: ssh_msg_send: write: Broken pipe
>> 2021-06-03T22:01:41+02:00 godsavethequeen sshd[1834]: error: send_rexec_state: ssh_msg_send failed
>>
>> $ free -h
>> total used free shared buff/cache available
>> Mem: 1.0T 606G 2.6G 2.2M 395G 391G
>> Swap: 0B 0B 0B
>>
>> Looking at this, I would have expected, that the pages(?) in buff/cache
>> would be moved/deleted to make memory available.
>>
>> Looking at `/proc/meminfo` (attached):
>>
>> MemTotal: 1052411824 kB
>> MemFree: 2709976 kB
>> MemAvailable: 410847908 kB
>> […]
>> CommitLimit: 1052411824 kB
>> Committed_AS: 1052455260 kB
>> […]
>
> With memory overcommit disabled, each accountable mapping
> (mm/mmap.c:accountable_mapping()) will count towards Committed_AS. So
> you might still have plenty of free memory in the system reserved for
> these mappings, yet Linux won't allow for more accountable mappings.
> That's why you see the "Cannot allocate memory" messages. mmap() failed.
Buffers: 3212 kB
Cached: 411083788 kB
SwapCached: 0 kB
Active: 303175824 kB
Inactive: 740080100 kB
Active(anon): 1448 kB
Inactive(anon): 632169724 kB
Active(file): 303174376 kB
Inactive(file): 107910376 kB
The documentation [1] describes *MemAvailable*, *Buffers*, and *Cached*:
> MemAvailable
> An estimate of how much memory is available for starting new
> applications, without swapping. Calculated from MemFree,
> SReclaimable, the size of the file LRU lists, and the low
> watermarks in each zone.
> The estimate takes into account that the system needs some
> page cache to function well, and that not all reclaimable
> slab will be reclaimable, due to items being in use. The
> impact of those factors will vary from system to system.
> Buffers
> Relatively temporary storage for raw disk blocks
> shouldn't get tremendously large (20MB or so)
> Cached
> in-memory cache for files read from the disk (the
> pagecache). Doesn't include SwapCached
So I would have assumed, the kernel removes files from the in-memory
cache for files.
>> Committed_AS is greater than the commit limit (total memory).
>>
>> Is such behavior expected?
>
> We're talking about 43436 kB that exceed the CommitLimit.
>
> The CommitLimit might change (grow/shrink) when
> a) The number of hugetlb pages changes
> b) Swap space is resized
>
> If CommitLimit did not change, Committed_AS should actually not exceed
> it. IIUC, it can only happen temporarily while trying creation of a new
> mapping. We increase Committed_AS unconditionally and decrease it again
> if we reject it.
I can’t say for sure, as the system was rebooted, but I thought the
value stayed the same.
Kind regards,
Paul
[1]: https://www.kernel.org/doc/html/latest/filesystems/proc.html#meminfo
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-06-10 5:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-04 11:36 Cannot allocate memory despite buff/cache non-zero Paul Menzel
2021-06-09 11:17 ` David Hildenbrand
2021-06-10 5:58 ` Paul Menzel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.