问题[ram](unix)

我曾经有两个内存条，每个 8GB。我把其中一根换成了 16G 内存条，原以为现在总共有 24GB，但实际只有 20GB。free -h 的结果：

              total        used        free      shared  buff/cache   available
Mem:           19Gi       2.8Gi        12Gi       105Mi       3.9Gi        16Gi
Swap:         2.0Gi          0B       2.0Gi

猫 /proc/meminfo

MemTotal:       20292048 kB
MemFree:        13254056 kB
MemAvailable:   16923208 kB
Buffers:          269448 kB
Cached:          3706108 kB
SwapCached:            0 kB
Active:          1319968 kB
Inactive:        4874796 kB
Active(anon):      14752 kB
Inactive(anon):  2312796 kB
Active(file):    1305216 kB
Inactive(file):  2562000 kB
Unevictable:         132 kB
Mlocked:             132 kB
SwapTotal:       2097148 kB
SwapFree:        2097148 kB
Dirty:               524 kB
Writeback:             0 kB
AnonPages:       2219512 kB
Mapped:          1341800 kB
Shmem:            108248 kB
KReclaimable:     159592 kB
Slab:             372516 kB
SReclaimable:     159592 kB
SUnreclaim:       212924 kB
KernelStack:       23104 kB
PageTables:        56624 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12243172 kB
Committed_AS:   13539940 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       67940 kB
VmallocChunk:          0 kB
Percpu:            25088 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 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:      635844 kB
DirectMap2M:    10717184 kB

sudo dmidecode -t 内存

    Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
# SMBIOS implementations newer than version 3.2.0 are not
# fully supported by this version of dmidecode.

Handle 0x0022, DMI type 16, 23 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: None
    Maximum Capacity: 64 GB
    Error Information Handle: 0x0025
    Number Of Devices: 2

Handle 0x0023, DMI type 17, 92 bytes
Memory Device
    Array Handle: 0x0022
    Error Information Handle: 0x0026
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 16384 MB
    Form Factor: SODIMM
    Set: None
    Locator: DIMM 0
    Bank Locator: P0 CHANNEL A
    Type: DDR4
    Type Detail: Synchronous Unbuffered (Unregistered)
    Speed: 3200 MT/s
    Manufacturer: Unknown
    Serial Number: E81F0ECB
    Asset Tag: Not Specified
    Part Number: CT16G4SFRA32A.M16FR
    Rank: 2
    Configured Memory Speed: 3200 MT/s
    Minimum Voltage: 1.2 V
    Maximum Voltage: 1.2 V
    Configured Voltage: 1.2 V
    Memory Technology: DRAM
    Memory Operating Mode Capability: Volatile memory
    Firmware Version: Unknown
    Module Manufacturer ID: Bank 6, Hex 0x9B
    Module Product ID: Unknown
    Memory Subsystem Controller Manufacturer ID: Unknown
    Memory Subsystem Controller Product ID: Unknown
    Non-Volatile Size: None
    Volatile Size: 16 GB
    Cache Size: None
    Logical Size: None

Handle 0x0024, DMI type 17, 92 bytes
Memory Device
    Array Handle: 0x0022
    Error Information Handle: 0x0027
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 8192 MB
    Form Factor: SODIMM
    Set: None
    Locator: DIMM 0
    Bank Locator: P0 CHANNEL B
    Type: DDR4
    Type Detail: Synchronous Unbuffered (Unregistered)
    Speed: 3200 MT/s
    Manufacturer: Samsung
    Serial Number: 00000000
    Asset Tag: Not Specified
    Part Number: M471A1G44AB0-CWE    
    Rank: 1
    Configured Memory Speed: 3200 MT/s
    Minimum Voltage: 1.2 V
    Maximum Voltage: 1.2 V
    Configured Voltage: 1.2 V
    Memory Technology: DRAM
    Memory Operating Mode Capability: Volatile memory
    Firmware Version: Unknown
    Module Manufacturer ID: Bank 1, Hex 0xCE
    Module Product ID: Unknown
    Memory Subsystem Controller Manufacturer ID: Unknown
    Memory Subsystem Controller Product ID: Unknown
    Non-Volatile Size: None
    Volatile Size: 8 GB
    Cache Size: None
    Logical Size: None

Linux：Ubuntu 20.04.6 LTS

我可以采取什么措施来查看我的所有 RAM 还是这是硬件问题？

UPD Journalctl -b0 -k 日志：

    BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
BIOS-e820: [mem 0x000000000009f000-0x00000000000bffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x0000000009efffff] usable
BIOS-e820: [mem 0x0000000009f00000-0x0000000009f0efff] ACPI NVS
BIOS-e820: [mem 0x0000000009f0f000-0x00000000b89e8fff] usable
BIOS-e820: [mem 0x00000000b89e9000-0x00000000babe8fff] reserved
BIOS-e820: [mem 0x00000000babe9000-0x00000000c8dfefff] usable
BIOS-e820: [mem 0x00000000c8dff000-0x00000000cbdfefff] reserved
BIOS-e820: [mem 0x00000000cbdff000-0x00000000cdf7efff] ACPI NVS
BIOS-e820: [mem 0x00000000cdf7f000-0x00000000cdffefff] ACPI data
BIOS-e820: [mem 0x00000000cdfff000-0x00000000cdffffff] usable
BIOS-e820: [mem 0x00000000ce000000-0x00000000cfffffff] reserved
BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
BIOS-e820: [mem 0x00000000fdc00000-0x00000000fdcfffff] reserved
BIOS-e820: [mem 0x00000000fe000000-0x00000000fe0fffff] reserved
BIOS-e820: [mem 0x00000000fec00000-0x00000000fec01fff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
BIOS-e820: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
BIOS-e820: [mem 0x00000000fed80000-0x00000000fed81fff] reserved
BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x0000000100000000-0x000000052e2fffff] usable
BIOS-e820: [mem 0x000000052e300000-0x000000062fffffff] reserved

extended physical RAM map:
reserve setup_data: [mem 0x0000000000000000-0x000000000009efff] usable
reserve setup_data: [mem 0x000000000009f000-0x00000000000bffff] reserved
reserve setup_data: [mem 0x0000000000100000-0x0000000009efffff] usable
reserve setup_data: [mem 0x0000000009f00000-0x0000000009f0efff] ACPI NVS
reserve setup_data: [mem 0x0000000009f0f000-0x00000000adb86017] usable
reserve setup_data: [mem 0x00000000adb86018-0x00000000adb93857] usable
reserve setup_data: [mem 0x00000000adb93858-0x00000000b2f69017] usable
reserve setup_data: [mem 0x00000000b2f69018-0x00000000b2f77057] usable
reserve setup_data: [mem 0x00000000b2f77058-0x00000000b89e8fff] usable
reserve setup_data: [mem 0x00000000b89e9000-0x00000000babe8fff] reserved
reserve setup_data: [mem 0x00000000babe9000-0x00000000c8dfefff] usable
reserve setup_data: [mem 0x00000000c8dff000-0x00000000cbdfefff] reserved
reserve setup_data: [mem 0x00000000cbdff000-0x00000000cdf7efff] ACPI NVS
reserve setup_data: [mem 0x00000000cdf7f000-0x00000000cdffefff] ACPI data
reserve setup_data: [mem 0x00000000cdfff000-0x00000000cdffffff] usable
reserve setup_data: [mem 0x00000000ce000000-0x00000000cfffffff] reserved
reserve setup_data: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
reserve setup_data: [mem 0x00000000fdc00000-0x00000000fdcfffff] reserved
reserve setup_data: [mem 0x00000000fe000000-0x00000000fe0fffff] reserved
reserve setup_data: [mem 0x00000000fec00000-0x00000000fec01fff] reserved
reserve setup_data: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
reserve setup_data: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
reserve setup_data: [mem 0x00000000fed80000-0x00000000fed81fff] reserved
reserve setup_data: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
reserve setup_data: [mem 0x0000000100000000-0x000000052e2fffff] usable
reserve setup_data: [mem 0x000000052e300000-0x000000062fffffff] reserved

e820: reserve RAM buffer [mem 0x0009f000-0x0009ffff]
e820: reserve RAM buffer [mem 0x09f00000-0x0bffffff]
e820: reserve RAM buffer [mem 0xadb86018-0xafffffff]
e820: reserve RAM buffer [mem 0xb2f69018-0xb3ffffff]
e820: reserve RAM buffer [mem 0xb321f000-0xb3ffffff]
e820: reserve RAM buffer [mem 0xb3351000-0xb3ffffff]
e820: reserve RAM buffer [mem 0xb89e9000-0xbbffffff]
e820: reserve RAM buffer [mem 0xc8dff000-0xcbffffff]
e820: reserve RAM buffer [mem 0xce000000-0xcfffffff]
e820: reserve RAM buffer [mem 0x52e300000-0x52fffffff]

[drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
amdgpu 0000:05:00.0: amdgpu: VRAM: 4096M 0x000000F400000000 - 0x000000F4FFFFFFFF (4096M used)
amdgpu 0000:05:00.0: amdgpu: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
amdgpu 0000:05:00.0: amdgpu: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF
[drm] Detected VRAM RAM=4096M, BAR=4096M
[drm] RAM width 128bits DDR4
[drm] amdgpu: 4096M of VRAM memory ready
[drm] amdgpu: 4096M of GTT memory ready.
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] PCIE GART of 1024M enabled.
[drm] PTB located at 0x000000F400900000

背景：
我购买了一台新电脑，在过去的两个月里，我经历了三次电脑死机。当它冻结时，除了重新启动计算机之外我别无选择。last -x显示：

nav    tty7         :0               Fri Jun 16 20:36 - crash  (00:19)

在运行 Memtest86+ 时，它在第一次运行时通过了，但我让它运行另一遍，然后失败了。关闭 XMP 后，没有出现任何故障。我将RAM频率从3200MHz降低到3000MHz，经过6次也没有出现故障。

问：
有人告诉我，由于 RAM 在 XMP 上运行了两个月，而且即使我下载并安装的操作系统也是在使用该 RAM 时进行的，因此无法确定有多少文件可能因翻转而损坏RAM 中的位。所以我被建议重新安装我的操作系统。
在我看来，我需要重新安装的不仅仅是操作系统。我还必须重新下载我使用的所有其他软件的所有安装程序文件。那部分还可以。
但我的所有个人文件都必须复制到外部磁盘并复制回来。这些个人文件是否也可能已损坏？安装操作系统后，我将这些文件从外部 HDD 复制到我的 SDD。但即使是通过RAM，那不是还有CRC校验吗这确保了文件的完整性？
那么哪些文件可能已损坏，我真的需要重新安装操作系统和其他软件吗？

我运行了一些命令（在脚本中快速）并得到了这个：

$ ps -A | wc -l
513

$ echo "$((`ps -A -o rss |tr "\n" +`0))"
4368208

$ free
              total        used        free      shared  buff/cache   available
Mem:        5993608     5157844      132848       42616      702916      519028
Swap:      21030892     5276136    15754756

$ cat /proc/meminfo
MemTotal:        5993608 kB
MemFree:          132996 kB
MemAvailable:     519176 kB
Buffers:           83384 kB
Cached:           514368 kB
SwapCached:       422808 kB
Active:           392060 kB
Inactive:        1572336 kB
Active(anon):     106632 kB
Inactive(anon):  1312656 kB
Active(file):     285428 kB
Inactive(file):   259680 kB
Unevictable:       27084 kB
Mlocked:           27084 kB
SwapTotal:      21030892 kB
SwapFree:       15754756 kB
Dirty:               264 kB
Writeback:             0 kB
AnonPages:       1190852 kB
Mapped:          1107036 kB
Shmem:             42616 kB
KReclaimable:     105164 kB
Slab:             291468 kB
SReclaimable:     105164 kB
SUnreclaim:       186304 kB
KernelStack:       19376 kB
PageTables:        58636 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    24027696 kB
Committed_AS:   14543756 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      117308 kB
VmallocChunk:          0 kB
Percpu:             7072 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 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:     5936768 kB
DirectMap2M:      335872 kB
DirectMap1G:           0 kB

789636 kB (5157844-4368208) 去哪儿了？
我的最终目标是确定什么正在使用该 RAM，以及是否可以释放它。
如果可能的话，我需要能够列出正在使用该 RAM 的内容。
有更好的ps命令参数吗？

相关：
RAM 使用量不加起来？(Free+used < total)
大部分已用内存没有被用户进程占用

当我看到这个短语（或类似短语）时，例如今天在如何在 Linux 上使用免费命令（2020 年日期的文章）：

未用于某事的 RAM 是浪费的 RAM

我记得用于移动设备的LPDDR ：

额外的节省来自温度补偿刷新（DRAM 在低温下需要较少刷新）、部分阵列自刷新和牺牲所有内存内容的“深度断电”模式。

由于Android是基于Linux内核的，是否已经支持将部分内存放入“深度掉电”？一些内核参数可以以最小化总内存使用的方式管理数据？

总的来说：Linux内核是否已经放弃了普遍应用“没有被用于某事的RAM是浪费RAM”的方法？

我用来GNU make在 R 中启动不同写入/读取调用的基准测试。在某些情况下，这将导致我的 RAM 被完全使用并且进程被终止（这很好，因为我想查看限制）。

然而问题是，整个制作过程被杀死，而不仅仅是特定的脚本调用。

例如，假设我有以下Makefile，目标small.csv工作正常，large.csv崩溃（有点预期），但现在其他...目标没有构建。

问题是，我怎样才能Rscript tester --size large以某种方式启动进程（），以便在一个进程被杀死后make继续其他（ ）基准测试？...

# Makefile

.PHONY: all

all: small.csv large.csv ...

small.csv: tester.R
    Rscript tester.R --size small

large.csv: tester.R
    Rscript tester.R --size large

...

请注意，脚本在第一行接触了目标，因此无论运行是否被终止，都会始终创建目标。

我正在使用带有 XFCE DE 和 XFWM4 WM 的 Arch Linux (5.1.8-arch1-1-ARCH)。事情非常优雅，RAM 和 CPU 使用率很低。

启动后，当 DE 完全加载后，我看到 665 MiB 的 RAM 使用量。

但是在打开 Atom、Code、Firefox、Chromium 等应用程序后，或在 GIMP、Blender 等中工作后，RAM 使用量会增加，这是显而易见的。但是在关闭所有应用程序并且只剩下一个 gnome-system-monitor 之后，我可以看到 RAM 使用量为 1.2 - 1.4 GiB。/proc/meminfo 与 gnome-system-monitor 一致，但 htop 始终给出不同的结果。

更糟糕的是，当我稍后打开一个占用 RAM 的应用程序时，它再次消耗了 1.4 GiB 之上所需的内存。情况总是如此。/tmp/ 目录中没有存储可能加起来达到兆字节的文件。

此外，如果我寻找使用那么多 RAM 的进程（从开始时的 700 MiB 到关闭浏览器后的 1.4 GiB ！！），我什么也看不到。事实上，即使在运行 Arch ARM 的树莓派上，我也遇到了同样的问题。

红宝石代码：

#!/usr/bin/ruby -w
STDOUT.sync = true

loop do
    IO.readlines(File.join(%w(/ proc meminfo))).then { |x| [x[0], x[2]] }.map { |x| x.split[1].to_i }.reduce(:-)
        .tap { |x| print "\e[2K\rRAM Usage:".ljust(20), "#{x / 1024.0} MiB".ljust(24), "#{(x / 1000.0)} MB" }
    Kernel.sleep(0.1)
end

该cat /proc/meminfo命令具有以下输出：

MemTotal:        3851796 kB
MemFree:         1135680 kB
MemAvailable:    2055708 kB
Buffers:            1048 kB
Cached:          1463960 kB
SwapCached:          284 kB
Active:          1622148 kB
Inactive:         660952 kB
Active(anon):     923580 kB
Inactive(anon):   269360 kB
Active(file):     698568 kB
Inactive(file):   391592 kB
Unevictable:      107012 kB
Mlocked:              32 kB
SwapTotal:       3978216 kB
SwapFree:        3966696 kB
Dirty:               280 kB
Writeback:             0 kB
AnonPages:        924844 kB
Mapped:           563732 kB
Shmem:            374848 kB
KReclaimable:      74972 kB
Slab:             130016 kB
SReclaimable:      74972 kB
SUnreclaim:        55044 kB
KernelStack:        8000 kB
PageTables:        14700 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     5904112 kB
Committed_AS:    3320548 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
Percpu:             1456 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      226736 kB
DirectMap2M:     3778560 kB
DirectMap1G:           0 kB

首先，您注意到 htop 从不同意。我对此知之甚少。

其次，您可以看到 xfdesktop 使用 44 MiB，而其他一些进程使用了​​一些内存，内核使用了 ~150 MiB，除此之外，为什么我看到正在使用 1.5 GiB RAM？这真的会影响系统的性能吗？

众所周知，cgroups可以限制进程的cpu使用。这是一个例子：

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND          
30142 root      20   0  104m 2520 1024 R 99.7  0.1  14:38.97 sh

我有一个进程，其 pid 为 30142。我可以将其限制如下：

mkdir -p /sys/fs/cgroup/memory/foo
echo 1048576 >  /cgroup/memory/foo/memory.limit_in_bytes
echo 30142 > /cgroup/memory/foo/tasks

正如我们看到的，如果我想限制一个进程，我必须先执行它，然后我可以根据它的pid来限制它。是否可以根据名称来限制进程？是否可以在执行之前限制进程？

如果安装了没有交换分区或交换文件的 Linux，比如 Arch Linux 或 Debian，会发生什么情况。然后，当在几乎没有 RAM 的情况下运行操作系统时，用户会打开一个新应用程序。考虑到这个新应用程序需要的 RAM 内存比实际需要的多，会发生什么？

操作系统的哪一部分处理 RAM 管理操作，我可以将其配置为不同的行为吗？

Memtester 已输出以下响应，

memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 10240MB (10737418240 bytes)
got  10240MB (10737418240 bytes), trying mlock ...locked.
Loop 1/1:
  Stuck Address       : testing   1FAILURE: possible bad address line at offset 0x12325b7a8.
Skipping to next test...
  Random Value        : ok
FAILURE: 0xa003776ad640ac0c != 0xe003776ad640ac0c at offset 0x7a4f2680.
  Compare XOR         : FAILURE: 0xe7139f89d94112c0 != 0x27139f89d94112c0 at offset 0x7a4f2680.
FAILURE: 0x4e53ee3a9704bdf5 != 0x4a53ee3a9704bdf5 at offset 0x950b4930.
  Compare SUB         : FAILURE: 0x96ecab120464e9c0 != 0xd6ecab120464e9c0 at offset 0x7a4f2680.
FAILURE: 0x7f67022cef637b99 != 0x2b67022cef637b99 at offset 0x950b4930.
FAILURE: 0x96c38c9f6e6dd229 != 0xd6c38c9f6e6dd229 at offset 0xe40d2b50.
  Compare MUL         : FAILURE: 0x00000001 != 0x00000002 at offset 0x69394a08.
FAILURE: 0x00000001 != 0x00000000 at offset 0x950b4930.
FAILURE: 0x400000000000001 != 0x00000001 at offset 0xea6b07a8.
FAILURE: 0x400000000000000 != 0x00000000 at offset 0xfb853610.
FAILURE: 0x00000000 != 0x800000000000000 at offset 0x12bf3ed10.
  Compare DIV         : FAILURE: 0x777fd9f1ddc6c1cd != 0x777fd9f1ddc6c1cf at offset 0x69394a08.
FAILURE: 0x777fd9f1ddc6c1cd != 0x7f7fd9f1ddc6c1cd at offset 0x12bf3ed10.
  Compare OR          : FAILURE: 0x367600d19dc6c040 != 0x367600d19dc6c042 at offset 0x69394a08.
FAILURE: 0x367600d19dc6c040 != 0x767600d19dc6c040 at offset 0x7a4f2680.
FAILURE: 0x367600d19dc6c040 != 0x3e7600d19dc6c040 at offset 0x12bf3ed10.
  Compare AND         :   Sequential Increment: ok
  Solid Bits          : testing   0FAILURE: 0x4000000000000000 != 0x00000000 at offset 0x12325b7a8.
  Block Sequential    : testing   0FAILURE: 0x400000000000000 != 0x00000000 at offset 0xfb853610.
  Checkerboard        : testing   1FAILURE: 0xaaaaaaaaaaaaaaaa != 0xeaaaaaaaaaaaaaaa at offset 0x7a4f2680.
  Bit Spread          : testing   1FAILURE: 0xdffffffffffffff5 != 0xfffffffffffffff5 at offset 0x102e353e8.
  Bit Flip            : testing   0FAILURE: 0x4000000000000001 != 0x00000001 at offset 0x12325b7a8.
  Walking Ones        : testing  40FAILURE: 0xdffffeffffffffff != 0xfffffeffffffffff at offset 0x102e353e8.
  Walking Zeroes      : testing   0FAILURE: 0x400000000000001 != 0x00000001 at offset 0xea6b07a8.
FAILURE: 0x400000000000001 != 0x00000001 at offset 0xfb853610.
  8-bit Writes        : -FAILURE: 0xfeefa0a577dfa825 != 0xdeefa0a577dfa825 at offset 0x4bd600e8.
  16-bit Writes       : -FAILURE: 0xf3dfa5fff79e950b != 0xf7dfa5fff79e950b at offset 0x2b04cca8.
FAILURE: 0x3ffb3fc56e7532c1 != 0x7ffb3fc56e7532c1 at offset 0xe40d2b50.

Done.

很明显，这表明记性不好。是否可以在内核或管理程序中将此内存标记为坏并继续使用它？还是将其放入文件 13 并购买替换？

所以我是 ram 昂贵的应用程序的新手，我真的不知道交换是如何工作的......

我只有 10GiB 的内存（它是一个虚拟机）和 500GB/1TB 的可用硬盘空间

Java 应用程序需要大约 150/200GiB 的内存才能运行，但我可以将其减少到 64GiB。我认为不是所有东西都同时加载，但Java仍然需要分配堆空间

我应该分配多少交换空间？它将如何运作？操作系统将如何响应？（我知道它在 ram 已满/减少 ram 使用时使用，但遗憾的是我没有找到更多有用的信息）