我有自己的多线程C程序,可以根据CPU内核的数量平滑地扩展速度.我可以用1,2,3等线程运行它并获得线性加速..在6核上最高可达5.5x速度Ubuntu Linux机器上的CPU.

我有机会在一个非常高端的Sunfire x4450上运行该程序,其中包含4个四核Xeon处理器,运行Red Hat Enterprise Linux.我急切期待看到16个内核以16个线程运行我的程序的速度有多快..但它的运行速度与两个线程相同!

稍后进行了大量的拔毛和调试,我发现我的程序确实在创建所有线程,它们实际上是同时运行的,但是线程本身比它们应该更慢.2个线程的运行速度比1快1.7倍,但是3个,4个,8个,10个,16个线程的运行速度仅为1.9倍!我可以看到所有线程都在运行(没有停滞或睡眠),它们只是很慢.

为了检查硬件是否有问题,我同时独立地运行了我的程序的第六个副本.他们全速奔跑.真的有16个内核,它们确实全速运行,并且确实有足够的RAM(实际上这台机器有64GB,而且每个进程只使用1GB).

所以,我的问题是,是否有一些操作系统解释,也许是一些每进程资源限制,它自动缩减线程调度,以防止一个进程占用机器.

线索是:

1. 我的程序无法访问磁盘或网络.它的CPU有限.它的速度在Ubuntu Linux中的单个CPU盒上线性扩展,带有一个用于1-6线程的hexacore i7.6个线程实际上是6倍加速.
2. 我的程序在这个16核心Sunfire Xeon盒子上的运行速度永远不会超过2倍,对于2-16的任意数量的线程.
3. 运行16个程序单线程的副本运行完美,全部16个全速运行.
4. top显示1600%的CPU分配./ proc/cpuinfo显示所有16个内核以2.9GHz的速度运行(不是1.6GHz的低频空闲速度)
5. 有48GB的RAM免费,它没有交换.

发生了什么？是否有一些进程CPU限制策略？如果是这样我怎么测量呢？还有什么可以解释这种行为？

感谢您的解决方案,2010年的伟大至强减速之谜!

作为normaluser：

$ ulimit -n 4096
-bash: ulimit: open files: cannot modify limit: Operation not permitted

作为 root，它可以按需要工作 - 但它不会影响normaluser.

如何摆脱第22条军规？我需要这个坚持下去。

Tomcat在我的工作站上运行了好几天,现在它没有响应,lsof命令输出大量的close_wait状态连接,tomcat pid是25422,但是ulimit命令显示"打开文件"是1024,这怎么会发生？

[root@localhost home]# lsof -p 25422 | wc -l
10309

[root@localhost home]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 399360
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, …

我试过几种方法来改变URL的开放文件限制

http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/

我已经更改了limit.conf和/etc/sysctl.conf

它与其他用户一起工作,但root的限制打开文件没有改变

在/etc/security/limits.conf

#####
*       -        nproc           8500
*       hard     nofile          200000
*       soft     nofile          200000
*       hard     stack           8192
*       hard    sigpending       45056

root    hard     nofile          200000
root    soft     nofile          200000
root    hard     no file         200000

/etc/sysctl.conf中

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
fs.file-max = 200000

重启服务器,之后

[root@ironman ~]# ulimit -n
8192

最后我在/ etc/bashrc上面添加命令,它对root用户也有效,我真的不明白为什么只在sysctl.conf /limits.conf上设置不会影响？

请指教

用于在容器上设置ulimit的方法不适用于服务.

对于容器,它就像ulimit在docker run命令上传递参数一样简单.

对于服务,是否可以在命令行上？Ulimit不被视为旗帜.

见这里对集装箱相关的问题(注:也不能适用于服务).

我有一个 node.js 进程，它需要从不同的其他进程提供的多个命名管道中读取作为 IPC 方法。

在打开并创建来自四个以上 fifos 的读取流后，我意识到 fs 似乎不再能够打开 fifos 并且只是挂在那里。

考虑到可以同时打开数千个文件而不会出现问题（例如在以下脚本中替换mkfifo为touch），这个数字似乎有点低。

我在 MacOS 10.13 上使用 node.js v10.1.0 和在 Ubuntu 16.04 上使用 node.js v8.9.3 进行了测试，结果相同。

错误的脚本

以及显示此行为的脚本：

var fs = require("fs");
var net = require("net");
var child_process = require('child_process');

var uuid = function() {
    for (var i = 0, str = ""; i < 32; i++) {
        var number = Math.floor(Math.random() * 16);
        str += number.toString(16);
    }
    return str;
}

function setupNamedPipe(cb) {
    var id …

我想malloc()通过限制可用内存来失败。

$ ulimit -v 1000
$ ./main.exe 10000000
0x102bfb000

但即使使用 ulimit，以下程序仍能正确完成。有人知道如何malloc()失败吗？谢谢。

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    size_t size = atoi(argv[1]);
    void *ptr = NULL;

    if((ptr = malloc(size)) == NULL) {
        perror("malloc()");
        exit(1);
    }

    printf("%p\n", ptr);
    free(ptr);
    return 0;
}

编辑：以上是在 Mac OS X 上。

在 Linux 上，我遇到了分段错误。为什么malloc()会导致segmentation fault？如何使malloc()返回空指针？

我的程序可以根据使用情况突然分配大量RAM。我想限制它可以从系统获取的RAM。

我在这里看到： 将RAM使用限制为python程序

但是它仅适用于Unix。Windows的任何解决方案？

在 54 核机器上，我用来os.Exec()生成数百个客户端进程，并使用大量的 goroutine 来管理它们。

有时，但并非总是，我会得到这样的信息：

runtime: failed to create new OS thread (have 1306 already; errno=11)\nruntime: may need to increase max user processes (ulimit -u)\nfatal error: newosproc\n

我的 ulimit 已经相当高了：

$ ulimit -u\n1828079\n

如果我将自己限制在 54 个客户之内，那绝对不会有问题。

有没有办法可以更优雅地处理这种情况？例如\xc2\xa0不会因为致命错误而崩溃，而只是做更少/延迟的工作？或者提前查询系统并预测我可以做的最大数量的事情（尽管我不想限制核心数量）？

鉴于我的 ulimit 很大，这个错误是否应该发生？grep -c goroutine致命错误后的堆栈输出仅给出 6087。每个客户端进程（其中肯定少于 2000 个）可能有一些自己的 goroutine，但没什么疯狂的。

编辑：该问题仅发生在高核机器（~60）上。保持其他一切不变，只需将内核数量更改为 30（这是 OpenStack 环境，因此仍在使用相同的底层硬件），就不会发生这些运行时错误。

我正在尝试在 ECS 上运行的 Nginx 上运行一些负载测试，并且我已ulimit通过文档中提到的任务定义将 设置为更高的值 (777001) 。

在容器内，容器内的ulimit -Hn命令和cat /proc/sys/fs/file-max运行将给出与输出相同的值 ()。

在运行容器（自动扩展集群中的 EC2 之一）的 EC2 上，ulimit -Hn指定为 1024，cat /proc/sys/fs/file-max指定为 777001。

当我运行负载时，too many open files当每秒请求数达到 500 左右时出现错误。（ECS 服务的 CPU 使用率和内存使用率似乎在 25% 左右）。

在对此进行一些挖掘时，我发现了这篇中等文章，其中引用了/etc/sysconfig/docker提供给 docker 守护程序的文件和启动选项。在我的情况下，cat /etc/sysconfig/docker输出如下。

# The max number of open files for the daemon itself, and all
# running containers.  The default value of 1048576 mirrors the value …