Linux下调试内存写入性能：两进程AtomicUsize写入耗时悬殊问题

我有两个近乎相同的进程，通过共享内存进行通信。每当一个进程收到另一个进程的消息时，会在自己的内存映射文件中对一个8字节的usize整数执行AtomicUsize的store操作（两个进程各有独立的文件，不共享）。奇怪的是，其中一个进程执行该操作平均耗时16ns，另一个则需要约137ns，性能数据如下：

进程1

p50: 15.00 ns, p90: 16.00 ns, p99: 94.00 ns, p99.9: 142.00 ns, p99.99: 422.00 ns, p99.999: 504.00 ns
max: 11.97 μs, avg: 16.00 ns

进程2

p50: 114.00 ns, p90: 320.00 ns, p99: 664.00 ns, p99.9: 1.07 μs, p99.99: 1.45 μs, p99.999: 4.45 μs
max: 10.69 μs, avg: 137.00 ns

测试用的Rust代码片段：

let t1 = Instant::now();
let offset_ptr = self.index.as_mut_ptr::<AtomicUsize>();
(*offset_ptr).store(self.topic.offset, Ordering::Relaxed);
let t2 = Instant::now();

不清楚该如何分析这一性能差异，请问可能的原因是什么，以及该如何调试？

• 内存页状态差异：进程2的映射页可能被换入/换出交换区（系统内存不足时），或者频繁被其他进程挤出CPU缓存（L1/L2/L3），每次store都要从主存甚至磁盘重新加载页，导致延迟飙升；而进程1的映射页始终驻留在缓存中。
• 进程调度优先级/亲和性差异：进程2的nice值更高（优先级更低），操作系统更频繁抢占它的CPU时间片，统计耗时包含了调度等待；或者进程2未绑定固定CPU核心，在多核心间游走时频繁刷新缓存，增加延迟。
• 内存映射/文件系统差异：两个进程的mmap参数可能有细微差别（比如是否设置MAP_POPULATE预加载页）；或者两个独立文件位于不同存储介质（一个SSD一个HDD）、文件碎片化程度不同，导致映射页访问效率差异。
• 进程内部资源竞争：进程2有其他后台线程/任务在占用CPU或内存带宽（比如大量IO、计算密集型任务），污染缓存或抢占store操作的执行周期。
• 消息频率差异：进程2接收消息的频率过高，导致store操作密集，缓存压力大；或者间隔太长，映射页被缓存逐出，每次操作都要重新加载。
• 编译/代码隐性差异：两个进程的编译参数不同（比如一个开启额外优化、一个有调试残留），生成的机器码效率有差；或者self.index的映射逻辑存在隐性差异（比如文件描述符权限、映射偏移）。

• 排查内存页状态：用pmap -x <pid>查看进程的内存映射，对比两个进程的RSS（常驻内存）和Dirty（脏页）大小，看进程2的映射页是否大量不在RSS中；用vmstat观察系统swap活动，确认是否有频繁换入换出。
• 检查进程调度属性：用ps -eo pid,ni,pri,pcpu,cmd查看nice值和优先级；用taskset -p <pid>检查CPU亲和性；用perf stat -p <pid>统计上下文切换次数，看进程2是否被频繁抢占。
• 对比映射配置与文件状态：仔细核对两个进程的mmap参数（flags、prot、offset等）；用df -T查看文件所在文件系统类型，filefrag -v检查文件碎片化程度。
• 分析进程内部资源：用htop观察进程的CPU、内存占用，看进程2是否有其他线程占用资源；用perf record -p <pid> -g采集性能数据，再用perf report查看缓存未命中（L1-dcache-load-misses、LLC-load-misses）情况，定位瓶颈点。
• 验证代码与编译一致性：确认两个进程用完全相同的编译参数（比如都是cargo build --release）；在代码中输出self.index的映射地址、文件描述符等信息，确认映射配置一致；交换两个进程的任务角色，看延迟是否随任务转移，判断是进程本身还是负载问题。
• 精准测试内存访问：写独立测试程序，直接对两个文件的映射页执行AtomicUsize::store，排除共享通信的干扰；用core::arch::x86_64::_rdtsc()获取CPU周期数，更精准地测量store操作的实际耗时，避免Instant的潜在误差。

内容的提问来源于stack exchange，提问作者Samuel Hapak