我有一个Python脚本导入一个大的CSV文件,然后计算文件中每个单词的出现次数,然后将计数导出到另一个CSV文件.
但正在发生的事情是,一旦计数部分完成并且出口开始,它就会Killed在终点中说明.
我不认为这是一个内存问题(如果我认为我会得到内存错误而不是Killed).
难道这个过程花了太长时间？如果是这样,有没有办法延长超时时间,所以我可以避免这种情况？
这是代码:
csv.field_size_limit(sys.maxsize)
counter={}
with open("/home/alex/Documents/version2/cooccur_list.csv",'rb') as file_name:
reader=csv.reader(file_name)
for row in reader:
if len(row)>1:
pair=row[0]+' '+row[1]
if pair in counter:
counter[pair]+=1
else:
counter[pair]=1
print 'finished counting'
writer = csv.writer(open('/home/alex/Documents/version2/dict.csv', 'wb'))
for key, value in counter.items():
writer.writerow([key, value])
而且Killed发生后finished counting已打印,以及完整的信息是:
killed (program exited with code: 137)
Blc*_*ght 82
退出代码137(128 + 9)表示您的程序因接收信号9退出,即SIGKILL.这也解释了这个killed消息.问题是,你为什么收到这个信号？
最可能的原因可能是您的进程超出了允许使用的系统资源量的限制.根据您的操作系统和配置,这可能意味着您有太多打开的文件,使用了太多的文件系统空间或其他东西.最可能的是你的程序使用了太多内存.当内存分配开始失败时,系统不会冒破坏的风险,而是向使用过多内存的进程发送了一个kill信号.
正如我之前评论的那样,打印后可能达到内存限制的一个原因finished counting是您counter.items()在最终循环中的调用会分配一个包含字典中所有键和值的列表.如果你的词典有很多数据,这可能是一个非常大的列表.可能的解决方案是使用counter.iteritems()哪个是发电机.它不是返回列表中的所有项目,而是让您以更少的内存使用量迭代它们.
所以,我建议尝试这个,作为你的最后一个循环:
for key, value in counter.iteritems():
writer.writerow([key, value])
请注意,在Python 3中,items返回一个"字典视图"对象,它与Python 2的版本没有相同的开销.它取代了iteritems,所以如果你以后升级Python版本,你最终会将循环改回原来的状态.
ROY*_*ROY 21
涉及两个存储区域:堆栈和堆.堆栈是保存方法调用的当前状态的位置(即局部变量和引用),堆是存储对象的位置.递归和记忆
我猜想counterdict中有太多的键会占用堆区域的太多内存,因此Python运行时会引发OutOfMemory异常.
要保存它,不要创建一个巨大的对象,例如计数器.
1.StackOverflow
一个创建太多局部变量的程序.
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('stack_overflow.py','w')
>>> f.write('def foo():\n')
>>> for x in xrange(10000000):
... f.write('\tx%d = %d\n' % (x, x))
...
>>> f.write('foo()')
>>> f.close()
>>> execfile('stack_overflow.py')
Killed
2.OutOfMemory
创建巨人的程序dict包含太多密钥.
>>> f = open('out_of_memory.py','w')
>>> f.write('def foo():\n')
>>> f.write('\tcounter = {}\n')
>>> for x in xrange(10000000):
... f.write('counter[%d] = %d\n' % (x, x))
...
>>> f.write('foo()\n')
>>> f.close()
>>> execfile('out_of_memory.py')
Killed
我怀疑有什么东西会仅仅因为需要很长时间就杀死这个过程。Killed 通常意味着来自外部的某些东西终止了进程，但在本例中可能不是按 Ctrl-C，因为这会导致 Python 在键盘中断异常时退出。另外，在 Python 中，如果这是问题所在，你会得到 MemoryError 异常。可能发生的情况是您遇到了 Python 或标准库代码中的错误，导致进程崩溃。
最有可能的是，您的内存不足，因此内核终止了您的进程。
你听说过OOM 杀手吗？
这是我为处理来自 CSV 文件的大量数据而开发的脚本中的日志：
Mar 12 18:20:38 server.com kernel: [63802.396693] Out of memory: Kill process 12216 (python3) score 915 or sacrifice child
Mar 12 18:20:38 server.com kernel: [63802.402542] Killed process 12216 (python3) total-vm:9695784kB, anon-rss:7623168kB, file-rss:4kB, shmem-rss:0kB
Mar 12 18:20:38 server.com kernel: [63803.002121] oom_reaper: reaped process 12216 (python3), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
它是从/var/log/syslog.
基本上：
PID 12216 被选为受害者（因为它使用了 +9Gb 的总虚拟机），所以oom_killer收获了它。
这是一篇关于OOM 行为的文章。
VirtualBox当我尝试从新的 Ubuntu 20.04 LTS 中的共享文件夹运行 python 脚本时，我也遇到了同样的情况。KilledPython在加载我自己的个人库时退出。当我将文件夹移动到本地目录时，问题就消失了。看来Killed停止是在我的库的初始导入期间发生的，因为一旦我将文件夹移过来，我就收到了缺少库的消息。
我重新启动计算机后问题就消失了。
因此，如果程序位于某种共享上，或者可能是一个暂时性问题，只需要重新启动操作系统，人们可能会尝试将程序移动到本地目录。