这周遇到了三个值得说一说的问题，每一个问题都带来了不小的麻烦，作为教训再来回顾一下。more第一个问题，在某次上线之后，突然出现了很多AttrubuteError和TypeError，这些错误看起来都是不应该出现的，究其原因，是从 memcached 中取回的数据和预期的不同。在代码中对容易出问题的 key 做跟踪，却找不到有任何代码对这些 key 做过 set 操作，但 memcached 中的数据的确是错的，由此基本可以推定并不是有代码 set 了错误的 key。在定位问题的过程中发现，重启应用时会有很大的机率触发 memcached 数据错乱，以此为线索，hongqn最终定位到了导致此问题的原因：Quixote在 fork 子进程之前 import 了部分应用代码，某个 changset 中的改动又使得部分代码在被 import 时就创建了到 memcached 的连接，多个子进程使用同一个 memcached 连接，数据包交织导致了 memcached 通讯混乱。这里主要有两个问题：Quixote在 fork 之前调用了应用代码、memcached 客户端库非线程安全；解决这两个问题中的任意一个都可以避免数据错乱的问题发生，第二个问题也可以通过在 fork 之后重新建立连接来作为 workaround 手段而绕过其线程安全的问题。第二个问题危害就更大了，几乎所有的 MySQ ...继续阅读 (17)

这周遇到了三个值得说一说的问题，每一个问题都带来了不小的麻烦，作为教训再来回顾一下。more第一个问题，在某次上线之后，突然出现了很多AttrubuteError和TypeError，这些错误看起来都是不应该出现的，究其原因，是从 memcached 中取回的数据和预期的不同。在代码中对容易出问题的 key 做跟踪，却找不到有任何代码对这些 key 做过 set 操作，但 memcached 中的数据的确是错的，由此基本可以推定并不是有代码 set 了错误的 key。在定位问题的过程中发现，重启应用时会有很大的机率触发 memcached 数据错乱，以此为线索，hongqn最终定位到了导致此问题的原因：Quixote在 fork 子进程之前 import 了部分应用代码，某个 changset 中的改动又使得部分代码在被 import 时就创建了到 memcached 的连接，多个子进程使用同一个 memcached 连接，数据包交织导致了 memcached 通讯混乱。这里主要有两个问题：Quixote在 fork 之前调用了应用代码、memcached 客户端库非线程安全；解决这两个问题中的任意一个都可以避免数据错乱的问题发生，第二个问题也可以通过在 fork 之后重新建立连接来作为 workaround 手段而绕过其线程安全的问题。第二个问题危害就更大了，几乎所有的 MySQ ...继续阅读 (12)

在给 MySQL 数据库访问层增加新功能时遇到了这样的错误：1ProgrammingError: (2014, "Commands out of sync; you can't run this command now")之前零星地见到过几次，因为发生频度很低，就没有太在意，这次找了一下原因，MySQL 文档对Commands out of sync错误的描述是这样的：moreIf you get Commands out of sync; you can’t run this command now in your client code, you are calling client functions in the wrong order.This can happen, for example, if you are using mysql_use_result() and try to execute a new query before you have called mysql_free_result(). It can also happen if you try to execute two queries that return data without calling mysql_use_result() or mysql_store_result ...继续阅读 (34)

在给 MySQL 数据库访问层增加新功能时遇到了这样的错误：1ProgrammingError: (2014, "Commands out of sync; you can't run this command now")之前零星地见到过几次，因为发生频度很低，就没有太在意，这次找了一下原因，MySQL 文档对Commands out of sync错误的描述是这样的：moreIf you get Commands out of sync; you can’t run this command now in your client code, you are calling client functions in the wrong order.This can happen, for example, if you are using mysql_use_result() and try to execute a new query before you have called mysql_free_result(). It can also happen if you try to execute two queries that return data without calling mysql_use_result() or mysql_store_result ...继续阅读 (30)

在给 MySQL 数据库访问层增加新功能时遇到了这样的错误：1ProgrammingError: (2014, "Commands out of sync; you can't run this command now")之前零星地见到过几次，因为发生频度很低，就没有太在意，这次找了一下原因，MySQL 文档对Commands out of sync错误的描述是这样的：moreIf you get Commands out of sync; you can’t run this command now in your client code, you are calling client functions in the wrong order.This can happen, for example, if you are using mysql_use_result() and try to execute a new query before you have called mysql_free_result(). It can also happen if you try to execute two queries that return data without calling mysql_use_result() or mysql_store_result ...继续阅读 (13)

遇到了几例 MySQL 没用使用预期索引的问题，读了些文档之后，发现 MySQL 的类型转换对索引选择的影响还真是一个不大不小的坑。比如有这样一张 MySQL 表：12345678910CREATE TABLE `indextest` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`name` varchar(10) DEFAULT NULL,`age` tinyint(3) unsigned NOT NULL DEFAULT '0',`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY (`id`),KEY `idx_name` (`name`),KEY `idx_age` (`age`),KEY `idx_create` (`create_time`)) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1morename是一个有索引的varchar字段，表内数据是这样的：12345678+----+--------+-----+---------------------+| id | name | age | create_time |+----+--------+-- ...继续阅读 (31)

遇到了几例 MySQL 没用使用预期索引的问题，读了些文档之后，发现 MySQL 的类型转换对索引选择的影响还真是一个不大不小的坑。比如有这样一张 MySQL 表：12345678910CREATE TABLE `indextest` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`name` varchar(10) DEFAULT NULL,`age` tinyint(3) unsigned NOT NULL DEFAULT '0',`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY (`id`),KEY `idx_name` (`name`),KEY `idx_age` (`age`),KEY `idx_create` (`create_time`)) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1morename是一个有索引的varchar字段，表内数据是这样的：12345678+----+--------+-----+---------------------+| id | name | age | create_time |+----+--------+-- ...继续阅读 (16)

遇到了几例 MySQL 没用使用预期索引的问题，读了些文档之后，发现 MySQL 的类型转换对索引选择的影响还真是一个不大不小的坑。比如有这样一张 MySQL 表：12345678910CREATE TABLE `indextest` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`name` varchar(10) DEFAULT NULL,`age` tinyint(3) unsigned NOT NULL DEFAULT '0',`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY (`id`),KEY `idx_name` (`name`),KEY `idx_age` (`age`),KEY `idx_create` (`create_time`)) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1morename是一个有索引的varchar字段，表内数据是这样的：12345678+----+--------+-----+---------------------+| id | name | age | create_time |+----+--------+-- ...继续阅读 (13)

MySQL 服务器设置的 binlog 单文件最大为 1GB，偶然发现会有十几 GB 大小的 binlog 文件，从产生的时间上看像是某个 cron job 使用了超大的 transaction，为了找出“罪魁祸首”，我需要分析一下 binlog。more在使用 mysqlbinlog 将 binary log 转换为文本文件时，发现根分区很快就被塞满了，使用 lsof 发现 mysqlbinlog 在往 /tmp 下写临时文件：123456789# lsof -p 17423COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEmysqlbinl 17423 root 1w REG 0,19 791765366 3186036 /mfs/user/xupeng/tmp/bigbinlogs/bigbinlog.sqlmysqlbinl 17423 root 2u CHR 136,7 0t0 10 /dev/pts/7mysqlbinl 17423 root 3r REG 0,19 13863171331 3172073 /mfs/user/xupeng/tmp/bigbinlogs/log.000323mysqlbinl ...继续阅读 (57)

MySQL 服务器设置的 binlog 单文件最大为 1GB，偶然发现会有十几 GB 大小的 binlog 文件，从产生的时间上看像是某个 cron job 使用了超大的 transaction，为了找出“罪魁祸首”，我需要分析一下 binlog。more在使用 mysqlbinlog 将 binary log 转换为文本文件时，发现根分区很快就被塞满了，使用 lsof 发现 mysqlbinlog 在往 /tmp 下写临时文件：123456789# lsof -p 17423COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEmysqlbinl 17423 root 1w REG 0,19 791765366 3186036 /mfs/user/xupeng/tmp/bigbinlogs/bigbinlog.sqlmysqlbinl 17423 root 2u CHR 136,7 0t0 10 /dev/pts/7mysqlbinl 17423 root 3r REG 0,19 13863171331 3172073 /mfs/user/xupeng/tmp/bigbinlogs/log.000323mysqlbinl ...继续阅读 (34)

MySQL 服务器设置的 binlog 单文件最大为 1GB，偶然发现会有十几 GB 大小的 binlog 文件，从产生的时间上看像是某个 cron job 使用了超大的 transaction，为了找出“罪魁祸首”，我需要分析一下 binlog。more在使用 mysqlbinlog 将 binary log 转换为文本文件时，发现根分区很快就被塞满了，使用 lsof 发现 mysqlbinlog 在往 /tmp 下写临时文件：123456789# lsof -p 17423COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEmysqlbinl 17423 root 1w REG 0,19 791765366 3186036 /mfs/user/xupeng/tmp/bigbinlogs/bigbinlog.sqlmysqlbinl 17423 root 2u CHR 136,7 0t0 10 /dev/pts/7mysqlbinl 17423 root 3r REG 0,19 13863171331 3172073 /mfs/user/xupeng/tmp/bigbinlogs/log.000323mysqlbinl ...继续阅读 (29)

Code swarm是一个可视化项目，最常见的用途是把代码仓库的提交历史可视化，changesets 以时间顺序回放，每个发生变更的文件作为一个闪亮的光点从各处汇聚在对应的 committer 身上，把项目的演进历史以视频的方式形象地呈现出来，通常还会配上激动人心的背景音乐，令程序员们潸然泪下。more很多著名的开源项目比如Python、Subversion、Django、PostgreSQL、Apache等等都有 code swarm 视频，很多互联网公司也都有 code swarm 视频，比如Twitter、Last.fm。可视化是一项伟大的技术，它使非专业人士也能形象地感受到“虚无事物”的发展历程，向致力于可视化的科学家和程序员致敬！豆瓣发展至今已经有 7 年了，2008 年的时候hongqn做过一个code swarm 视频，时至今日，豆瓣的工程师队伍已经壮大了数倍，再次做了 code swarm 视频。这次我使用了code_swarm项目的一个fork，这个 fork 最大的亮点是加入了头像支持，除了 committer 的 ID 之外，还可以显示头像，使辨识度更高，按照项目的简要文档可以很容易地为单仓库生成视频。code_swarm 接受的输入是一个配置文件和一个 XML 格式的 events 序列，每一个发生变更的文件加上 commiter ID 和时间（1970-0 ...继续阅读 (30)

Code swarm是一个可视化项目，最常见的用途是把代码仓库的提交历史可视化，changesets 以时间顺序回放，每个发生变更的文件作为一个闪亮的光点从各处汇聚在对应的 committer 身上，把项目的演进历史以视频的方式形象地呈现出来，通常还会配上激动人心的背景音乐，令程序员们潸然泪下。more很多著名的开源项目比如Python、Subversion、Django、PostgreSQL、Apache等等都有 code swarm 视频，很多互联网公司也都有 code swarm 视频，比如Twitter、Last.fm。可视化是一项伟大的技术，它使非专业人士也能形象地感受到“虚无事物”的发展历程，向致力于可视化的科学家和程序员致敬！豆瓣发展至今已经有 7 年了，2008 年的时候hongqn做过一个code swarm 视频，时至今日，豆瓣的工程师队伍已经壮大了数倍，再次做了 code swarm 视频。这次我使用了code_swarm项目的一个fork，这个 fork 最大的亮点是加入了头像支持，除了 committer 的 ID 之外，还可以显示头像，使辨识度更高，按照项目的简要文档可以很容易地为单仓库生成视频。code_swarm 接受的输入是一个配置文件和一个 XML 格式的 events 序列，每一个发生变更的文件加上 commiter ID 和时间（1970-0 ...继续阅读 (25)

Code swarm是一个可视化项目，最常见的用途是把代码仓库的提交历史可视化，changesets 以时间顺序回放，每个发生变更的文件作为一个闪亮的光点从各处汇聚在对应的 committer 身上，把项目的演进历史以视频的方式形象地呈现出来，通常还会配上激动人心的背景音乐，令程序员们潸然泪下。more很多著名的开源项目比如Python、Subversion、Django、PostgreSQL、Apache等等都有 code swarm 视频，很多互联网公司也都有 code swarm 视频，比如Twitter、Last.fm。可视化是一项伟大的技术，它使非专业人士也能形象地感受到“虚无事物”的发展历程，向致力于可视化的科学家和程序员致敬！豆瓣发展至今已经有 7 年了，2008 年的时候hongqn做过一个code swarm 视频，时至今日，豆瓣的工程师队伍已经壮大了数倍，再次做了 code swarm 视频。这次我使用了code_swarm项目的一个fork，这个 fork 最大的亮点是加入了头像支持，除了 committer 的 ID 之外，还可以显示头像，使辨识度更高，按照项目的简要文档可以很容易地为单仓库生成视频。code_swarm 接受的输入是一个配置文件和一个 XML 格式的 events 序列，每一个发生变更的文件加上 commiter ID 和时间（1970-0 ...继续阅读 (11)

近来美国在尚未通过的SOPA法案上产生了巨大争议，该法案最邪恶的地方在于，它使得 ISP 和版权方有权利因为某网站上有一点侵权内容而“拔其网线” - 使其域名无法解析，此权利也很容易被滥用。more此举最大的获益者可能是日益衰落不思进取的传统出版、娱乐等行业，而代表先进技术生产力的互联网和互联网企业则遭受极大威胁，这是以损害创新为代价、以知识产权保护为名来庇护濒死的产业模式，实在是饮鸩止渴，阻碍信息传播和技术进步。我的域名一直都是在 Godaddy 注册的，而 Godaddy 站在了SOPA支持者行列，颇让人意外，其实公开表示支持的公司还挺多的，比如这里就有一个不完全列表，但令人感到欣慰的是，我喜欢或者因其而受益的美国公司或组织全都是坚定的 SOPA 反对者，比如：GoogleFacebookTwitterWikipediaQuoraLinodeGithubOpenDNS…等等等等。鉴于此，我打算将我在 Godaddy 的域名全部 transfer 到别的域名注册商，name.com 和 namecheap.com 都是不错的选择，做了一些比较之后，我打算将域名 transfer 到 name.com，之所以选择 name.com，主要是因为 name.com 也算是一个比较老牌的注册商/代理商了，另外也是因为 name.com 的价格比较公道。Transfer 的详细 ...继续阅读 (28)

近来美国在尚未通过的SOPA法案上产生了巨大争议，该法案最邪恶的地方在于，它使得 ISP 和版权方有权利因为某网站上有一点侵权内容而“拔其网线” - 使其域名无法解析，此权利也很容易被滥用。more此举最大的获益者可能是日益衰落不思进取的传统出版、娱乐等行业，而代表先进技术生产力的互联网和互联网企业则遭受极大威胁，这是以损害创新为代价、以知识产权保护为名来庇护濒死的产业模式，实在是饮鸩止渴，阻碍信息传播和技术进步。我的域名一直都是在 Godaddy 注册的，而 Godaddy 站在了SOPA支持者行列，颇让人意外，其实公开表示支持的公司还挺多的，比如这里就有一个不完全列表，但令人感到欣慰的是，我喜欢或者因其而受益的美国公司或组织全都是坚定的 SOPA 反对者，比如：GoogleFacebookTwitterWikipediaQuoraLinodeGithubOpenDNS…等等等等。鉴于此，我打算将我在 Godaddy 的域名全部 transfer 到别的域名注册商，name.com 和 namecheap.com 都是不错的选择，做了一些比较之后，我打算将域名 transfer 到 name.com，之所以选择 name.com，主要是因为 name.com 也算是一个比较老牌的注册商/代理商了，另外也是因为 name.com 的价格比较公道。Transfer 的详细 ...继续阅读 (24)

近来美国在尚未通过的SOPA法案上产生了巨大争议，该法案最邪恶的地方在于，它使得 ISP 和版权方有权利因为某网站上有一点侵权内容而“拔其网线” - 使其域名无法解析，此权利也很容易被滥用。more此举最大的获益者可能是日益衰落不思进取的传统出版、娱乐等行业，而代表先进技术生产力的互联网和互联网企业则遭受极大威胁，这是以损害创新为代价、以知识产权保护为名来庇护濒死的产业模式，实在是饮鸩止渴，阻碍信息传播和技术进步。我的域名一直都是在 Godaddy 注册的，而 Godaddy 站在了SOPA支持者行列，颇让人意外，其实公开表示支持的公司还挺多的，比如这里就有一个不完全列表，但令人感到欣慰的是，我喜欢或者因其而受益的美国公司或组织全都是坚定的 SOPA 反对者，比如：GoogleFacebookTwitterWikipediaQuoraLinodeGithubOpenDNS…等等等等。鉴于此，我打算将我在 Godaddy 的域名全部 transfer 到别的域名注册商，name.com 和 namecheap.com 都是不错的选择，做了一些比较之后，我打算将域名 transfer 到 name.com，之所以选择 name.com，主要是因为 name.com 也算是一个比较老牌的注册商/代理商了，另外也是因为 name.com 的价格比较公道。Transfer 的详细 ...继续阅读 (13)

用了三年多 Wordpress，由于实在很懒，没有写过多少东西，但跑在Linode VPS上的 Wordpress 却一直占用了很多资源，几个PHP-FPM进程加上 MySQL 就用掉了将近 400MB 内存，却没有什么访问量，觉得很不划算，再加上 Wrodpress 越来越臃肿，就想把它换成一个静态内容发布系统。more简单看了一下，很快就找到了Octopress，一眼就看上了，花了半个小时试用，还是很符合我的使用习惯的：配置简单，简单修个几个配置就能使用Markdown语法，VIM + Terminal 就能完成内容书写与发布定制简单，plugin 看起来也不复杂，不过写 plugin 要学一点 ruby默认的模版就很漂亮，也很便于阅读花了几个小时把 Wordpress 里旧的文章导出、导入到 Octopress，手工编辑了部分不像样的文章，一个焕然一新的静态发布 blog 就基本可用了，在这个过程中我主要参考了这些文档和文章：http://octopress.org/docs/http://felipecypriano.com/2011/09/16/why-ive-migrated-to-octopress/http://mattgemmell.com/2011/09/12/blogging-with-octopress/把这些读一遍就能顺利完成迁移和部署，所以就不重复步骤了 ...继续阅读 (35)

用了三年多 Wordpress，由于实在很懒，没有写过多少东西，但跑在Linode VPS上的 Wordpress 却一直占用了很多资源，几个PHP-FPM进程加上 MySQL 就用掉了将近 400MB 内存，却没有什么访问量，觉得很不划算，再加上 Wrodpress 越来越臃肿，就想把它换成一个静态内容发布系统。more简单看了一下，很快就找到了Octopress，一眼就看上了，花了半个小时试用，还是很符合我的使用习惯的：配置简单，简单修个几个配置就能使用Markdown语法，VIM + Terminal 就能完成内容书写与发布定制简单，plugin 看起来也不复杂，不过写 plugin 要学一点 ruby默认的模版就很漂亮，也很便于阅读花了几个小时把 Wordpress 里旧的文章导出、导入到 Octopress，手工编辑了部分不像样的文章，一个焕然一新的静态发布 blog 就基本可用了，在这个过程中我主要参考了这些文档和文章：http://octopress.org/docs/http://felipecypriano.com/2011/09/16/why-ive-migrated-to-octopress/http://mattgemmell.com/2011/09/12/blogging-with-octopress/把这些读一遍就能顺利完成迁移和部署，所以就不重复步骤了 ...继续阅读 (28)

用了三年多 Wordpress，由于实在很懒，没有写过多少东西，但跑在Linode VPS上的 Wordpress 却一直占用了很多资源，几个PHP-FPM进程加上 MySQL 就用掉了将近 400MB 内存，却没有什么访问量，觉得很不划算，再加上 Wrodpress 越来越臃肿，就想把它换成一个静态内容发布系统。more简单看了一下，很快就找到了Octopress，一眼就看上了，花了半个小时试用，还是很符合我的使用习惯的：配置简单，简单修个几个配置就能使用Markdown语法，VIM + Terminal 就能完成内容书写与发布定制简单，plugin 看起来也不复杂，不过写 plugin 要学一点 ruby默认的模版就很漂亮，也很便于阅读花了几个小时把 Wordpress 里旧的文章导出、导入到 Octopress，手工编辑了部分不像样的文章，一个焕然一新的静态发布 blog 就基本可用了，在这个过程中我主要参考了这些文档和文章：http://octopress.org/docs/http://felipecypriano.com/2011/09/16/why-ive-migrated-to-octopress/http://mattgemmell.com/2011/09/12/blogging-with-octopress/把这些读一遍就能顺利完成迁移和部署，所以就不重复步骤了 ...继续阅读 (13)

线上的 MySQL 服务器一直都在使用 XFS 文件系统，性能和稳定性都表现良好，使用的内核版本是 2.6.29，经过时间和访问压力的验证，表现也不错。前一段时间在测试几款 SSD 产品，考虑到 XFS 在内核 2.6.38 之后才加入了对 FITRIM 的支持（ref1ref2），就在 2.6.38 和 2.6.39 上对 SSD 做了测试，测试结果却让人大跌眼镜，XFS 在 2.6.38 和 2.6.39 之上的性能差到完全不能接受。more我在内核 2.6.29 和 2.6.39 下使用fio分别对 raw device、XFS 和 ext4 做了一个简单的 IO 测试，测试参数是这样的：123fio --filename=$PATH-TO-TEST-FILE --direct=1 --rw=randrw --bs=16k\--size=50G --numjobs=16 --runtime=120 --group_reporting\--name=test--rwmixread=90 --thread --ioengine=psync大意是：使用 non-buffered I/O，16 个并发 IO 线程，做 16KB 块大小的随机读写混合测试，读写比为 9:1下面是 2.6.29 下的测试结果：2.6.29 + raw device2.6.29 + XFS2.6.29 + ...继续阅读 (33)

线上的 MySQL 服务器一直都在使用 XFS 文件系统，性能和稳定性都表现良好，使用的内核版本是 2.6.29，经过时间和访问压力的验证，表现也不错。前一段时间在测试几款 SSD 产品，考虑到 XFS 在内核 2.6.38 之后才加入了对 FITRIM 的支持（ref1ref2），就在 2.6.38 和 2.6.39 上对 SSD 做了测试，测试结果却让人大跌眼镜，XFS 在 2.6.38 和 2.6.39 之上的性能差到完全不能接受。more我在内核 2.6.29 和 2.6.39 下使用fio分别对 raw device、XFS 和 ext4 做了一个简单的 IO 测试，测试参数是这样的：123fio --filename=$PATH-TO-TEST-FILE --direct=1 --rw=randrw --bs=16k\--size=50G --numjobs=16 --runtime=120 --group_reporting\--name=test--rwmixread=90 --thread --ioengine=psync大意是：使用 non-buffered I/O，16 个并发 IO 线程，做 16KB 块大小的随机读写混合测试，读写比为 9:1下面是 2.6.29 下的测试结果：2.6.29 + raw device2.6.29 + XFS2.6.29 + ...继续阅读 (20)

线上的 MySQL 服务器一直都在使用 XFS 文件系统，性能和稳定性都表现良好，使用的内核版本是 2.6.29，经过时间和访问压力的验证，表现也不错。前一段时间在测试几款 SSD 产品，考虑到 XFS 在内核 2.6.38 之后才加入了对 FITRIM 的支持（ref1ref2），就在 2.6.38 和 2.6.39 上对 SSD 做了测试，测试结果却让人大跌眼镜，XFS 在 2.6.38 和 2.6.39 之上的性能差到完全不能接受。more我在内核 2.6.29 和 2.6.39 下使用fio分别对 raw device、XFS 和 ext4 做了一个简单的 IO 测试，测试参数是这样的：123fio --filename=$PATH-TO-TEST-FILE --direct=1 --rw=randrw --bs=16k\--size=50G --numjobs=16 --runtime=120 --group_reporting\--name=test--rwmixread=90 --thread --ioengine=psync大意是：使用 non-buffered I/O，16 个并发 IO 线程，做 16KB 块大小的随机读写混合测试，读写比为 9:1下面是 2.6.29 下的测试结果：2.6.29 + raw device2.6.29 + XFS2.6.29 + ...继续阅读 (19)

最近在写一个配置推送客户端，结构如下图：每一个应用服务进程会起一个额外的线程，与 ZooKeeper 保持连接，需要变更配置时，将新配置更新到 ZooKeeper，ZooKeeper 将配置推送到所有的客户端，客户端收到配置之后，即时更新进程内的配置信息，并将更新配置成功与否、延时、错误等信息反馈到 redis，以这样的方式做到不重启服务更新配置。more同时也会有一个独立的客户端与 ZooKeeper 保持连接，收到 ZooKeeper 推送的配置之后，将配置写回并提交到 Puppet 配置仓库中，这样仍然保持只在一个地方修改配置的习惯。这个推送客户端的第一个应用场景是更新线上的 MySQL 配置，线上服务是 Quixote + SCGI，由于在 SCGI server fork 子进程之前就已经 import 了部分自有库，其中包括这个配置推送客户端的使用者，因此，这个客户端必须是 lazy 的，只能在 fork 发生之后才能启动线程、建立与 ZooKeeper 和 redis 的连接。将这个客户端与 Quixote + SCGI 服务进行联调时，奇怪的事情发生了，配置发生变更时，客户端并没有立刻收到 ZooKeeper 的推送，而是等到下一次用户请求到达时才会收到，起初以为是线程根本就没有在工作，后来发现，线程也并不是完全不工作，而是阻塞在了某个地方，当有用户请求到达时，线程 ...继续阅读 (38)

最近在写一个配置推送客户端，结构如下图：每一个应用服务进程会起一个额外的线程，与 ZooKeeper 保持连接，需要变更配置时，将新配置更新到 ZooKeeper，ZooKeeper 将配置推送到所有的客户端，客户端收到配置之后，即时更新进程内的配置信息，并将更新配置成功与否、延时、错误等信息反馈到 redis，以这样的方式做到不重启服务更新配置。more同时也会有一个独立的客户端与 ZooKeeper 保持连接，收到 ZooKeeper 推送的配置之后，将配置写回并提交到 Puppet 配置仓库中，这样仍然保持只在一个地方修改配置的习惯。这个推送客户端的第一个应用场景是更新线上的 MySQL 配置，线上服务是 Quixote + SCGI，由于在 SCGI server fork 子进程之前就已经 import 了部分自有库，其中包括这个配置推送客户端的使用者，因此，这个客户端必须是 lazy 的，只能在 fork 发生之后才能启动线程、建立与 ZooKeeper 和 redis 的连接。将这个客户端与 Quixote + SCGI 服务进行联调时，奇怪的事情发生了，配置发生变更时，客户端并没有立刻收到 ZooKeeper 的推送，而是等到下一次用户请求到达时才会收到，起初以为是线程根本就没有在工作，后来发现，线程也并不是完全不工作，而是阻塞在了某个地方，当有用户请求到达时，线程 ...继续阅读 (21)

最近在写一个配置推送客户端，结构如下图：每一个应用服务进程会起一个额外的线程，与 ZooKeeper 保持连接，需要变更配置时，将新配置更新到 ZooKeeper，ZooKeeper 将配置推送到所有的客户端，客户端收到配置之后，即时更新进程内的配置信息，并将更新配置成功与否、延时、错误等信息反馈到 redis，以这样的方式做到不重启服务更新配置。more同时也会有一个独立的客户端与 ZooKeeper 保持连接，收到 ZooKeeper 推送的配置之后，将配置写回并提交到 Puppet 配置仓库中，这样仍然保持只在一个地方修改配置的习惯。这个推送客户端的第一个应用场景是更新线上的 MySQL 配置，线上服务是 Quixote + SCGI，由于在 SCGI server fork 子进程之前就已经 import 了部分自有库，其中包括这个配置推送客户端的使用者，因此，这个客户端必须是 lazy 的，只能在 fork 发生之后才能启动线程、建立与 ZooKeeper 和 redis 的连接。将这个客户端与 Quixote + SCGI 服务进行联调时，奇怪的事情发生了，配置发生变更时，客户端并没有立刻收到 ZooKeeper 的推送，而是等到下一次用户请求到达时才会收到，起初以为是线程根本就没有在工作，后来发现，线程也并不是完全不工作，而是阻塞在了某个地方，当有用户请求到达时，线程 ...继续阅读 (27)

升级到 Lion 后一直在忍受着很大的音量，戴着入耳一格音量也觉得很大，找了两句 applescript，写成了一个符合我使用习惯的脚本，这下可以精确地把音量调整为舒适的大小了：moreAdjust volume (adjust-volume)download123456789101112131415161718#!/usr/bin/osascriptonusage()set_usageto"Usage: adjust-volume number\n"set_usageto_usage&"For example:\n"set_usageto_usage&" adjust-volume 2\t - increase volume by 2\n"set_usageto_usage&" adjust-volume -2\t - decrease volume by 2"return_usageendusageonrunargvif(countargv)<1thenreturnusage()endifsetcurrentVolumetooutputvolumeof(get volume settings)set volumeoutputvolume(currentVolume+(item1ofargv))endrun使用方法：1234Usage: adjust-volume numb ...继续阅读 (36)

升级到 Lion 后一直在忍受着很大的音量，戴着入耳一格音量也觉得很大，找了两句 applescript，写成了一个符合我使用习惯的脚本，这下可以精确地把音量调整为舒适的大小了：moreAdjust volume (adjust-volume)download123456789101112131415161718#!/usr/bin/osascriptonusage()set_usageto"Usage: adjust-volume number\n"set_usageto_usage&"For example:\n"set_usageto_usage&" adjust-volume 2\t - increase volume by 2\n"set_usageto_usage&" adjust-volume -2\t - decrease volume by 2"return_usageendusageonrunargvif(countargv)<1thenreturnusage()endifsetcurrentVolumetooutputvolumeof(get volume settings)set volumeoutputvolume(currentVolume ...继续阅读 (37)

升级到 Lion 后一直在忍受着很大的音量，戴着入耳一格音量也觉得很大，找了两句 applescript，写成了一个符合我使用习惯的脚本，这下可以精确地把音量调整为舒适的大小了：moreAdjust volume (adjust-volume)download123456789101112131415161718#!/usr/bin/osascriptonusage()set_usageto"Usage: adjust-volume number\n"set_usageto_usage&"For example:\n"set_usageto_usage&" adjust-volume 2\t - increase volume by 2\n"set_usageto_usage&" adjust-volume -2\t - decrease volume by 2"return_usageendusageonrunargvif(countargv)<1thenreturnusage()endifsetcurrentVolumetooutputvolumeof(get volume settings)set volumeoutputvolume(currentVolume ...继续阅读 (14)

在从 5.0.x 向 5.1.x 升级的过程中，使用 mysqldump 备份某张表之后，向5.1.x中导入时却遇到重复数据的错误：1ERROR 1062 (23000) at line 65: Duplicate entry '1003-' for key 'uk_cat_name'more这张表的schema是这样的：123456789CREATETABLE`tag`(`id`int(11)NOTNULLAUTO_INCREMENT,`name`varchar(255)CHARACTERSETucs2NOTNULLDEFAULT'',`count`int(11)NOTNULLDEFAULT'0',`cat_id`mediumint(8)unsignedNOTNULLDEFAULT'0',PRIMARYKEY(`id`),UNIQUEKEY`uk_cat_name`(`cat_id`,`name`),KEY`idx_cat_count`(`cat_id`,`count`))ENGINE=InnoDBAUTO_INCREMENT=2545965DEFAULTCHARSET=latin1分析 mysqldump 生成的 SQL 之后，发现数据本身并没有问题，并且向原有的 5.0.x 中导入也没有问题，那么问题应该是出在向 5.1.x 导入的过程中，但仍不明白其原因，于是去掉了 UNI ...继续阅读 (33)