提高移动已安装文件夹中不断增长的大量文件的性能

Question

这是我的情况：

A 有一个 Windows 网络共享，我使用 mount -t cifs -o username=username,password=password,rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 //192.168.1.120/storage /mnt/storage 挂载

此文件夹包含数量快速增长的各种大小的文件（从几个字节到 ~20MB）。如果不移动/删除，此目录中的文件数可能会超过 1000 万。

我需要将具有特定名称 (*.fext) 的批量文件（在 move_script 中）从该目录移动到另一个目录（当前是目录 /mnt/storage/in_progress 中的子文件夹）。

然后脚本启动另一个脚本 (process_script)，它将处理 /mnt/storage/in_progress 中的文件。在process_script 完成后，文件被move_script 再次移动到另一个子目录（/mnt/storage/done）。 move-process-move 一直持续到源文件夹 (/mnt/storage) 不再包含文件。

流程的附加信息：

• 目前的瓶颈是文件的移动（文件的移动速度比目录中创建的文件快一点）

  if len(os.listdir("/mnt/storage") >= batch_size:
      i = 0
      for f in os.listdir("/mnt/storage"):
          if f.endswith(".fext"):
              move("/mnt/storage/+"f","/mnt/storage/in_progress"
              i+=1
          if i==batch_size:
              break
  

• 脚本移动/开始处理文件，等待处理完成

• 处理 /mnt/storage/in_progress 中的文件最快，批量为 1k-2k 文件。

• 我试图让移动的文件数量增加。首先移动 1k，然后如果源目录中的文件数量增加，则移动的文件数量增加一倍。这会减慢 process_script 中文件的处理速度，但有助于跟上“文件生成器”的速度“..

• 我考虑在process_script完成后将子目录/mnt/storage/in_progress重命名为"/mnt/storage/done"+i_counter并创建一个新的/mnt/storage/in_progress。我认为这将使脚本中的移动时间减半。

我需要加快进程，以便跟上文件生成器的步伐。如何提高此移动操作的性能？

我愿意接受任何建议，并愿意彻底改变我目前的做法。

编辑：脚本在 debian wheezy 上运行，所以理论上我可以使用发出 mv 的子进程，但我不知道这有多合理。

============================================

编辑2： 我写了一个脚本来测试各种移动方法之间的速度差异。 首先创建 1x5GB (dd if=/dev/urandom of=/mnt/storage/source/test.file bs=100M count=50)，然后创建 100x5MB (for i in {1..100}; do dd if=/dev/urandom of=/mnt/storage/source/file$i bs=1M count=5)，最后创建 10000x5kB (for i in {1..100000}; do dd if=/dev/urandom of=/mnt/storage/source/file$i bs=1k count=5)

from shutil import move
from os import rename
from datetime import datetime
import subprocess
import os

print("Subprocess mv: for every file in directory..")
s = datetime.now()
for f in os.listdir("/mnt/storage/source/"):
    try:
        subprocess.call(["mv /mnt/storage/source/"+str(f)+" /mnt/storage/mv"],shell=True)
    except Exception as e:
        print(str(e))
e = datetime.now()
print("took {}".format(e-s)+"\n")

print("Subprocessmv : directory/*..")
s = datetime.now()
try:
    subprocess.call(["mv /mnt/storage/mv/* /mnt/storage/mvf"],shell=True)
except Exception as e:
    print(str(e))
e = datetime.now()
print("took {}".format(e-s)+"\n")


print("shutil.move: for every file file in directory..")
s = datetime.now()
for f in os.listdir("/mnt/storage/mvf/"):
    try:    
        move("/mnt/storage/mvf/"+str(f),"/mnt/storage/move")
    except Exception as e:
        print(str(e))
e = datetime.now()
print("took {}".format(e-s)+"\n")

print("os.rename: for every file in directory..")
s = datetime.now()
for f in os.listdir("/mnt/storage/move/"):
    try:
        rename("/mnt/storage/move/"+str(f),"/mnt/storage/rename/"+str(f))
    except Exception as e:
        print(str(e))
e = datetime.now()
print("took {}".format(e-s)+"\n")


if os.path.isdir("/mnt/storage/rename_new"):
    rmtree('/mnt/storage/rename_new')
print("os.rename & os.mkdir: rename source dir to destination & make new source dir..")
s = datetime.now()
rename("/mnt/storage/rename/","/mnt/storage/rename_new")
os.mkdir("/mnt/storage/rename/")
e = datetime.now()
print("took {}".format(e-s)+"\n")

这表明并没有太大的区别。5GB 文件的移动速度非常快，这告诉我通过更改文件表进行的移动是有效的。这是 10000*5kB 文件的结果（感觉结果取决于当前的网络工作量。例如第一次 mv 测试用了 2m 28s，之后用相同的文件 3m 22s，也是 os.rename() 最快的大多数时候都是这种方法..）：

Subprocess mv: for every file in directory..
took 0:02:47.665174

Subprocessmv : directory/*..
took 0:01:40.087872

shutil.move: for every file file in directory..
took 0:01:48.454184

os.rename: for every file in directory..
rename took 0:02:05.597933

os.rename & os.mkdir: rename source dir to destination & make new source dir..
took 0:00:00.005704

Answer 1

通过登录 CIFS 服务器并检查它是否可以在不复制文件的情况下快速移动文件来剥洋葱皮。

如果您发现它仍在复制，请检查 CIFS 服务器上的安装。可能在幕后，/mnt/storage/in_progress 和/或/mnt/storage/done 实际上是挂载在/mnt/storage 下的不同文件系统或硬盘驱动器，但通过一个 CIFS 共享共享出去。

编辑：Daedalus Mythos 的计时测试更新表明这种情况不太可能发生，因为 Daedalus 可以非常快速地移动一个 5 GB 的大文件，但无法快速移动数千个较小的文件。

Answer 2

这是要求文件生成器开发人员将*.fext 文件放在他们自己的子目录中的完美案例，例如/mnt/storage/fext_raw，因此您可以将整个目录重命名为/mnt/storage/in_progress，然后重新创建/mnt/storage/fext_raw .

Answer 3

您可以通过使用glob 模块列出文件来简化代码。但最有可能的限制因素是网络。这些文件很可能最终通过网络复制而不是简单地移动。否则这个过程会非常快。

尝试使用os.rename() 移动文件。它可能不适用于 cifs 文件系统，但值得一试。那应该做一个实际的重命名，而不是一个副本。如果它不起作用，您可能需要以其他方式挂载该文件系统。或者在文件系统所在的机器上运行移动进程。