1、去ruby官方下载安装包，下载地址：
2、解压缩下载的ruby-1.9-stable.tar.gz安装包，进入目录。
su
#./configure -prefix=/usr/local/ruby-1.9
#make
#make install
此时可能出现的错误：
echo executable host ruby is required. use --with-baseruby option.
false ./tool/generic_erb.rb -c -o known_errors.inc
./template/known_errors.inc.tmpl ./defs/known_errors.def
executable host ruby is required. use --with-baseruby option.
make: *** [known_errors.inc] Error 1
出现此问题的原因在于1.9版本的ruby编译需要系统默认安装旧版本的ruby，而ubuntu中默认没有安装。
3、解决方法：
sudo apt-get install ruby
#默认ubuntu10.10会自行安装ruby 1.8，之后再编译1.9就没问题了。
下载1.8.7版本源码编译安装，并设置临时环境变量 ，进入1.8源码目录
su
#./configure -prefix=/usr/local/ruby-1.8
#make &&make install
export PATH=/usr/local/ruby-1.8/bin:$PATH
#此时使用ruby -v验证版本为1.8
4、在刚才安装配置ruby1.8的终端中继续重新进行1.9的编译安装，进入1.9源码目录：
#解压文件
tar vfxz ruby-1.9.1-p0.tar.gz
#进入解压后的文件夹
cd ruby-1.9.1-p0/
#编译源码,编译之前,应该先对/usr/local/ruby-1.9.1文件夹设置权限.
./configure --prefix=/usr/local/ruby-1.9.1
#大名鼎鼎的 make 和 install
make &&make install
#设置PATH路径,把安装的ruby放在系统PATH前面，避免调用操作系统自带的ruby
export PATH=/usr/local/ruby-1.9.1/bin:$PATH
#在 ~/.profile 文件中增加了这样的代码:
if [ -d "/usr/local/ruby-1.9.1/bin" ] then
PATH="/usr/local/ruby-1.9.1/bin:$PATH"
fi
然后 注销 再登陆一次.
#如无意外
ruby -v
#ruby 1.9.1p0 (2009-01-30 revision 21907) [i686-linux]
#ruby 1.9.1安装成功了.
注意：之前安装了1.8版本ruby，可以直接通过rm -rf /usr/local/ruby-1.8删除即可。
在windows下启动JBoss服务器，需要在命令行中输入run.bat。但是运行后如果你想停止服务器，可能的做法就是直接按Ctrl+C键强行终止服务器，显然这种方式是不友好的。另一种方法就是再开一个cmd窗口，进入Jboss的bin目录，然后键入shutdown.bat -S. 这样毕竟费时费力，如果能像Linux下在命令行的后面加一个&让它在后台运行，要关闭时就不用另开窗口直接输入相应的关闭命令就好了。答案就在下面：在执行的命令前加上start /b，比如start /b run.bat。就相当于Linux下的run.sh &。
最近在解决探针获取Ruby应用服务器的内存使用的情况，将解决的思路总结一下，希望对此感兴趣的伙伴一起探讨。
先对比应用服务器： Puma 和 Passenger ，下面对比这2个服务器内存统计，
单进程模式：直接获取进程id: Process.pid
cluster模式：以启动2个worker进程为例:
从上面截图可以看到，Puma启动后会出现3个进程：1个master进程和2个worker进程。
内存的使用情况(见 RSS 列):
而对于探针来说，一个探针实例是伴随进程一起启动的，也就说一个探针只能识别自己所在的进程id，那如何获取应用服务器使用的内存？我们用其中1个woker进程所在的进程组[ PGID ]看一下:(为啥不是父进程?, 见下文Passenger)
这3个进程都在相同的进程组里，而且进程组号为master的进程id，那我们就可以用这个信息获取应用服务器的所使用的内存:
4.累加进程组内进程内存和即为应用服务器使用内存:
启动Passenger后的Process信息：
对Passenger架构感兴趣的请移步到 这儿 .
查看一下worker所在进程组和父进程:
通过PPID可以看出
Passenger core —>Passenger AppPreloader —>Passenger RubyApp
三者为爷-父-子关系，当服务器请求量增大时 AppPreloader 会产生新的进程来响应请求,从而新的 RubyApp 进程的 PPID 即为 AppPreloader 的 PID ，这样看来就可以将同一个 PPID 的进程加起来得到应用服务器的内存？
由于Passenger会根据服务器的负载量动态调整进程数，当服务器请求量较小时，Passenger会kill多余的进程，会出现下面的情况：
AppPreloader 也被Passenger杀掉了。原 RubyApp 进程的 PPID 变成了1。这时如果服务器的请求量增大，应用服务器进程会成为这样：
Passenger core 产生新的 AppPreloader 进程，并且 AppPreloader 产生新的 RubyApp 进程，这时如果只用 PPID 统计应用服务器内存就会不准确，所以要统计Passenger的使用的内存还得通过累加在同一个进程组( PGID )的所有进程使用的内存和得到。
由于 Unicorn 和 Rainbows 都与Puma的cluster模式[master+worker模式]类似，内存统计的方式可以参考上文的Puma。
由于 Thin 启动多个server后没有类似的特点，上面方法不适用于Thin，有好方法的伙伴们可以告知:smile:
在解决探针统计应用服务器的内存问题上，摸索出了上面的一条路子，如果小伙伴们有其他更好的方式，可以一起探讨一下。
