关于大量静态页的想法
上次在MeetBSD的时候Tim提到了一种处理大量静态页的办法。今天看Squid开发人员在NYC的BSD活动上的一个演讲里面也介绍了各种方法处理I/O的区别。
共 34 篇文章。
上次在MeetBSD的时候Tim提到了一种处理大量静态页的办法。今天看Squid开发人员在NYC的BSD活动上的一个演讲里面也介绍了各种方法处理I/O的区别。
今天MeetBSD由Pawel Jakub Dawidek开讲,等,为啥出来的是xterm……?然后OpenOffice Impress从命令行启动了。
ZFS是大家最关心的一个话题。Pawel最近这段时间对ZFS做了相当多的完善工作(主要是写测试用例和改用例发现的bug)。新版本的ZFS v13除了大大改善了可靠性问题之外,还增加了很多有意思的功能。不过这样一来,这patchset的尺寸?(后话:后一天的committer闭门会议,在大家的一致怂恿下ZFSv13终于给commit到了-HEAD)提问非常踊跃,我们最大的白老鼠之一,运营Internet(作为ISC公司的雇员)的Peter Losher就他遇到的一些问题进行了询问,并且得到了满意的答复。
Murray老大在这之后对这次Google SoC进行了总结。FreeBSD这几次SoC的项目成功率都很高,唯一的遗憾是在SoC之后,很多没有最终进入-HEAD。在肯定SoC的成功的同时,如何更好地利用?很多SoC的代码品质并不是很高,如何求得完成目标与高品质代码之间的合理平衡?这些都是我们需要思考的问题。
今天起了一个大早,9:00到了位于 1600 Amphitheatre Parkway 的 Google 总部。
手头没有精确的人数统计,不过目测来看,大概有120-150人。看到的第一个见过照片的人是著名的 Cameraman 同学, DragonFly 的 Matthew Dillon 老大!
由于今年是 FreeBSD 计划成立15周年,今年的 MeetBSD ‘08 California 很大程度上是一次 FreeBSD 的活动。
An elegant tool for analysis of your website regarding its appearance slowness. Why is it slow?
What you need are:
最近看到 OpenSolaris 上面的 ZFS 引入了将 ZIL 写到另一个 pool 的方法。这种做法非常类似于 FreeBSD 2005年的 Google SoC 项目—-GEOM Journal。
简单地说,这种做法的原理就是将准备写的数据(注意,不是元数据,而是数据)首先写到固态盘上,然后再将数据写回。这样做有很重要的好处,即先前必须同步写入的数据(例如fsync()、文件系统元数据更新等等),可以不必做完整的回写,而只需将 SSD 作为回写快取缓存 (Write-Back Cache) 了。
做了一个试验,导一个10万多revision的svn库进来到trac里面,结果整整一个上午过去了,才导了一半。估计得等到下班才能有结果了吧。。。
以前一直觉得mailman与postfix的VERP支持配合的很不好,今天把它patch掉了。需要注意一点即 postfix 的smtpd_authorized_verp_clients默认设置为$authorized_verp_clients,这个值没有意义,需要自己改成合适的值。
周六、周日两天的AsiaBSDCon正式报告会,内容非常充实,以致于我都没有时间去整理和把一些感想写出来。今天终于准备离开了,现在是当地时间早上1点半。
说说我比较关注的几个presentation。
Brooks Davis做的关于FreeBSD高性能计算集群的报告,讲到了他们在选型方面遇到的一些问题。计算集群主要考虑的成本是能源消耗与性能之比,因此他们采购了一批Intel机器之后,选择了AMD的产品,而新一代集群也许又要选择Intel的产品;早期Alpha的节点,已经基本被x86的取代。另一方面,他讲述了相当长时间的关于高性能计算为何有很多人使用Linux的问题,由于很多人使用Linux,导致很多做高性能计算的人有这样一种概念,如果那不是超级计算机,就一定是Linux——然而,这样一来,FreeBSD的集群就会遇到一些问题,因此,他们完成了一系列MPI及相关的支持系统的支持,并制作了port。总体而言,高性能计算集群中更倾向于采用自动化的任务分配,以降低管理成本;他们对SGE(Sun Grid Engine)和监控工具进行了一系列修改,使其在FreeBSD上运行的效果与Linux相当甚至更好。
从某种意义上说,超级计算中的开发人员和系统管理员,会朝着两个完全不同的方向去思考问题。如何调和两者之间的矛盾呢?其实,这也正是在其他计算系统中经常碰到的问题。
前一阵在为cn.freebsd.org的邮件列表做维护时发现,由于网易的邮件系统无法正确地(更具体地说,是以符合标准的方式)进行退信,导致一些无效地址仍然在不停地接收邮件,导致邮件系统的管理员必须手动处理这些退信产生的报告。后来在挖掘了mailman的文档之后,发现它支持djb的VERP退信。
相比处理符合标准的退信来说,VERP所需的编码量更少,并且对于不符合标准的退信也能够做很好的处理。从开销上说,由于VERP不需要parse整封邮件,因此也不会导致性能上的折损,甚至由于不需要进行任何解信操作,这种做法在性能上应该会优于标准的做法。
今天,John Birrell同学commit了一个不大不小的patchset—-将KSE变为内核选项。具体说来,在-CURRENT上,KSE不再是一个必选项了。
KSE是FreeBSD 5.0-CURRENT时的一个非常重要的技术探索,它是对由华盛顿大学THOMAS E. ANDERSON等人提出的调度器激活概念的一个实现。
对于M:N线程来说,调度器激活是一项十分先进的概念。在这个模型中,内核并不需要了解用户态线程的细节,而用户态线程也并不是由内核直接调度,相反,这些线程被绑定到一系列"调度实体"上,内核能够看到这些调度实体,并在上下文切换时激活用户态的线程调度器。由于减少了内核-用户态的上下文切换操作,因此理论上这一模型能够获得更好的性能。