Mongrel的内存占用确实成问题
December 14th, 2008
- A. 20 mongrel instances * 300MB memory limitation for each
- B. 10 mongrel instances * 512MB memory limitation for each
- with config A, total memory usage is about 6000+MBytes
- with config B, total memory usage is about 4000+MBytes
- in normal cases, the momory usage of each mongrel instance is about 400MBytes
- for operations with light calculation, config A is generally faster than config B
- for operations with heavy calculation, config B is more efficient than config A when load (amount of concurrent users) grows
- more importantly, config B performs more consistenly than config A
- config A fails 2 test cases for 15 concurrent users, and the possibility of failure grows significantly to 5.57% for 20 concurrent users
- config B doesn’t fail any test case
- the degrading curve of performance of config B is flatter than config A
- besides the memory usage, CPU usage is yet another bottle neck of performance
- 20 mongrel instances on 1 server overloads the CPUs, and thus degrades the performance
- reducing the amount of mongrel instances makes HAProxy works as a queue, therefore makes the system performs linearly
- prefer config B than A: 10 mongrel instances on each of 2 production servers can handle 20 concurrent users, which (based on my experience) effectively means at least 1000 users online AT THE SAME TIME
- try config C (15 mongrel instances * 400MB limitation for each) and D (5 or 7 mongrel instances * 512MB limitation for each), IF NECESSARY
RubyWorks近况很好，将来会更好
September 15th, 2007
经过一番调整之后，CruiseControl.rb的网站又回来了，顺便host了Ruby on Rails的持续集成。这次用了一个CentOS 5的服务器，用RubyWorks Production Stack做部署环境。自己的狗食自己吃，自己的产品自己用。在下周的RailsConf Europe 2007上，我们的CC.rb、Production Stack和JRubyWorks都会亮相。这就是我们RubyWorks团队取得的阶段性成果。
不过，当负责宣传推广的同事去参加RailsConf Europe的时候，我就已经从这个项目中roll out了。至少在可预见的将来，我的角色将从RubyWorks的核心开发者变成热心的开源参与者之一。这就是控球后卫的姿态，运球推进到前场，晃开防守找到空档，把球传给位置最好的队友让他得分，自己转身投入防守。
不过说真的，但愿很快能再进入一个Ruby项目……昨天和dreamhead聊天的时候瞎扯了一句：你知道为什么以前的程序员总是想做几年技术就转为做管理吗？因为他们用C++编程太没乐趣了。
Rails部署环境：各就位，预备，跑
August 24th, 2007
有人评论了RubyWorks Production Stack。“Damn those ThoughtWorks people are smart!” 这话听着很振奋。不过第二天，他又爱上了FiveRuns的RM-Manage。“With built in notification it’s definitely a winner”
毫无疑问，FiveRuns的RM-Install是一个好东西。完整的Rails stack，丰富的附加功能，使用简便。但试用以后却加深了我对RubyWorks的信心。因为：
- 我们的stack是在现有标准（apt和yum）基础上搭建起来的，这就意味着用户能够以他们习惯的方式安装和（更重要的）升级所有软件；一个以自定义格式包装的工具包将不得不提供自己的更新升级方式，甚至根本就无法升级。
- 我们的stack是逐步组合出来的，这就意味着我们提供的始终是对绝大多数用户最有价值的东西，并且给用户选择的机会；一个大包大揽的工具包很可能包含一些看上去很酷、但很多用户并不需要的庞大的组件（例如ImageMagick）。
- 我们的stack是开源的，这就意味着我们能够得到整个社区的反馈和贡献；一个闭源工具包的开发者需要花费更多的工夫才能弄清系统管理员们的工作方式和习惯。
归根结底，我的信心来自于对Unix传统的信心：开放的、遵循标准的、组合协作的软件，应该好过封闭的、自立山头的、大包大揽的软件。谁能在这场Rails stack的赛跑中最终获胜，走着看吧。
编程选择GEM安装版本
July 7th, 2007
rayzer留言说：
“昨天在feisty上装rubyworks的时候,到了安装fastthread一步，会编译本地gem, 并提示mkmf模块依赖关系无法满足，需要引入ruby1.8-dev来解决。”
出现这个问题的原因是，在选择gem安装版本的时候，选中了一个错误的版本：我们提供了预编译好的二进制版本，安装这个版本是不需要有GCC和头文件的；但如果选中了没有预编译的版本，就会在安装的过程中build native extension。
而选中了错误版本的原因是，RubyGems本身没有提供非交互式的安装命令。一旦需要在多个版本中选择，就必须从命令行输入。我们以前用的简单办法是：
echo "1" | gem install fastthread -y
这样做的问题是，如果已经有gem cache（看看你有没有/usr/lib/ruby/gems/1.8/source_cache这个文件），编号1的版本很可能就不是我们提供的那个，而是RubyForge的gem repository里的某一个。于是就出现了开头提到的问题。昨天看到rayzer的留言以后，我终于下定决心把这个问题解决掉……
其实也不难。用IO.popen来开启进程，一行一行读STDOUT，看到合适的选项就往STDIN输入数字：
def install_gem(name)
cmd = "gem install #{name} -y --no-rdoc --no-ri"
puts cmd
IO.popen(cmd, "r+") do |io|
io.each_line do |line|
puts "[out] #{line}"
if(line =~ /\s(\d+).*\(i[3|4]86-linux\)/)
puts "[selection] #{$1}"
io.puts $1
end
end<br /> end
end
install_gem "fastthread"这个修改将在0.0.3版本中发布。
RubyWorks迈出第二步：Production Stack on Ubuntu
June 19th, 2007
RubyWorks Production Stack今天发布0.0.2版本。
虽然只是千分位上的进展，不过也可以说是比前一个版本进步了一倍——事实也差不多正是这样：除了Redhat/CentOS以外，我们现在开始支持Debian 4 Etch和Ubuntu 7.04 Feisty Fawn。此外我们还用runit替换了monit来负责管理所有的服务器进程，从而避免了由于非正常退出而留下PID文件、导致服务无法启动的问题。monit仍然可以提供监控服务器进程的功能。
我们还全面重写了文档。Alexey和我，两个“外国人”写出的文档，文采就不敢说了，但愿对用户有所帮助就行。
下一步我们将支持x64架构的服务器，进一步加强安全性和可管理性，以及增加对Capistrano的支持。下一次的发布——如果一切顺利的话——应该在“敏捷中国”技术大会之前出来。
[转载]RubyWorks入门指南
May 20th, 2007
（抄袭Giive Chen的RubyWorks 0.0.1 Release，感谢Giive的帮助_）
如果你覺得安裝所有的 Ruby on Rails 相關套件，並且將 Production Server系統設定好是一件很麻煩的事情嗎？或許你可以試試看RubyWorks。
RubyWorks 是一個在 Red Hat Enterprise 或是 CentOS 上面的套件組合，他會幫你把所有 Production 環境下面的相關的 Ruby on Rails 套件跟 Server 套件一次安裝完成，並且提供一個馬上可以跑的 defulat config file，也就是說各位公司的技術長們不需要花時間去看那麼多 Production 設定方式，你已經有一個很堪用的 Production Ruby on Rails Server了。
So，你還有理由不玩 Ruby on Rails嗎？
我們看看怎麼安裝 RubyWorks，因為我沒有 Red Hat Enterprise Server，所以我只 Test CentOS。
前置作業
RubyWorks 因為好像還沒進去 yum 資料庫，所以我們還是得必須告訴 yum 哪裡有 RubyWorks 的 Package，如果已經進去yum repo了，就好像不需要這個動作了。
如果你像我一樣，是個不求甚解，只求可以 Work 的人，就這樣打就好了。
wget http://rubyworks.rubyforge.org/public_key.txtsudo rpm—import public_key.txtwget http://rubyworks.rubyforge.org/RubyWorks.repocp RubyWorks.repo /etc/yum.repos.d/
直接用 gem 安裝
yum install rubyworks然後…..裝好了。
Rubyworks 安裝表
RubyWorks 一共會幫你安裝
- ruby
- ruby-devel
- rubygems
- haproxy
- monit
- mongrel
- rubyworks
Rubyworks 詳細位置表
詳細的安裝位置是在
/usr/bin/ruby/：Ruby 所在地/usr/lib/ruby/：Ruby libraries/usr/lib/ruby/1.8/：Ruby standard library/usr/lib/ruby/gems/1.8/gems/：所有安裝的 Ruby gems Package/usr/bin/monit：monit 執行檔/etc/init.d/monit：monit的啟動 script，所有的 server 都會在 monit 啟動的時候，也順便幫你啟動好了（Mongrel，Haproxy）/usr/bin/haproxy：HAProxy 執行檔/usr/bin/mongrel_rails：Mongrel/etc/rails/：configuration files/var/rails/：所有 Deamon 的 .pid files/usr/rails/：Rails app code 所在地。/var/log/monit.log：Monit 的 log/var/log/haproxy.log：HAProxy log/usr/rails/log/：Mongrels and Rails 的 log
不用说（或者随便怎么说）
May 19th, 2007
今天在敏捷西安做了关于RubyWorks的演讲。在准备讲稿的时候，随便乱看，就看到了孟岩以前的一个blog：动态语言，别再说不。
“国 外的大气候和国内的小气候都有共同特点，就是站在传统技术立场上的人对于RoR的火爆看不下去了，首先站出来发难，从而引发Ruby支持者们的回击，然后 双方厮杀在一起，连带旁边相干不相干的看热闹的、拉架的、含沙射影的、慷慨激昂的，瞬间就浩浩荡荡，横无际涯了。而争论来争论去，无非还是Ruby的性能 问题、可用性问题、前景问题，等等等等。”
孟岩的态度——如果我没理解错的话——是在劝解大家，不要随便怀疑新生事物，新生事物旺盛的生命力是能够克服一切困难的，要对新生事物抱有希望。而我（现在）的态度是，我不劝说谁。不是怀疑性能问题吗？我们做出唾手可得的高性能部署环境放在这儿。不是担心跟遗留系统不方便整合吗？我们把遗留数据库和消息系统的问题都解决掉。不是没有看到成熟案例吗？我们就来做成熟案例。
既然对它有信心，那就动手把所有的怀疑都打消掉。人们怀疑什么，我们就解决什么。
至于教育大众的事情么……我很相信，我们只要教育“小众”——多半是“大众”们的老板——就行了，“小众”会帮我们教育大众的。
所以孟岩希望大众“别再说不”，我的态度是，大众随便怎么说，我无所谓。
RubyWorks 0.0.1 Released
May 16th, 2007
RubyWorks production stack is a collection of open-source software required to host a RubyOnRails application on a RedHat Enterprise Linux 4 or CentOS 4 server.
Once you point your package manager (up2date or yum) to RubyWorks repository and install the package, you have all the necessary pieces preconfigured and ready to go. Moreover, there is a skeleton Rails application up and running on the server. It’s as close as we could get to one-click production deployment with Rails.
前一阵的冲锋有了成果。在即将开幕的RailsConf 2007上，所有人都将看到我们的RubyWorks。
正如我以前说过的，Ruby和Rails已经做好了准备走向企业。在众多怀疑的部署问题（性能、伸缩性、可靠性、可管理性……）上，一个经过实践检验的部署方案已经存在，事实证明它完全能够应付所谓“企业级”的要求——不论你如何定义“企业级”这个词，因为这个部署方案各方面的能力已经证明了它自己。
唯一的问题是，HAProxy、Monit、Mongrel的配置即令不是困难的，至少也不是易如反掌的。RubyWorks的出现正是为了解决这个问题。我们提供一个“高性能”“企业级”（如果你喜欢这些大词的话）Rails部署环境所需的所有软件，以及可以立刻投入使用的缺省配置，再加上一个示例应用。所有这些都以RPM的形式发布，用yum或者up2date就可以直接安装。如果你正在开发Rails应用并且你的部署环境是Redhat/Fedora/CentOS，那么恭喜你了，因为……
高性能的Rails部署应用服务器，现在只需一分钟就可以获得。
Create RPM For Your Rails Application
April 29th, 2007
Now you can create RPM package for your Rails application fairly easily. Here are the instructions:
- Install and config rpmbuild. (You may wanna read an RPM Tutorial.)
- Install rpmpackager plugin:
ruby script/plugin install \ http://rubyworks.googlecode.com/svn/trunk/rpmpackager/
- Config rpmpackager plugin. Edit vendor/plugins/rpmpackager/config.yml as following:
configuration: # name of your application app_name: rubyworks-dogfood description: This is dogfood of RubyWorks. license: Apache version: 1.2.1 release: 1 # RPM dependencies. separated with commas dependencies: openssl, mysql >= 5.0 # gem dependencies and installation indecies # 0 for gems don't need selection gems: redcloth: 0 rcov: 1 - Create RPM package:
- rake rpm_package
- (By default the generated RPM will install your application to ”/usr/local/lib/rails-apps/#{app_name}”.)
That’s it. Package your application and throw it to deployment :>
