- 主题:其实我觉得技术站务们...... (转载)
现在 cpu 资源有富余。。你这个就属于改了不少还不会提高太多的那种 。。
【 在 oldbug (心平气和) 的大作中提到: 】
: 对于系统的优化，首先需要搞清楚的是什么地方是性能的瓶颈。除了技术站务之外，
: 没有人能够接触到水木运行时刻的相关统计数据，我们也不可能模拟出一个和水木
: 一模一样的运行时刻环境，技术站务们不公开说明白各个功能的负荷大概多少，别人
: ...................
--
FROM 61.51.182.*
是 IO, 不过我记得以前说过很多次了，另外大部分系统最后瓶颈全都是卡死在 IO 上面，这点优化的 sense ，应该有的吧？
【 在 oldbug (心平气和) 的大作中提到: 】
: 所以要你们说到底性能瓶颈在哪里？IO？
--
FROM 61.51.182.*
慢。。。真的慢。。
【 在 dvlt (目标: 文章数<上站数) 的大作中提到: 】
: 不过现在水母的速度也不慢呀，可以花点精力完善功能：）
--
FROM 61.51.182.*
mmap 不是万能的，你不知道 mmap .DIR 的副作用，呵呵
随便说两个，最讨厌的就是进程在可写方式下面 mmap 时候，退出进程会 flush 所有 dirty page , 如果遇到熄灯一类的大面积退出，马上系统 load 高到像死，虽然这里可以通过把进程退出做排队来糊弄，但是效果会怎么样还不知道。
另一个就是每个进程都 mmap 很大一段不需要的地址空间，浪费了不少页表空间，也带来了不小的进程切换开销。。。
其实说起来这个 2001 年时候就尝试过 mmap .PASSWDS, 后来又改回 shm 了。。原因主要就是上面说的 1
【 在 dvlt (目标: 文章数<上站数) 的大作中提到: 】
: 还是先mmap .DIR吧，哼哼 -,-
--
FROM 61.51.182.*
2G 内存基本不够用，4G 也少。。
【 在 JulyClyde (七月) 的大作中提到: 】
: 内存那么大还IO什么啊？
--
FROM 61.51.182.*
这个策略不够好用。。原因自己考虑吧。。虽然没有公布具体的读写统计数据，不过我想冰雪聪明的 oldbug 一定可以分析出来 fb bbs 系统里面，哪里读命中的几率大吧 :p
【 在 oldbug (心平气和) 的大作中提到: 】
: IO的时候加入一个策略？如果长度大于多少的文章就直接实时写入磁盘，否则写入
: cache，等到IO空闲或者cache满的时候再写入磁盘？呵呵
--
FROM 61.51.182.*