我在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时保留多核并行循环）？
答案 0 :(得分：0)
这似乎是由于内存处理问题，可能是qsub批处理作业提交所特有的。具体来说，如果在pmem电话中分配给qsub的金额不足，则会发生奇怪的事情。在一些新的工作中，我发现，例如，某些行被错误地任意写入（因此无法读取CSV）。同时，如果使用相同数量的内存，但通过mem（即pmem * ppn），fwrite和foreach {{1正常工作。