2.6.18 PageCache分配速度太慢?? 求助

lovegq

机器的配置如下:
=======================================
4个CPU节点, 24个计算单元，超线程为48个cpu， 1.8GHZ
内存256G
一个巨牛逼的SSD卡,顺序读2G，顺序写1G，随机读1-2G，随机写1G(你没看错)
内核版本 rhel5u2 (2.6.18-92)
=======================================
现有问题如下：
用directIO时:
dd if=/dev/zero of=test.date oflag=direct bs=1M count=10240    # 写10G文件 directIO
顺序写速度可达1G， cpu无压力

走pagecache时
dd if=/dev/zero of=test.date bs=1M count=10240                      # 写10G文件 pagecache
速度500M， cpu 100%,几乎全在sys态

仔细观察了下，此时瓶颈在 pagecache分配内存时,
用 watch -n1 " awk 'BEGIN{X}/free/{X+= \$3}END{print X}'  /proc/zoneinfo " 观察内存
发现每秒也就分配个500M左右

结合 1) cpu 100% ;2) 几乎全在sys态; 3) zoneinfo free中下降的速度，推测出pagecache(写时)分配速度比较慢
只有SSD卡顺序写速度的一半

同样的测试又应用到顺序读上， pagecache分配速度变为1G, 但依然只有SSD卡顺序读速度的一半

然后怀疑是单线程pagecache分配比较慢
于是开了3个dd , 用 numactl  分别定到三个不同的cpu上，
速度反而更慢了，难道有全局锁?

以前没用过这么快的SSD存储设备，从来没感受到过内存是瓶颈，因此很奇怪
不晓得是内核版本问题，还是配置问题，不知道各位有没有遇到?
另外，同样的测试在同样机器配置的 6u3下也做了， 结果也类似。

lovegq

自己顶一下，别沉了

humjb_1983

除了软件原因外，估计还跟你的内存硬件的读写速度有关，建议用lmbench之类的工具测试下内存读写速度。
另外，可能也跟numa相关，低版本内核对numa支持可能也不够好，可能存在远程节点访问效率的问题。
如果怀疑软件问题，可以将内核升级再试试。
另外，多线程效率更低是说3个进程的总的速度还不抵单进程的情况么？感觉可能跟超线程相关，对于内存访问密集型的应用，超线程(由于共享cache)的性能也不好。

瀚海书香

回复 1# lovegq
这个内核版本有点低了啊。建议改成高版本内核试试吧，用这么低的内核出了问题也很少有人愿意翻老代码帮你定位的

   

lovegq

回复 3# humjb_1983
内存 是 1033MHZ的，速度不会慢，我用
dd if=/dev/zero of=/dev/null bs=10240 count=1 试过，都是零点零几秒

升级版本什么的，不是不可以，就是代价有点儿大，
而且但是总要给领导个理由，就怕万一升级完后，问题照旧，那就没法子交代了


   

lovegq

回复 3# humjb_1983


    另外 我都是用 numactl  cpu和内存都是定到某个节点上的，而且仔细观察了 /proc/buddyinfo， 可以确保没有从远程分配

lovegq

刚刚用 oprofile 采样了一下内核
发现
80%以上在 text.acpi_processo_idle 上
这个是做什么的？

humjb_1983

这是acpi模式下的cpu_idle()接口，即CPU空闲时就会进入此函数。
这样就不对了，该函数应该表示CPU空闲才对，不应该cpu占用100%哦
cat /proc/cmdline看看结果呢？
另外，看看试试吧apci关掉试试？

humjb_1983

lovegq 发表于 2014-03-07 14:31
刚刚用 oprofile 采样了一下内核
发现
80%以上在 text.acpi_processo_idle 上

另外，请在测试时，将测试进程的内核态堆栈打一下。看看具体在干嘛

lovegq

大哥，我不是内核开发人员，不会打内核堆栈，用什么sysQ魔术键?
怎么关acpi? bios? 开机选项？