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万。

我需要将具有特定名称（move_script）的文件批次（在*.fext中）从此目录移动到另一个目录（当前是目录/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

脚本移动/开始处理文件，等待处理完成
批量处理1k-2k文件时，/mnt/storage/in_progress中文件的处理速度最快。
我试图让移动的文件数量增加。首先移动1k，然后如果源目录中的文件数量增加，则移动的文件数量增加一倍..这会减慢process_script中文件的处理速度，但有助于跟上＆＃ 34;文件生成器＆＃34; ..
我考虑在/mnt/storage/in_progress完成process_script之后简单地重命名子目录"/mnt/storage/done"+i_counter并创建新的/mnt/storage/in_progress。我认为这将是脚本中移动时间的一半。

我需要加快这个过程，以便跟上文件生成器的步伐。我怎样才能提高此移动操作的性能？

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

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

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

EDIT2：我写了一个脚本来测试各种移动方法之间的速度差异。首先创建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测试需要2分28秒，而后者使用相同的文件3分22秒，也是{{1大多数时候最快的方法..）：

os.rename()

Answer 1

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

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

Answer 2

通过登录CIFS服务器剥离洋葱，检查是否可以快速移动文件而不复制它们。

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

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

Answer 3

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

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

3 个答案: