主页 / user-11377

Jan Hudec's questions

Martin Hope
Jan Hudec
Asked: 2022-01-19 01:28:51 +0800 CST
  • 2

我正在尝试设置一些监视以查看服务何时使用过多内存。可以从两个地方读取内存使用情况：

  • 用于/proc/<pid>/statuspid，或
  • 用于运行它的/sys/fs/cgroup/<group-id>/memory.stat对照组。

该服务由 systemd 启动，因此它有自己的控制组，并且因为它有时会启动我需要包含在统计信息中的子进程，并且因为路径在重新启动时是恒定的，所以控制组统计信息更合适。

不幸的是，数字似乎不匹配。这是没有子进程运行时的值示例（命令与执行完全相同，除了服务名称，结果与获取完全相同，除了与内存相关的项目被删除）：

# cat /sys/fs/cgroup/system.slice/some.service/memory.stat /proc/$(cat /sys/fs/cgroup/system.slice/some.service/cgroup.procs)/status
anon 5873664
file 2408448
kernel_stack 491520
slab 962560
sock 0
shmem 61440
file_mapped 405504
file_dirty 0
file_writeback 0
inactive_anon 0
active_anon 5853184
inactive_file 1916928
active_file 360448
unevictable 0
slab_reclaimable 270336
slab_unreclaimable 692224
pgfault 60258
pgmajfault 99
pgrefill 0
pgscan 0
pgsteal 0
pgactivate 0
pgdeactivate 0
pglazyfree 0
pglazyfreed 0
workingset_refault 0
workingset_activate 0
workingset_nodereclaim 0
…
VmPeak:   494812 kB
VmSize:   494164 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:     25836 kB
VmRSS:     25484 kB
RssAnon:            5468 kB
RssFile:           20016 kB
RssShmem:              0 kB
VmData:   464776 kB
VmStk:       132 kB
VmExe:       180 kB
VmLib:     23940 kB
VmPTE:       156 kB
VmSwap:        0 kB
voluntary_ctxt_switches:        9
nonvoluntary_ctxt_switches:     620

我会认为过程统计中的适当值是VmRSS(= RssAnon+ RssFile+ RssShmem)。但是，虽然我认为anon小组应该RssAnon属于过程，file小组应该RssFile属于过程，但它们并不匹配。虽然anon是 5736 KB，RssAnon但只有 5468 KB，而对于文件来说差异更大，file只有 2352 KB，但RssFile为 20016 KB，几乎是数量级的差异。

还有memory.current一个值与anon+ file+ kernel_stack+ slab+ sock+大致匹配的文件shmem，但我在进程状态中看不到任何匹配值。

那么为什么这些数字如此不同，哪些数字更能说明应用程序对系统施加的内存压力呢？

注意：在内核 4.19.72（稍微陈旧的嵌入式 BSP）上使用 cgroup2。

memory virtual-memory
Martin Hope
Jan Hudec
Asked: 2019-05-18 05:11:58 +0800 CST
  • 14

TCP KeepAlive（套接字选项SO_KEEPALIVE）由三个选项控制——机制触发的时间、探测间隔和连接被声明断开之后的失败探测数。

它们的默认值是：

  • tcp_keepalive_time = 7200
  • tcp_keepalive_intvl = 75
  • tcp_keepalive_probes = 9

在 1¼ 分钟后发送探测听起来很合理，在 9 次失败探测后声明失败也是如此，但初始时间为2 小时背后的想法是什么？

甚至tcp(7)说

请注意，底层连接跟踪机制和应用程序超时可能要短得多。

启用 keepalive 的主要目的是防止任何有状态的网络元素丢弃状态信息，但这些元素往往会在几分钟内丢弃连接。对于一些速率受限的服务器，curl用short--keepalive-time似乎可以显着提高下载的可靠性。

那么为什么默认这么长呢？

tcp networking