我正在cat分别结合file_X了众多的若干文件，例如file_1到file_100000000000。
由于数量众多，我将作业分配到具有64个CPU的节点上，以在每个CPU上并行运行。每个作业都在一个子文件夹中运行，因此有64个子文件夹。
令我惊讶的是，总体速度比预期的要慢得多。
由于我使用的Shell脚本仅将每个作业定向到file_X位于64个子文件夹的父目录中的同一单个文件，因此我想知道是否有许多CPU同时读取同一文件，这会减慢每个CPU的读取速度吗？
是的，没有。
不管有多少处理器执行该文件，实际读取文件的速度均应相同。
但是，取决于操作系统及其配置，可能会发生文件锁定。尽管多个进程可以同时具有读锁，但获取锁和释放该锁必须在共享的互斥块中进行。如果您的系统正在执行此类锁定，则处理器必须排队以访问文件，然后必须排队以声明对文件没有进一步的兴趣。
根据存储file_X的文件系统以及与之结合的各种文件以及该文件系统的安装选项，每次cat读取file_X时，其访问时间可能都会更新。如果是这样，很可能在每次更新之前都会对file_X inode进行写锁定，然后将其释放。
降低速度的另一个可能原因是，所有这些作业中的所有64个都是并行写入文件，这些文件必须位于磁盘上的不同点上。除非使用固态驱动器（SSD），否则可能需要大量移动磁盘上的写磁头。这些文件位于64个不同的目录中，因此除了要创建的文件之外，还有64个要更新的位置。
在shell脚本中执行所有这些活动意味着每个文件副本都将被fork执行。Fork被视为相当昂贵的系统调用，但是在具有共享库的系统上，与exec系列系统调用的成本相比，它显得苍白，因为这需要搜索每个共享库，并加载所有共享库。库。这是另一个可能在文件上放置读取锁的地方，具体取决于它所在的UNIX以及其配置是什么。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句