OS X 10.7.1 上的 httperf 分段错误错误答案

【问题标题】：httperf segmentation fault error on OS X 10.7.1OS X 10.7.1 上的 httperf 分段错误错误
【发布时间】：2011-11-13 03:24:46
【问题描述】：

当我尝试使用高请求率的 httperf 执行负载测试时，我收到以下错误：

» httperf --client=0/1 --server=www.xxxxx.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=200 --rate=30
httperf --client=0/1 --server=staging.truecar.com --port=80 --uri=/ --rate=30 --send-buffer=4096 --recv-buffer=16384 --num-conns=200 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
**Segmentation fault: 11**

当“速率”> 15 时引发错误

版本：

httperf 0.9.0

OS X 10.7.1

【问题讨论】：

我在 OSX 10.6.8 上看到了同样的情况，httperf 0.8.1 和 0.9.0
我看到了这一点，即使将速率设置为 > 1。在段错误为 2 之前它似乎运行时间更长，但 3 段错误很快。
检查是否内存不足。
您的系统文件描述符不足。 IIRC，这发生在使用太小的方式的 RPM 包__FD_SETSIZE（如 1024）。 Afaik 你需要重新编译限制性 RPM 包（例如 glibc、Apache、PHP 等）以增加 __FD_SETSIZE，所以我建议将问题迁移到 Server Fault。
我在运行 Apache 2.2.15 的 CentOS 6 x64 上遇到了同样的问题，但在运行 Nginx 1.2.3 的 Debian 6 x64 上却没有，两者都使用 httperf-0.9.0。两者的打开文件限制相同 (1024)。

标签： testing load httperf

【解决方案1】：

尝试使用gdb 并使用类似的东西：

$ gdb httperf --client=0/1 --server=staging.truecar.com \
--port=80 --uri=/ --rate=30 --send-buffer=4096 \
--recv-buffer=16384 --num-conns=200 --num-calls=1

这将调用gdb，您应该会看到(gdb) 提示。

然后：run 并输入。

如果它会崩溃，请输入bt（回溯）。在此处调查和/或分享。

【讨论】：

我和原来的问题有同样的问题。这是您建议的 gdb 运行的输出：gist.github.com/2990517
恕我直言，这可能是您的系统文件描述符不足的另一种情况。另一件事可能是 httperf 中糟糕的内存管理。您可以尝试改用sysbench。
可能这是httperf内部的问题。 Sysbench 对我没用，因为我想测试一个网络服务器。
最终我最终使用了部分围攻和大部分 tsung。

【解决方案2】：

如警告所述，与 http 服务器的连接数超过了允许的打开文件描述符的最大数量。即使httperf 将值限制为 FD_SETSIZE，您也可能超出了该限制。

您可以使用ulimit -a检查限制值

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 709
virtual memory          (kbytes, -v) unlimited

尝试使用ulimit -n <n> 增加限制

$ ulimit -n 2048
$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 2048
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 709
virtual memory          (kbytes, -v) unlimited

这是大型网络服务器等的常见做法，因为套接字本质上只是一个打开的文件描述符。

【讨论】：

正如@Tom van der Woerdt/@m_pahlevanzadeh 指出的，如果您使用的是 csh 而不是 bash/ksh，请将 umlimit 替换为 limit
感谢您的提示。但这并不能解决分段错误，而且很可能不是问题的根本原因。阅读 httperf 文档，它实际上知道可用的文件描述符。它将记录不可用的文件描述符并在一次运行后输出它们。如果文件描述符用完，程序不会崩溃。
Basho 有一个 convenient guide 用于提高 Lion 的打开文件限制。基本上，将limit maxfiles 16384 32768 添加到一个名为/etc/launchd.conf 的文件中（如果缺少则创建它）。重启。使用ulimit -a 或launchctl limit 检查新值。不过，我仍然遇到段错误。
不起作用。我已经有以下集合：open files (-n) 640000

【解决方案3】：

ksh 和 bash 使用 ulimit，csh 使用 limit 命令。

【讨论】：

还可以使用 lsof 命令查看打开的文件，并将此命令用于以下发行版：AIX 5.3、FreeBSD 4.9 用于基于 x86 的系统、FreeBSD 7.0 和 8.0 用于基于 AMD64 的系统、Linux 2.1。对于基于 x86 的系统以及 Solaris 9 和 10，为 72 及更高版本。@yesterday