mark

介绍: 强制停用的服务，无法手动启用

屏蔽服务

systemctl mask <服务>

systemctl mask --now <服务> #屏蔽并关闭服务

解除屏蔽

systemctl unmask <服务>

systemctl unmask --now <服务> #解除并开启服务

转:linux 网桥配置

 

使用 Bridge网桥（最常用）

创建网桥，让多个容器通过网桥互联并访问外部网络。

bash

# 1. 创建网桥
sudo ip link add br0 type bridge
sudo ip link set br0 up
sudo ip addr add 192.168.100.1/24 dev br0

# 2. 创建veth pair
sudo ip link add veth-host type veth peer name veth-container

# 3. 将veth-host连接到网桥
sudo ip link set veth-host master br0
sudo ip link set veth-host up

# 4. 创建命名空间并移动veth-container
sudo ip netns add container1
sudo ip link set veth-container netns container1
sudo ip netns exec container1 ip link set veth-container up
sudo ip netns exec container1 ip addr add 192.168.100.100/24 dev veth-container

# 5. 启用NAT转发（让容器能访问外网）
sudo iptables -t nat -A POSTROUTING -s 192.168.100.0/24 ! -o br0 -j MASQUERADE
sudo sysctl -w net.ipv4.ip_forward=1

问题:Buff/Cache 中不可以算到Availabe中的部分是什么？

 交流中被问到free -h中为什么Available 比Buff/Cache小

查询发现Available估算时Buff/Cache有无法使用的部分，

是

Buff/Cache中不可立即回收（不能完全算入Available）的部分主要包括：

1. 脏页：已被修改但尚未写入磁盘的数据。

2. 正在被使用的页：有进程正在直接读取或写入的缓存页。

3. 被锁定在内存中的页：通过mlock()系统调用锁定的页。

4. 内核数据结构占用的Slab内存中的不可回收部分。

1. 脏页 - 最大的“不确定因素”

• 是什么：数据已在内存中被修改，但与磁盘上的版本不一致。内核必须先将它们写回磁盘，才能回收这些内存页。

• 影响：如果系统有大量写入操作（如数据库、日志写入），脏页会很多。回收它们需要等待I/O完成，因此不能立即提供给应用程序。

• 查看命令：

  bash

  grep -E 'Dirty|Writeback' /proc/meminfo

  输出示例：

  text

  Dirty:            12456 kB      # 待写回的脏数据量
  Writeback:          432 kB      # 正在写回的数据量

2. 正在被使用的页

• 是什么：某个进程正在通过read()或write()系统调用访问的缓存页。回收会导致进程I/O错误。

• 影响：通常比例很小，但存在。

3. 被锁定的页

• 是什么：通过mlock()系统调用明确要求常驻内存的页（如一些实时性要求高的应用、加密密钥）。

• 影响：明确不可回收。

4. Slab内存中的不可回收部分

• 是什么：/proc/meminfo中的SReclaimable（可回收Slab）被计入Buff/Cache，而SUnreclaim（不可回收Slab）则不被计入。

  • 可回收Slab：如目录项缓存（dentry）、索引节点缓存（inode_cache）。这些可被回收，并被计入Available。

  • 不可回收Slab：一些内核数据结构占用的内存，无法回收。

• 查看命令：

  bash

  grep -E 'SReclaimable|SUnreclaim' /proc/meminfo

---

内核如何计算 Available？（深入原理）

Available 的值在 /proc/meminfo 中是这样计算的（简化版）：

bash

# 查看精确值
grep Available /proc/meminfo

# 内核的估算逻辑（概念上）：
Available = Free + (PageCache的总和 - 其中不可立即回收的部分) + (SReclaimable * 权重系数)

不可立即回收的部分 主要通过以下方式估算：

1. 统计所有“干净”的页面（未修改的缓存），这些可以瞬间回收。

2. 估算回收“脏页”的成本，并根据系统当前压力、I/O负载等因素，决定将多大比例的脏页计入“可用”资源。在内存压力不大时，内核可能保守估计；压力大时，会更积极地将脏页的潜在回收能力计入。

---

一个具体的诊断例子

假设您的系统 free -h 显示：

text

              total        used        free      shared  buff/cache   available
Mem:            16Gi        10Gi       500Mi       1.0Gi        5.5Gi        4.5Gi

分析：

• buff/cache 有 5.5Gi

• available 有 4.5Gi

• free 只有 500Mi

计算 available 的来源：
4.5Gi ≈ 0.5Gi (free) + [5.5Gi (buff/cache) - 约 1.5Gi (不可立即回收部分)]

查看这“约1.5Gi”不可回收部分的具体构成：

bash

# 1. 查看脏页大小
cat /proc/meminfo | grep Dirty
# 假设输出 Dirty: 800000 kB (约0.76Gi)

# 2. 查看Slab分配
cat /proc/meminfo | grep -E 'SReclaimable|SUnreclaim'
# SReclaimable:  400000 kB  (约0.38Gi，这部分是buff/cache的一部分且可回收)
# SUnreclaim:    200000 kB  (约0.19Gi，这部分不属于buff/cache)

# 3. 粗略估算
# 不可立即回收部分 ≈ 脏页 + 其他难以估算的正在使用的页
# ≈ 0.76Gi + (0.5Gi ~ 0.7Gi) ≈ 1.3Gi ~ 1.5Gi

这个估算结果与上面的分析基本吻合。

结论与建议

1. Available 是一个智能估算值，而非简单加减。它告诉你在不引起严重I/O阻塞或进程错误的前提下，能安全分配多少内存。

2. Buff/Cache 和 Available 的差值，主要反映了脏页的数量和回收成本。

3. 当系统内存压力极大时，内核会启动激进的后台回写，将脏页刷入磁盘，从而将它们转变为“干净页”，增加 Available 的估算值。但这个过程会导致I/O争用，可能使系统变慢。

当您需要精确分析时，请使用 cat /proc/meminfo 获取原始数据，并重点关注 Dirty, Writeback, SReclaimable 这几个指标。它们正是 Buff/Cache 中那些“看得见但暂时用不了”的部分。

问题：flask子类线程启动问题

 问题:_thread.start_new_thread(app.run())

_thread.start_new_thread(get_list()) 其中app=Flask(__name__) 为什么运行后_thread.start_new_thread(get_list()) 线程一直没有启动机会呢？flask类有什么特别的原因吗？

解决:

 Flask 应用默认是阻塞式的，它会独占主线程，导致后面的线程没有机会执行。

🔍 问题根源分析

app.run() 方法启动的 Flask 开发服务器是一个无限循环，它会一直监听 HTTP 请求，阻塞当前线程。因此，_thread.start_new_thread(get_list()) 这行代码根本没有机会执行。

✅ 解决方案

将 Flask 放在子线程中

穴位测试笔记-养老穴

 养老+灸: 左手30分钟左右，当时没有太多反应，但晚上的梦非常的焦虑，上课没有地方，一直在找，后来找到很多的非常小方形门有圆形开口的奇怪位置，原来是卫生间，自己没去但感觉还是不好，出来的位置说是课堂当有蛇胆做粥的地方，突然感觉很害怕就醒来了，总体感觉前期焦虑，后来害怕。不好。至少这个测试不好。2025-11-21晚8：45～9：15左右。---问了deepseek说是艾灸养老穴扰动心经了，所以焦虑，而22日是小寒本就是要阴阳分离的日子自己好像时间确实也不太恰当，但还是感觉有问题，首先养老是补小肠的吧？这个过程应该都是在入能量，如果都是入表里应该是心神的焦虑可以解释，但恐惧呢？火反克水？还是感觉牵强，但确实暂时不打算测试这个组合了。体感非常不好。

另外在想自己对感觉好的体验中，有多少是透支肾精来完成的，有多少是真正补益气血完成的？这个在第四环境实验中应该要考虑，并且最好有测量方式。

黑水晶球的反思

 

昨晚睡前吃了太多的面包可能是添加的内容太多自己和吞后半夜都无法入睡了，后来想起黑水晶的入眠作用就拿了黑水晶球到床边，果然睡着了可梦中焦虑万分 不是找不到书包就是赶不上火车，晨起和吞对了一下，他也梦中焦虑异常；和吞说了自己用黑水晶帮助入眠的事情，后悔自己的决定还不如不入睡呢！吞笑我又耍小聪明，有了锤子到处找钉子，把自己又赔进去了：）。

再次回到我们最近探讨的好医生到底应该如何的问题上，感叹身怀利器必起杀心的问题，最近吞一直感叹我几次用药把自己赔进去的事，谈到如何在利器之下得到中正自己的选择的问题。可后来自己反思，说是后来梦中焦虑有问题，确实我承认使用不当有问题，但没有这次尝试我又如何深刻理解这个力量的使用场景和潜在问题，看似是有问题，但未尝不是我的宝藏不是吗？也是人生难得经历的一部分，来了经历了就不后悔，

但之后再做其他测试考虑时多一份这个反蚀力量的警惕就好了。这样一想感觉不止平和很多，还感觉也没有什么问题了。所以这个过程也不是吞说自己的用小聪明，这个小聪明何尝不是大智慧的一部分呢？这个应该比什么都不做至少从我的角度来说更多了一步向智慧迈进的步伐不是吗？这样看其实没有绝对的是聪明的决定还是智慧的选择，这个和自己最近一直体悟的善恶是一样的，只要自己的目标在变，心态的改变就不用拘泥是不是小聪明，不是吗？写的过程突然发现，其实自己在乎的是被吞嘲笑自己一直在用小聪明，但这个路上的自己一直没有停过脚步，这个他说的小聪明于自己只是在向智慧靠近路上的修行方式，你只要目标明确何必在意吞的说法呢？如果真特别在意你还可以和他好好交流一下自己的体悟，而继续做自己的就好了，不是吗？

问题：linux 中top(1) ,malloc(3) 括号后的数字含义

 回答：[popexizhi:第一次非常郑重的感谢deepseek这个问题困扰自己很久了，之前看过很多资料都这样写，但就是没见过这样写的原因，终于找到了，非常感谢]

来自deepseek

在 Linux 的 man 手册系统中，命令后面括号里的数字表示该命令所属的手册章节。

手册章节详解

章节	内容类型	示例
1	用户命令	top(1), ls(1), vim(1)
2	系统调用	open(2), read(2), fork(2)
3	库函数	printf(3), malloc(3)
4	特殊文件	/dev/null(4), /dev/random(4)
5	文件格式	passwd(5), proc(5)
6	游戏
7	杂项	ascii(7), utf-8(7)
8	系统管理命令	vmstat(8), ifconfig(8)

---

具体到您的例子

• top(1)：属于第1章节，是普通用户可执行的命令

• vmstat(8)：属于第8章节，是系统管理员命令（通常需要 root 权限）

小提示：您提到的 mastat 可能是笔误，应为 vmstat。

---

为什么要有章节划分？

因为不同实体可能有相同名字，章节号帮助区分：

bash

# 查看 passwd 命令（修改密码）
man 1 passwd

# 查看 passwd 文件格式
man 5 passwd