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.*

是说要用pipeline吗？已经用上了。

【 在 oldwatch 的大作中提到: 】
: https://redis.io/topics/pipelining
:
--
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.*