CompCache, Now in Mainline Kernel

版权声明: 允许非商业性转载，但转载时必须标明原作者 fcicq、原始链接 http://www.fcicq.net/wp/?p=783 及本声明。

迟到的一篇. 有些时日不太关心 Kernel 的变化了.
Git 很方便, 想要什么就 merge 什么.
Phoromatic Kernel Performance Tracker 很不错.

不过也懒了, Ubuntu Lucid 的优化做的挺彻底. 以前编译一个内核就能提高好多的速度, 现在榨不出来了. 不过 bug 也确实多.

开始说这个 compcache. 2.6.33 入 mainline (实际还早一点).
偶不喜欢开 swap, compcache 是个例外, 因为它和磁盘没有关系(后面的版本可能会有关).

有些人喊垃圾收集, swap 就是从内存中来的嘛, 需要的时候从 swap 出去, 当然也可以扔掉.
如果不考虑 compcache 和 swap 的关系, 仅仅把它看作一个 block device, 那么随便写吧, 这么一块大好的内存空间, 实际空间小于所需空间(特殊数据可能会例外).
compcache 有能力解决一些和内存分配利用不当有关的疑难杂症.

compcache swap 的大小个人不推荐超过物理内存的 1/2 (512 M 以下内存用户除外).

有些人知道 memcached 可以用上 lzo 或者 quicklz 什么的, 在客户端配置一下就行了.
甚至单纯的英文字符串也可以压缩 (SMAZ – compression for very small strings, http://github.com/antirez/smaz) – 知道有这么回事就行, 这叫”先学习再替换”.

可是当问 内存, CPU, 存储 哪一个是瓶颈的时候, 除了全换更大更好更快更强的, 就没有其它答案了?
缺 CPU? 实际是不缺的, 明明那么多机器负载不高, 装个 Gearman. 实际上是负载控制能力差. 上下文切换高很难说是坏事还是好事. 腾出一两个 CPU 核或者 irqbalance 试试看.
缺存储? 硬盘那么便宜. 有了那么大的内存, 花了那么多钱搞了 SSD, QPS (query per second) 后面还是没能加个 0.
缺内存? 这块数据放内存里最终也没用几次, 而且还有过度(在内存中)冗余的倾向. 而且那些 worker 占着那么多内存, 不心疼哪?

当然这对正规军好像不算什么大问题.
山寨嘛, 才会出这些问题. 抄完整一点, 把理论也抄来. 好有只抄技术不抄制度的感觉啊 (这语气好好奇怪)…

也许是因为缺银子缺人吧… 确实有不少人意识到啦, 这个混水里的鱼不好摸.

跑题了.

ps:
先知道你的内存长脚跑哪里去了再干活.

ps2:
偶不是内存, 跑…

友情提示: 请注意文章的时效性与准确性, 作者不对文章的有效性负责.