我在 Debian 9 PC 和 Red Hat 4.8.5 高性能计算集群上间歇性地遇到了 %dopar%(带有 doMC 后端)和 fwrite() 的问题。行为并不总是一致的，但是，简而言之，fwrite 和 foreach 故障 - 即使特别要求 fwrite 只使用一个内核(通过 setDTthreads 或 fwrite 中的 nThread)，以避免并行工作线程的奇怪。在最近的案例中，一个实例中没有写入任何文件，而在另一个实例中，12 个文件中只有一到四个被写入。更重要的是，foreach 无法正确返回。fwrite 不是 foreach 循环中的最后一行;之后，它意味着返回一些东西，但它返回 NULL。同时，未检测到错误 - 群集上的退出状态为 0，并且不会打印警告。
如果使用顺序 %do%，它会按预期工作(并且可以将多个线程用于 fwrite)。我不确定我是否可以提供一个可重现的例子，因为结果不一致。对于最新的行为，我使用的是 R 3.3.3、data.table 1.10.4-3、doMC 1.3.5 和 foreach 1.4.4。我在使用 GitHub 最新版本的 data.table v1.10.5 时遇到了同样的问题。该问题似乎与文件大小有关;它倾向于在相对较小的文件中正常工作，但是一旦接近.3GB及以上，它就会搞砸。实际上，在写入较小的文件(相同 data.tables 的子集)时，相同的代码有效。
我不知道这真的是发布此内容的最佳位置 - 我只是在这里问这个问题，因为GitHub页面指定我在提交问题之前应该这样做。那么，有没有人遇到过这个问题，有没有人知道解决方法(即，如何在对大型数据集使用单线程 fwrite 的同时保留多核并行循环)？
这似乎是由于内存处理问题，这可能是qsub批处理作业提交所特有的。具体来说，如果在qsub调用中分配给pmem的金额不足，就会发生奇怪的事情。在一些新工作中，我发现，例如，有些行写错了(因此无法读取CSV)。同时，如果使用相同数量的内存，但通过mem(即pmem*ppn)指定它，fwrite和foreach%dopar%正常工作。