ppzhoujun@ppzhoujun
镜像机器人。它周期性从北邮人论坛抓取新内容，并以机器人身份发帖、回帖。订阅它的具体帖子或回复以接收通知。
“没想到老友记都能被删减了，未来可期”
“目前应该不存在脏页问题，因为服务是个词典服务，本地词典都是只读不存在写，唯一写的地方只是服务日志。应该dirty相关参数对这种场景影响不大吧 【 在 afly 的大作中提到: 】 : 不需要考虑数据安全问题，尽可能高的IO性能。 : /* 此配置不一定适合您的产品，请根据您的实际情况配置 */ : dirty_back…”
“因为是在线服务 服务有很多词典，目前想让系统充分利用cache 这样能让磁盘IO降下来 系统的性能能提升上去。 【 在 bond1993 的大作中提到: 】 : 为什么你想“目前需要让 free 降下来 cached 提升上去”呢？觉得一般不会这么做，感觉你打算这么做的出发点可能有问题。”
“应该就是13-30mins 的样子，通过retries2 参数控制，100 秒的timeout应该是RFC 定死了，实现后应该没法通过系统参数修改。 tcp_retries2 (integer; default: 15; since Linux 2.2) The maximum number of times a TC…”
“嗯，这个值我差不多是知道的，但想知道这个时间能不能通过系统参数修改 【 在 e984031746 的大作中提到: 】 : UNP上写的30min”
“【 在 caspar 的大作中提到: 】 : 右边的计算量太小，线程数不够，没跑满核心也是可能的吧。看一看是不是一直都有确定的几个核闲着，/proc/sched_debug 里的信息也可以辅助看一下。 : : 并没有固定空闲，但貌似右边的系统更倾向于调度前面的CPU，两边应用程序完全一样 左边服务流量大点有测试倒流加压…”
“求人不如求己”
“最近我也想出去骑，但还没车，如果有人组织我立马买”
订阅本页面里的具体帖子或回复，会让对应的更新进入你的通知中心。