Nodejs和计算繁重的操作，利用cpu最大限度地利用工作线程，同时仍能获得一些响应

如何解决Nodejs和计算繁重的操作，利用cpu最大限度地利用工作线程，同时仍能获得一些响应

我正在尝试以高效的方式解决nodejs中的以下情况。

我需要处理一个价值100Mb的json，并且处理每个条目的时间函数约为O(sweet_jesus(n))。实时而言，每次输入大约需要4-5秒。
我唯一可以完全独立处理每个条目（总共约900个条目）的一线希望，它们是无关的。

我的第一选择是和worker_threads一起去node-worker-threads-pool：

import fs from 'fs';
import path from 'path';
import _ from 'lodash';
import moment from 'moment';
import workerPool from 'node-worker-threads-pool';

function generateShortEvaluationsByWorkers(){
    const pool = new workerPool.StaticPool({
        size: 10,task: path.resolve('src/simulator/evaluationGenerator.js')
    });
    let simulationEvaluations = [];
    const promises = [];

    fs.readdirsync(path.resolve(`results/companies`)).forEach(file => {
        const rawData = fs.readFileSync(path.resolve(`results/companies/${file}`));
        const company = JSON.parse(rawData);

        console.log(new Date(),": company parsed,sending it for processing:",file);

        promises.push(pool.exec(company).then(result=>{
            simulationEvaluations.push(result);
        }));
    });

    Promise.all(promises).then(()=>{
        fs.writeFileSync(
            path.resolve(`results/bundles/simulationEvaluations.json`),JSON.stringify(simulationEvaluations,null,2)
        );
        pool.destroy();
    })
}

上面的代码运行得很漂亮，它表明I / O-读取所有文件并将其馈送到池中-大约需要5-6秒钟... 但是在那之后，与在单个线程中运行整个程序相比，绝对没有任何区别。日志确实显示对各个文件的处理不再像以前那样按顺序进行，因此我想后台会发生一些线程化，但是总时间不会改变一位。两种方法大约需要一个小时。另外，我的具有6个核（12个逻辑）的超线程Intel 8750也显示出86％的利用率用于节点进程。因此，我所谓的10个独立线程甚至无法利用一个完整内核。 -编辑：我是个智障者，确实确实给我带来了巨大的改变，我记错了时间...

在此之后，我将线程池的大小增加到100，并将文件数量减少到100。这就是奇怪的事情开始发生的地方。首先，我所有的cpu内核都变坏了，笔记本电脑如人们所愿地正确地融化了桌子。操作系统使响应速度为零，一切都是幻灯片。前20个左右的文件在同一秒内得到处理，之后各个文件的处理时间分别约为3秒（彼此紧紧相接，一条消息则相距3-5秒）。最后10个左右的文件将在同一秒内再次得到处理。

为什么10个线程与1个线程相比没有区别？
我不应该看到要在群集中处理的文件吗，群集的大小与逻辑核心的数量相当，而不是一个接一个的时间戳吗？
当计算仍与所有其他内核一起进入海王星时，有没有办法“离开”内核来处理其他事情？

编辑：我不会删除它，也许有人会从中学习:) 因此，请回答我自己的问题：

它确实可以，我无法测量，无法写入，也无法读取cpu仪表...完全是我的错
我仍然没有完全理解这一点，但是经过几次运行后，我怀疑当您启动一整堆线程时，只是由于当时全部启动它们的压力，才使整个系统挂起了很多东西它能够发出第一个日志，已经进行了大量计算。
是的，这也很明显，不要使用太多的线程，以至于线程管理本身会使操作系统抛出问题。

最后我得到了11条线程的最佳结果。