- 主题:问个python操作redis的优化问题
1万个小文件,每个大概1M,文件内就是key,value对。
现在要将这些文件全load到redis中,就是字符串形式存着。
电脑是6核12线程电脑,64G内存,文件放到了RAMDISK上。
我的方法就是读文件到数组,然后用redis的python包先mset再execute。开了64个进程,multiprocess来跑。
观察到加载初段CPU占满,但跑到后面越来越慢,CPU占用率在10+,我猜测只有一个核(1/6)在跑,整体几乎处于空载。另外内存也不存在快满的情况。
想问下瓶颈大概会在哪,应该怎么优化。谢谢。
--
修改:ackerx FROM 222.68.18.*
FROM 222.68.18.*
我感觉不至于吧,这点量算大吗,我感觉是python多进程会不会有什么锁导致的。但是PIL是线程级的,已用上多进程了。又或者有什么硬件资源隐含地变成锁了,但不知道怎么分析。
另外我用的是py2.7
【 在 GoGoRoger 的大作中提到: 】
: 可以先压缩一下吧?
--
FROM 222.68.18.*
没呢,我64G内存,有一半多还空着呢
【 在 GoGoRoger 的大作中提到: 】
: 我猜是内存用完了,redis dump到硬盘,瓶颈是io?
--
FROM 222.68.18.*
我64进程都是读文件,往redis里写。都用上了pipeline。
即便redis自身单线,我以为不重要,因为最终就是在redis处理上做排队,将IO时间通过并行化隐藏起来,可是实际结果是初段往redis里写的效率非常高,后段却非常慢。
我是想弄清这种效率差异的原因是什么,怎么优化。
在写这帖时,我渐渐有个想法可能是python redis包连接的开销太大了。也许python redis自己池化的连接,后面池子满了,要不断释放申请?
【 在 oldwatch 的大作中提到: 】
: 那你64个线程跑的都是啥?
: redis在6.0之前都是单线程模型
:
--
FROM 222.68.18.*