1
wenbinwu 2014-09-05 17:36:43 +08:00
你代码怎么写的啊?
|
2
yueyoum 2014-09-05 17:40:45 +08:00
不是 mysqldb 的问题, 你代码写错了
上代码 |
3
magine 2014-09-05 18:02:28 +08:00
围观代码QAQ
|
4
no13bus OP |
7
adieu 2014-09-05 19:01:48 +08:00 1
@no13bus 先试试两个最简单的优化:
1. 在settings.py里面设DEBUG=False,当DEBUG=True时,默认是每个request过程中产生的sql查询都会被缓存下来,结束时flush。在Command里面的代码因为不在request里面,所以不会flush。那么会产生大量缓存的sql指令。 2. result_list = results.objects.exclude(value='') 改为 result_list = results.objects.exclude(value='').iterator()。因为默认Django会缓存query result。 如果这两个优化做了之后还会OOM,那就需要比较详细的调试了。用调试工具检测for循环没有被gc的变量有哪些。甚至放弃一次取回所有结果,用分段查询的办法。不过如果数据量不算太大的话,可能不会需要走那么远。 |
8
hustlzp 2014-09-05 20:37:22 +08:00 via iPhone 1
遇到过这种问题,最后用程序分段处理解决的。
|
9
no13bus OP |
10
wenbinwu 2014-09-05 21:02:05 +08:00 via iPhone
像ls说的,可以一次取几千个,处理完了再取。
另外,那个re_minitor_info是什么?会不会造成另一个查询? |
11
wenbinwu 2014-09-05 21:03:00 +08:00 via iPhone 1
突然想起来,如果是django命令内存过高的话是正常的
|
12
no13bus OP @wenbinwu 恩。这个就是做成的django的命令。写在了management里面了。为什么命令导致内存高是正常的?
|
16
est 2014-09-05 22:18:46 +08:00
硬tab,for里面嵌套3层if。。。。
|
17
adieu 2014-09-05 22:48:00 +08:00
@no13bus 在考虑什么时候用.iterator()时需要考虑Django平常的使用场景。大部分的时候是在view里面把queryset传入到模板里面进行render。同一个queryset可能会多次遍历,如果每遍历一次就hit一次db,就一来浪费资源二来拖慢render时间。所以queryset本身是缓存的。
不过有的时候在Command里面或者async task里面,需要对数据进行处理。那在明确知道这个queryset只会遍历一次的时候就可以用.iterator()取消掉cache。节约内存占用。 平常如果数据量小,由于有gc,所以用起来区别不大。在数据量大的时候就是一个可以调优的点。 |