BlogDay 2007

FeedBurner 已死,Feedsky 当立! 现在广大 Blogger 们除了呼吸稍有不畅之外,还能忍耐。

昨天 (8 月31) 日是 BlogDay,晚上匆忙扫了几眼 Google Reader ,很多朋友都响应了这个活动。06 年 Blog Day 我也参加过,今天马后炮一下补充一篇。

我推荐的几个 Blog:

Livid’s Paranoid
url: http://www.livid.cn/
网络上对于 Livid 有很多并不过分的夸奖。他前一段时间关于 “个人数据中心” 的想法很具有战略性。Livid 与 Flypig 两个人是 “80 后靠谱” 的有力证明。

大徐
url: http://daxu.net/
大徐在雅虎工作。我非常喜欢他的 Blog 写作风格。大徐是个热爱生活的程序员

DBA story
url: http://www.ixdba.com/
DBA 为题材的 Blog 有好几个了,Piner 这个虽然出现的比较晚,但也相对有更多的技术信息,不像我的 Blog 兑了那么多水。 最近他开始走怀旧路线和亲情路线了,也耐看,我只是担心他的写作热情是否会持续下去。所以在这里推荐一下.

插一腿的薄壳
url: http://www.bullog.cn/blogs/cyt/
插一腿是个半职业赌士。从这里我了解了关于赌徒的很多有趣生活。他的那部小说妙趣横生。

Taobao UED
url: http://ued.taobao.com/blog/
淘宝用户界面设计团队的 Blog。我喜欢看其中的 UI / UE 内容,其他文章也没有写成散文诗,所以是值得看看的,也是传达淘宝文化的一个窗口。

Tag BlogDay 一下。另外就不一一留言通知了,如果这些 Blogger 能看到,他们就能看到。不能看到,我留言作用也不大。

Blogger 来,Blogger 走,而 Blog 永存。

FeedBurner 已死,FeedBurner 万岁!

EOF

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

RHEL 的 I/O 调度器(Scheduler)与 Database 的关系

今天参加 AIX 的技术培训,听了一些关于 CPU 调度的算法,倒也都是些基本知识,回想讲课内容的时候倒让我想起 Linux Kernel 的 I/O Scheduler 来。

这篇 Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel 是必须的参考资料。相比 Linux 2.4 Kernel 的一种 IO 调度器,2.6 做了很多改进,共有四种 IO 调度器。

Deadline scheduler

Deadline scheduler 用 deadline 算法保证对于既定的 IO 请求以最小的延迟时间,从这一点理解,对于 DSS 应用应该会是很适合的。

Anticipatory scheduler

Anticipatory scheduler(as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是”预料的, 预想的”, 这个词的确揭示了这个算法的特点,简单的说,有个 IO 发生的时候,如果又有进程请求 IO 操作,则将产生一个默认的 6 毫秒猜测时间,猜测下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时,对数据库应用很糟糕,而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的,因为那个”猜测”实际上的目的是为了减少磁头移动时间。

Completely Fair Queuing

虽然这世界上没有完全公平的事情,但是并不妨碍开源爱好者们设计一个完全公平的 IO 调度算法。Completely Fair Queuing (cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列,各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中,SuSE Linux 好像是最先默认用 cfq 的.

NOOP

Noop 对于 IO 不那么操心,对所有的 IO请求都用 FIFO 队列形式处理,默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然,对于复杂一点的应用类型,使用这个调度器,用户自己就会非常操心。

那么如果跑数据库应用,那个更好一些呢? 我们看Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel一文中的测试结果:

scheduler.jpg

对于数据库应用, Anticipatory Scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点,而 cfq 综合来看表现更好一些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3,整体 IO 改进还是不小的。

哪一种方式更好? 很难说,每一种方式都有特定的应用对它是最适合的。就像上面的 as 好像表现比较差,如果是 CPU 密集型的应用呢?

Tip:
Q:如何确认当前用什么 IO 调度器?
A: 过滤 /var/log/boot.msg 文件, 查找 “io scheduler”, 看到了么?

在 操作系统上可以查到的相关文档:
/usr/src/linux/Documentation/block/as-iosched.txt
/usr/src/linux/Documentation/block/deadline-iosched.txt

EOF

更新: Ubuntu Server 使用 Deadline 而不是桌面版的 CFQ 算法

从很多实际测试场景来看,Deadline 更适合跑 MySQL 数据库。

补充一下关于 RSS 订阅

FeedBurner 不能访问带来的影响有多大? Virushuo Che Dong 都说其实没那么严重,因为大部分都是用在线阅读器的,对这一部分的影响到的确是很小,但是要考虑到 GreatNews 用户和其他用桌面客户端工具订阅的啊。

继续是用 FeedBurner 的 Blogger,注意原来在 FeedBurner 上起用高级统计功能的,必须关闭掉,这样 RSS 阅读器抓到的文章链接就不需要通过 FeedBurner 中转了。

另外,在本地 Blog 上引用 FeedBurner 订阅统计数的,会显示不出来。如果你是用 Dreamhost 这样的国外虚拟主机的用户,可以考虑在后台做一个 crontab 脚本,定期 wget 那个 订阅数字图片到本地来,然后直接引用本地图片地址就可以了(这样其实也减少了网络交互,对你的网站提速也有那么一点作用的。

最后一点友情提示: 请统一用我站内的 URL 地址订阅 RSS 更新。 这样每次变化就不会有影响了. 推荐用这两个地址:

https://www.dbanotes.net/index.xml
或者
https://www.dbanotes.net/atom.xml

EOF

FeedBurner 被阻尼,Feed 托管转到 FeedSky

早晚会有这么一天,连 Flickr 都被阻尼了,FeedBurner 每天有大量的”内容”进出,不被阻尼是怪事,被阻尼是正常事件,慢慢的就习惯了。再见, FeedBurner! 广大 Blogger 会想你.

现在默认大多数用户订阅的 Feed 应该自动转换到 FeedSky 上了。今天我还在外面开会,FeedSky 输出的 Feed 集成了 Flickr,会有不少垃圾输出,我尽快修改一下。

如果还不灵,手工用 这个地址更新一下吧: http://feed.feedsky.com/fenng

Upgrade:

有的朋友在我的 Blog 上搜索 关于这对这个事件对 Feed 地址 URL Rewrite 的信息:
其实并不复杂。我以前也说过,再重复一下。首先在模版管理的地方创建一个 2feedsky_index.xml 的文件,内容和 index.xml 或者 atom.xml 即可。然后在 FeedSky 上把自己的 Feed 地址修改为新创建的这个文件地址。再修改站点根目录下的 .htaccess 文件,内容如下:

Redirect temp /index.xml http://feed.feedsky.com/fenng
Redirect temp /atom.xml http://feed.feedsky.com/fenng

FeedBurner 不能访问带来的影响有多大? Virushuo Che Dong 都说其实没那么严重,因为大部分都是用在线阅读器的,对这一部分的影响到的确是很小,但是要考虑到 GreatNews 用户和其他用桌面客户端工具订阅的啊。

继续是用 FeedBurner 的 Blogger,注意原来在 FeedBurner 上起用高级统计功能的,必须关闭掉,这样 RSS 阅读器抓到的文章链接就不需要通过 FeedBurner 中转了。

另外,在本地 Blog 上引用 FeedBurner 订阅统计数的,会显示不出来。如果你是用 Dreamhost 这样的国外虚拟主机的用户,可以考虑在后台做一个 crontab 脚本,定期 wget 那个 订阅数字图片到本地来,然后直接引用本地图片地址就可以了(这样其实也减少了网络交互,对你的网站提速也有那么一点作用的。

补充建议: 请统一用我站内的 URL 地址订阅 RSS 更新。 这样每次变化就不会有影响了. 推荐用这两个地址:

https://www.dbanotes.net/index.xml
或者
https://www.dbanotes.net/atom.xml

另外 FeedBurner 的地址还是保留的,如果用在线阅读工具不会受到影响

EOF
2e3587f6