Linux下C/C++程序读Samba共享PDF卡顿，如何用Valgrind排查

1. 用strace分析IO系统调用细节 #

Valgrind的callgrind仅统计CPU耗时，无法追踪IO等待，因此需要通过strace查看程序的实际读写行为：

strace -tt -e trace=read,write,open,close ./myprogram /sambasrv/share/myfile.pdf 2>&1 | grep -E "(read|write)"

重点观察每次read调用的字节数，如果出现大量read(..., 1, ...)或极小块尺寸（几十字节级）的读操作，就是问题核心——网络共享环境下，小尺寸读会触发大量Samba服务器往返请求，累积延迟导致总耗时飙升。同时可以对比程序处理本地PDF时的strace输出，明确IO模式的差异。

2. 用perf分析IO阻塞耗时 #

perf可以追踪程序的阻塞时间（包括网络IO等待），弥补callgrind的局限性：

• 录制程序运行数据：

  perf record -g ./myprogram /sambasrv/share/myfile.pdf
  

• 生成报告查看耗时分布：

  perf report
  

  重点关注syscalls:sys_read或Samba相关内核函数的耗时占比，以及调用栈中是否有大量时间消耗在IO等待上。也可以用perf top -p <进程PID>实时观察运行中程序的耗时热点。

3. 模拟程序IO模式验证问题 #

手动模拟程序的读写方式，验证是否由小尺寸IO导致性能问题：

• 若怀疑是逐字节读，运行：

  dd if=/sambasrv/share/myfile.pdf of=/dev/null bs=1
  

  查看该命令的耗时是否与程序处理时间接近；若换成bs=4096（常见文件系统块大小）后耗时骤降，即可确认程序IO块尺寸过小的问题。

4. 检查文件打开参数与缓存策略 #

查看程序是否使用了绕过缓存的打开方式，这会让每次读操作直接请求Samba服务器：

• 通过strace的open调用输出，确认是否带有O_DIRECT标记，例如：

  open("/sambasrv/share/myfile.pdf", O_RDONLY|O_DIRECT) = 3
  

  若存在该标记，就是问题所在。另外可检查Samba挂载参数，比如是否启用noac（禁用属性缓存），临时重新挂载测试：

  sudo mount -o remount,ac /sambasrv/share
  

  再运行程序观察耗时是否改善。

5. 用ltrace分析第三方库的IO行为 #

如果程序依赖libpoppler等PDF处理库，用ltrace追踪库函数的读写调用：

ltrace -tt -e fread,fgetc,fgets ./myprogram /sambasrv/share/myfile.pdf

查看是否存在频繁调用fgetc（逐字节读）或fread每次只读极小尺寸数据的情况——部分PDF处理库若配置不当，会出现这类低效IO模式。

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