标签: performance

为什么 wc 实用程序这么慢？

当我在一个大文件上运行它时，它比 md5sum 需要大约 20 倍的时间：

MyDesktop:/tmp$ dd if=/dev/zero bs=1024k count=1024 of=/tmp/bigfile
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.687094 s, 1.6 GB/s

MyDesktop:/tmp$ time wc /tmp/bigfile 
         0          0 1073741824 /tmp/bigfile

real    0m45.969s
user    0m45.424s
sys     0m0.424s

MyDesktop:/tmp$ time md5sum /tmp/bigfile 
cd573cfaace07e7949bc0c46028904ff  /tmp/bigfile

real    0m2.520s
user    0m2.196s
sys     0m0.316s

这不仅仅是由文件充满空值导致的奇怪边缘条件，即使文件充满随机数据或者是文本文件，我也看到了相同的性能差异。

（这是在 Ubuntu 13.04，64 位上）

我们希望在 Linux 文件系统中存储数百万个文本文件，目的是能够压缩并将任意集合作为服务提供服务。我们尝试了其他解决方案，例如键/值数据库，但我们对并发性和并行性的要求使使用本机文件系统成为最佳选择。

最直接的方法是将所有文件存储在一个文件夹中：

$ ls text_files/
1.txt
2.txt
3.txt

这在 EXT4 文件系统上应该是可能的，它对文件夹中的文件数量没有限制。

这两个 FS 进程将是：

1. 从网页抓取写入文本文件（不应受文件夹中文件数量的影响）。
2. 压缩选定的文件，由文件名列表给出。

我的问题是，在一个文件夹中存储多达 1000 万个文件是否会影响上述操作的性能或一般系统性能，这与为这些文件创建子文件夹树有什么不同？

我在我的工作站上运行了一些繁重的 I/O 进程，并且最近安装iotop了它们来监视它们。这是最近的截图：

我对IO>专栏中的读数有些困惑。它表明我的磁盘正在以大约 1500% 的 I/O 活动运行。这甚至可能吗？

如何从这些读数中找出磁盘的最大可能 I/O？iotop 是如何计算相对 I/O 活动的？

有时，我系统上的某些东西开始敲打磁盘。我想记录可以让我知道每个进程的 I/O 使用情况的数据，然后我可以稍后再回到它，看看是什么继续这样做。我应该如何解决这个问题？为任意块设备解决这个问题的奖励积分。

我在以下 bash 脚本中并行运行数以千计的curl后台进程

START=$(date +%s)
for i in {1..100000}
do       
    curl -s "http://some_url_here/"$i  > $i.txt&
    END=$(date +%s)
    DIFF=$(( $END - $START ))
    echo "It took $DIFF seconds"
done

我有 49Gb Corei7-920 专用服务器（非虚拟）。

我通过top命令跟踪内存消耗和 CPU ，它们离界限很远。

我ps aux | grep curl | wc -l用来计算当前curl进程的数量。这个数字迅速增加到 2-4 千，然后开始不断减少。

如果我通过管道 curl 添加简单的解析到 awk ( curl | awk > output) 比 curl 进程数量增加到 1-2 千，然后减少到 20-30 ...

为什么进程数量减少如此显着？这种架构的边界在哪里？

我没有对我的硬件或内核配置（所有默认设置、全新操作系统安装、Linux 内核 3.11 TCP/IP 堆栈）进行任何异常处理，我通过 TCP 平均每秒发送大约 383 万条消息，而我平均只有 0.75每秒通过 UDP 发送百万条消息。这似乎完全违背了我对这两个协议的期望。

造成巨大差异的最可能原因是什么，我如何在 Ubuntu 13.10 上对其进行诊断？

#TCP RESULTS
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

87380  65536     64    10.00      1963.43   32.96    17.09    5.500   2.852

#UDP RESULTS
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs …

我有两台服务器。其中之一有 1500 万个文本文件（约 40 GB）。我正在尝试将它们转移到另一台服务器。我考虑过压缩它们并传输存档，但我意识到这不是一个好主意。

所以我使用了以下命令：

scp -r usrname@ip-address:/var/www/html/txt /var/www/html/txt

但是我注意到这个命令只传输了大约 50,000 个文件，然后连接丢失。

有没有更好的解决方案可以让我传输整个文件集？我的意思是使用诸如rsync传输连接丢失时未传输的文件之类的方法。当另一个连接中断发生时，我会再次键入命令来传输文件，忽略那些已经成功传输的文件。

这是不可能的scp，因为它总是从第一个文件开始。

我正在运行 Ubuntu Linux 12.04.1，带有 VirtualMin 4.08.gpl GPL 和 2 个 CPU 内核。

在过去的几周里，它几乎一直以远高于 5 的平均负载运行，通常接近 10，有时达到 20。

现在，CPU 平均负载：9.20（1 分钟）8.20（5 分钟）7.81（15 分钟）

同时，VirtualMin 返回：

Virtual Memory: 996 MB total, 15.44 MB used
Real Memory: 3.80 GB total, 972.43 MB used 
Local disk space: 915.94 GB total, 116.03 GB used

已经重新启动 ( shutdown -rf now) 机器几次，并且肯定迟早我们会以高 CPU 负载备份。

Running top(或htop) 在高 CPU 下运行时根本没有返回任何显着的结果——事实上，观察它几分钟，最高的项目可能会占用 3% 的 CPU。

Top 也返回这个：

Cpu(s): 2.2%us, 1.2%sy, 0.0%ni, 0.0%id, 96.5%wa, 0.0%hi, 0.2%si, 0.0%st …

似乎find必须检查给定的路径是否与文件或目录相对应，以便递归地遍历目录的内容。

这是一些动机以及我在本地所做的事情，以说服自己find . -type f确实比find .. 我还没有深入研究 GNU 查找源代码。

所以我正在备份我$HOME/Workspace目录中的一些文件，并排除属于我的项目或版本控制文件的依赖项的文件。

所以我运行了以下快速执行的命令

% find Workspace/ | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' > ws-files-and-dirs.txt

find管道传输到grep可能是不好的形式，但它似乎是使用否定正则表达式过滤器的最直接方式。

以下命令仅包含 find 输出中的文件，并且花费的时间明显更长。

% find Workspace/ -type f | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' > ws-files-only.txt

我编写了一些代码来测试这两个命令的性能（使用dash和tcsh，只是为了排除 shell 可能产生的任何影响，即使不应该有任何影响）。的tcsh，因为他们基本上是相同的结果已被忽略。

我得到的结果显示了大约 10% 的性能损失 -type f

下面是程序的输出，显示了执行 1000 次各种命令迭代所花费的时间。

% perl tester.pl
/bin/sh -c find Workspace/ >/dev/null
82.986582

/bin/sh -c find Workspace/ | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' …

在搜索什么人能够监测perf_events在Linux上，我找不到什么Kernel PMU event是？也就是说，与perf version 3.13.11-ckt39该perf list节目的事件，如：

branch-instructions OR cpu/branch-instructions/    [Kernel PMU event]

总的来说有：

Tracepoint event
Software event
Hardware event
Hardware cache event
Raw hardware event descriptor
Hardware breakpoint
Kernel PMU event

我想了解它们是什么，它们来自哪里。我对所有人都有某种解释，但Kernel PMU event项目。

从perf wiki 教程和Brendan Gregg 的页面我得到：

• Tracepoints是最清楚的——这些是内核源代码上的宏，它们是监控的探针点，它们是在ftrace项目中引入的，现在每个人都在使用
• Software 是内核的低级计数器和一些内部数据结构（因此，它们与跟踪点不同）
• Hardware event是一些非常基本的 CPU 事件，可以在所有架构上找到，并且内核很容易访问

• Hardware cache event是昵称Raw hardware event descriptor——它的工作原理如下

  据我所知，Raw hardware …