JQuery 1.5.2 RC 1 发布
JQuery 1.5.2 RC 1 发布！如果没有重大缺陷发生，3月31日就将发布jQuery 1.5.2正式版了。 该版本主要是bug的修复，没有新功能发布。 详细更新日志：http://blog.jquery.com/2011/03/24/jquery-1-5-2-rc-1-released/ 下载地址：http://code.jquery.com/jquery-1.5.2rc1.js
Ruby on Rails with Nginx on CentOS 5
Ruby on Rails is a popular rapid development web framework that allows web designers and developers to implement fully featured dynamic web applications using the Ruby programming language. This guide describes the required process for deploying Ruby on Rails with Passenger and the nginx web server on CentOS 5. These instructions work with the […]
received event “button/power PWRF 00000080 00000001”
今天其中一台服務器無緣無故重啓了。問了機房的人，沒有人去操作。只有清潔工進過機房。 無耐，只好查看系統日誌。/var/log/acpid 發現以下內容。時間跟服務器重啓時間敏合。初步推薦是電源按扭被按了。 [Wed Mar 23 10:44:38 2011] received event “button/power PWRF 00000080 00000001” [Wed Mar 23 10:44:38 2011] notifying client 4187[68:68] [Wed Mar 23 10:44:38 2011] notifying client 4380[0:0] [Wed Mar 23 10:44:38 2011] executing action “/bin/ps awwux | /bin/grep gnome-power-manager | /bin/grep -qv grep || /sbin/shutdown -h now”[Wed Mar 23 10:44:38 2011] BEGIN […]
Rapid Development with Rails ( OSDC 演講）
這是我在 OSDC 2011 的前言草稿。本來是打算週六才打算放出來的，不過目前對岸正在 Twitter 上演 Rails 與 PHP 之爭（詳情請看 @robbinfan 與 @fenng 的大戰），看了手癢。 想了一下，還是把當天的這前十分鐘講稿先放出來好了… 我的主題是如何善用 Rails 特性達到 Rapid Development。這場 talk 不會有太多的 code，一些觀念上的闡釋和搭配的架構介紹會講比較多。時間是 3/26（六）的下午 2:00 在中研院 ==== 簡單自我介紹一下，我是 xdite，在 T 客邦工作。我目前的角色是 Lead Developer 與 Manager。中間是有去「出國深造」一陣子 ….不過目前回來了 XD 我寫 Rails 大約有快四年的時間，之前待過和多、PIXNET 與 HTC。 講題概念 ( 澄清關於對 Rails 的一些錯誤認知） 大概講一下這次會講這個主題的原因：Ruby on Rails 一直以來是一個非常優秀的網頁框架。應該是有始以來最棒的網頁框架，開發者不僅可以從中跟上世界頂尖開發者的研究進度，滿足自己的技術癮之外，又可以穩穩 的兼顧快速的商業需求。很可惜因為種種因素，讓世人對人一直對它停留在非常糟糕的印象（「市場上找不到開發者」且「只適合滿足技術狂人癮頭」的「效率糟 糕」「不穩定」框架）。 Rails 對於生意與開發上的幫助，絕非只有「Rapid […]
node.js调研与服务性能测试
这几天对nodejs进行了一下简单的调研 主要关注这几个方面 socket服务性能, socket客户端性能 http服务性能. 服务的稳定性与资源占用 开发成本 考虑到今后的应用场景, 实现了一个简单的memcache代理服务. 内部维护了一个50连接的简单连接池, 通过长连接与memcache服务器相连. 同时对外提供socket代理服务与http restful服务 测试环境 测试使用编译安装的node.js v0.3.1,未使用任何第三方modules 代理服务与memcache部署在不同的服务器中. 系统均为rhel 5.2, cpu: AMD Opteron 2200, mem: 4g 测试用例 通过此代理程序, 分别使用memcached协议与http协议从memcache服务中取出一个长度为100bytes的值, 并检查最终输出是否正确 压力工具 socket: 由于没有找到合适的socket压力工具.用node.js实现了一个简单的socket压力工具 http: siege 2.70 测试结论 服务启动与空载资源占用 程序启动20秒后,系统资源占用达到稳定状态, 内存消耗13m, 堆尺寸8m 由堆使用变化可知v8每隔7~8秒会进行一次gc操作 100并发100秒socket长连接压力 压力启动后内存占用迅速提高至30m, v8堆也基本维持在22m的水平, 使用率在20%到50%之间波动 此时v8的gc操作频率降低到约20秒一次. qps曲线比较平稳,在16700左右波动,幅度在400左右,v8的gc操作对性能没有明显影响 压力过程中cpu占用基本维持在95%左右,处于满载状态. 另, 测试结束后20秒左右, 所占用资源被释放,内存与v8堆均回复至空载水平. 250并发100秒http长连接压力 与socket相比, http消耗的系统资源约多出30%,且8v的gc操作也要更频繁 qps值为4392, […]
让代码取代你的配置文件吧
最近, 在编写一个专门压测NameNode的工具(以下简称s4nn), 它有两个难点 : s4nn需要可以模拟上万个DataNode ; s4nn 需要灵活的支持对NameNode访问行为的定义. 后者导致了本文的思考. 命令行参数和配置文件是最常用来配置系统的方法, 前者用于配置项较少, 后者则适合配置复杂情况. 这两种方式都有共同令人痛苦的地方: 编写代码去载入->解析->转换, 通常如同处理协议般无聊(要是有个什么变更, KMN!!); 对于复杂的配置文件编写而言, 总是没有顺手的编辑器支持, 写起来既累又易错. 要是用代码取代配置文件呢? 呃… 这会很麻烦吧, 像java这样的改了代码那还不要重新编译啊? 嗯, 确实, 但并没有想象中那么麻烦, 一些技巧可以让它变得简单(至少java是这样), 如Btrace. 用代码取代独立的配置文件不是新鲜的做法, 像Guice, Gant 等已经以Internal DSL的代码代替了XML. 好处很明显: 良好的DSL风格, 简洁易懂 ; 免去对配置文件的解析转换 ; 最好的编辑器支持, 语法高亮, 一键格式化, 提示补全, 重构 ; 编译器帮助查错; 与代码无缝结合, 能够容易在变化中保持一致性. 简言之两个字, “高效”! 这倒是挺适合s4nn的, 不妨一试! 从需求的角度出发, 配置应该能够完成: 定义一组Client RPC调用行为, […]
bash下利用trap捕捉信号
我在之前的文章里写了myisam读数据压缩的情况，最近决定把它用在生产环境上，所以避免不了写一个“安全”的处理脚本放在DB服务器上，这就引入了本文所讨论的话题。 我希望这个bash脚本在退出的时候做一些事情，包括： 它启动的切到后台的job需要被杀死； 一些临时文件的清理。 在这个脚本里我用到了trap这个命令，关于它，你可以man一下，我这里就不啰嗦了。直接上示例代码： $ cat test_trap.sh declare -i run_terminate=0 trap “run_terminate=1” SIGINT SIGTERM # 启动io监控，IO较大时不进行压缩 vmstat 1 >> ./a.log & while [ ${run_terminate} -eq 0 ] do # 核心代码 sleep 30 done for pid in $(ps -ef | awk -v p=${$} ‘{if ($3 == p){print $2}}’) do kill -9 ${pid} > /dev/null done […]
mysql数据压缩性能对比（二）
在上一篇文章中，我们用生产环境的真实数据与真实SQL测试了archive和myisampack两种方式下的性能对比情况。我们得到一个对这个测试case有效的结论，那就是在240万数据量的情况下，采用archive引擎将使得某些查询慢得无法忍受! 那么，原因是什么呢? 我们知道，mysql提供archive这种存储引擎是为了降低磁盘开销，但还有一个前提，那就是被归档的数据不需要或者很少被在线查询，偶尔的查询慢一些也是没关系的。鉴于上述原因，archive表是不允许建立自增列之外的索引的。 有了这个共识，我们拿一条测试SQL来分析一下不用索引前后的查询性能差别为什么这么大。在我们的测试SQL中有这么一条： SELECT c1,c2,…,cn FROM mysqlslap.rpt_topranks_v3 WHERE … AND partition_by1 = ‘50008090’ ORDER BY added_quantity3 DESC LIMIT 500 我们前边说过，测试的这个表在partition_by1这个字段上建立了索引，那么，我们初步判断在基准表和myisampack表上，这个查询应该用到了partition_by1的索引；EXPLAIN一下： mysql> EXPLAIN -> SELECT … FROM mysqlslap.rpt_topranks_v3 -> WHERE … AND partition_by1 = ‘50008090’ -> ORDER BY added_quantity3 DESC -> LIMIT 500\G *************************** 1. ROW *************************** id: 1 select_type: SIMPLE TABLE: rpt_topranks_v3 TYPE: REF […]
mysql的数据压缩性能对比（一）
数据魔方需要的数据，一旦写入就很少或者根本不会更新。这种数据非常适合压缩以降低磁盘占用。MySQL本身提供了两种压缩方式——archive引擎以及针对MyISAM引擎的myisampack方式。今天对这两种方式分别进行了测试，对比了二者在磁盘占用以及查询性能方面各自的优劣。至于为什么做这个，你们应该懂的，我后文还会介绍。且看正文： 1. 测试环境： 软硬件 一台 64位 2.6.18-92 内核Linux开发机，4G内存，4个2800Mhz Dual-Core AMD Opteron(tm) Processor 2220 CPU。 MySQL放在一块7200转SAT硬盘，未做raid； MySQL未做任何优化，关闭了query cache，目的在于避免query cache对测试结果造成干扰。 表结构 2424753条记录，生产环境某一个分片的实际数据； 分别建立了(partition_by1,idx_rank) 和 (partition_by1,chg_idx)的联合索引，其中partition_by1为32长度的varchar类型，用于检索；其余两个字段均为浮点数，多用于排序； autokid作为子增列，充当PRIMARY KEY，仅作为数据装载时原子性保证用，无实际意义。 2. 测试目的： 压缩空间对比 压缩率越大，占用的磁盘空间越小，直接降低数据的存储成本； 查询性能对比 压缩后查询性能不应该有显著降低。Archive是不支持索引的，因此性能降低是必然的，那么我们也应该心里有个谱，到底降低了多少，能不能接受。 3. 测试工具： mysqlslap 官方的工具当然是不二之选。关于mysqlslap的介绍请参考 官方文档。 测试query 截取生产环境访问topranks_v3表的实际SQL共9973条，从中抽取访问量较大的7条，并发50，重复执行10次。命令如下： ./mysqlslap –defaults-file=../etc/my.cnf -u**** -p**** -c50 -i10 -q ../t.sql –debug-info 4.测试结论 比较项 磁盘空间 耗时（秒） CPU Idle LOAD 并发 基准表（MyISAM） 403956004 […]
nginx+resin 使用中文域名解决方案。
xxx中文域名.中国 这样的域名在resin下会出错： [15:34:31.628] {hmux-127.0.0.1:6801-5} java.lang.StringIndexOutOfBoundsException: String index out of range: 9[15:34:31.628] {hmux-127.0.0.1:6801-5} at java.lang.String.charAt(String.java:687)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.server.host.DomainName.decode(DomainName.java:205)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.server.host.DomainName.fromAscii(DomainName.java:86)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.server.host.HostContainer.buildInvocation(HostContainer.java:305)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.server.cluster.Server.buildInvocation(Server.java:915)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.server.dispatch.DispatchServer.buildInvocation(DispatchServer.java:209)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:427)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.server.port.TcpConnection.run(TcpConnection.java:603)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)[15:34:31.628] {hmux-127.0.0.1:6801-5} at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)[15:34:31.628] {hmux-127.0.0.1:6801-5} at java.lang.Thread.run(Thread.java:619)[15:34:31.628] {hmux-127.0.0.1:6801-5} java.lang.RuntimeException: java.lang.StringIndexOutOfBoundsException: String index out of range: 9[15:34:31.628] {hmux-127.0.0.1:6801-5} at […]