http://200yi.com/ff_internal/ 2026-04-28T04:46:50+0800 http://200yi.com/ff_internal/ http://200yi.com/ff_internal/lib/tpl/mnml-blog/images/favicon.ico text/html 2023-06-17T21:25:18+0800 Anonymous (anonymous@undisclosed.example.com) http://200yi.com/ff_internal/wiki.php?id=wiki:OS:Linux:%E6%80%A7%E8%83%BD:Linux%E7%8E%AF%E5%A2%83%E5%86%99%E6%96%87%E4%BB%B6%E5%A6%82%E4%BD%95%E7%A8%B3%E5%AE%9A%E8%B7%91%E6%BB%A1%E7%A3%81%E7%9B%98IO%E5%B8%A6%E5%AE%BD&rev=1687008318&do=diff 转自：Linux 环境写文件如何稳定跑满磁盘 I/O 带宽? 准备 要求 在 限制内存 的情况下，假定我们每次写入 4k 的数据，如何保证 kill -9 不丢数据的情况下，仍然稳定的跑满磁盘的 IO？因为需要保证 kill -9 不丢数据，所以 fwrite() 就不在我们的考虑范围之内了. 又因为限制内存，所以直观的想法是直接 Direct IO, 但 Direct IO 能否跑满磁盘 IO 呢? text/html 2023-06-17T21:25:18+0800 Anonymous (anonymous@undisclosed.example.com) http://200yi.com/ff_internal/wiki.php?id=wiki:OS:Linux:%E6%80%A7%E8%83%BD:perf%20top%E6%B2%A1%E6%9C%89%E8%AE%B0%E5%BD%95%E9%97%AE%E9%A2%98&rev=1687008318&do=diff 相关讨论： * Bug 203203 - Perf 'top -p PID' no longer records any samples text/html 2023-06-17T21:25:18+0800 Anonymous (anonymous@undisclosed.example.com) http://200yi.com/ff_internal/wiki.php?id=wiki:OS:Linux:%E6%80%A7%E8%83%BD:%E6%99%AE%E9%80%9A%E7%94%A8%E6%88%B7%E6%89%A7%E8%A1%8Cperf%20top%E5%91%BD%E4%BB%A4&rev=1687008318&do=diff 问题 使用普通用户执行perf top命令通常无法执行，报告以下错误（You may not have permission to collect system-wide stats ...）： [image] 解决方法 临时修改方法1： sudo sh -c 'echo 1 > /proc/sys/kernel/perf_event_paranoid' text/html 2023-06-17T21:25:18+0800 Anonymous (anonymous@undisclosed.example.com) http://200yi.com/ff_internal/wiki.php?id=wiki:OS:Linux:%E6%80%A7%E8%83%BD:%E4%BD%BF%E7%94%A8%E8%AE%A1%E7%AE%97PI%E7%9A%84%E6%96%B9%E6%B3%95%E7%AE%80%E5%8D%95%E8%AF%84%E4%BC%B0CPU%E6%80%A7%E8%83%BD&rev=1687008318&do=diff Linux系统下，可以用计算π的方法来简单评估CPU单核计算性能。 一、方法 [root@yz219 ~]# time echo "scale=5000; 4*a(1)" | bc -l -q 3.141592653589793238462643383279502884197169399375105820974944592307\ 81640628620899862803482534211706798214808651328230664709384460955058\ 22317253594081284811174502841027019385211055596446229489549303819644\ …… real 0m20.190s user 0m20.126s sys 0m0.082s