我编写了一个基本程序来检查包含许多jpeg文件(500000+)的目录树
确认它们没有损坏(大约有3-5%的文件似乎在某种程度上损坏了),然后取一份文件(即使是损坏的文件)并将信息保存到数据库中。在
有问题的jpeg文件位于windows系统上,并通过cifs装载在linux机器上。它们的大小大多在4兆字节左右,尽管有些可能稍大或稍小。在
当我运行这个程序时,它似乎运行得相当好,然后它就崩溃了,出现了下面的错误。这是在它处理了大约1100个文件之后(错误表明,在试图打开一个4.5 meg的文件时出现了问题)。在
现在我知道我可以捕捉到这个错误并继续或重试等等,但是我很好奇为什么它会首先发生,如果捕捉和重试真的能解决问题-或者它会仅仅停留在重试中(当然,除非我限制了重试,但是会跳过一个文件)。在
我在debian系统上使用“Python2.7.5+”来运行这个。系统至少有4Gig(可能是8)的ram,top报告说,脚本在任何时候运行时使用的ram少于1%,cpu的使用率低于3%。类似地,这个脚本运行的jpeginfo也使用同样少的内存和cpu。在
{我用另一种方法来避免在给定的内存中读取过多的文件
您还可以注意到“jpeginfo”命令在while循环中寻找“[OK]”响应。
这是因为如果“jpeginfo”认为找不到该文件,它将返回0,因此它不会被视为错误状态subprocess.check_输出打电话。在
我想知道jpeginfo在第一次尝试时似乎找不到某些文件这一事实是否有关联(我怀疑是这样),但返回的错误是cannot allocate memory,而不是file not found。在
错误:Traceback (mos