各类工具的性能分析都能看到我楼上说的这篇论文中提到的解决问题的思路，Oracle 的自带的性能分析工具自然不必说；Openresty 作者经常会发的火焰图也是一个例子；Percona Toolkit 里面的pt-query-digest出来的结果也是这种思路；甚至于最简单的strace工具加上-c的参数也会做一个花费时间从高到低的统计结果给你。大家可以先看下上面提到的论文，然后在看下我上面提到的这几个工具，自己去试用一下，然后你就知道我在说什么了。

下面给个strace -cp <pid>做 nginx 分析的输出给大家感受下：

~# strace -cp 1926
Process 1926 attached - interrupt to quit
^CProcess 1926 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 89.10    0.000711           0      2989           epoll_wait
  5.89    0.000047           0       802           close
  2.63    0.000021           0       552           writev
  1.38    0.000011           0      3014      1305 read
  1.00    0.000008           0      2203           epoll_ctl
  0.00    0.000000           0      2036           write
  0.00    0.000000           0       100         2 open
  0.00    0.000000           0         6           stat
  0.00    0.000000           0        98           fstat
  0.00    0.000000           0         3           mmap
  0.00    0.000000           0         3           munmap
  0.00    0.000000           0       394           ioctl
  0.00    0.000000           0        65           pread
  0.00    0.000000           0       414           readv
  0.00    0.000000           0        12           sendfile
  0.00    0.000000           0       394           socket
  0.00    0.000000           0       394       394 connect
  0.00    0.000000           0       829        21 recvfrom
  0.00    0.000000           0         1           shutdown
  0.00    0.000000           0       272           setsockopt
  0.00    0.000000           0       397           getsockopt
  0.00    0.000000           0      2989           gettimeofday
  0.00    0.000000           0         1         1 futex
  0.00    0.000000           0       298           accept4
------ ----------- ----------- --------- --------- ----------------
100.00    0.000798                 18266      1723 total

我看了半天也没找到有价值的信息

同意这句话，要解决性能问题，首先要做的就是找到性能瓶颈，然后针对瓶颈的地方进行分析，看看这个瓶颈的问题是否可以解决，而不是在这里猜测是不是没有用连接池？还是 rails 性能差？或者服务器的问题等等。找瓶颈的思路也不难，对于程序级别就是埋点分析每一步的执行时间，看看哪一步占的时间长。

请大家研究性能问题之前一定好好的读几遍性能分析的圣经级别的论文《Thinking Clearly about Performance》，由 Oracle 大牛 Cary Millsap 在 10 年左右写的通俗易懂的关于分析性能问题思路的。相信我，看完这论文之后肯定对于性能分析有一个更清晰的思路和认知。

楼主这是先在前面使劲的刨一个大坑，然后纵身往下一跃……

不得不赞一个

很遗憾看到 imax.im 关了，我年初也有尝试类似项目想法，研究的过程中发现了 imax.im 已经把我想做的事情都做了，然后就放弃了。尽管项目停了，不知道@huacnlee 同学能不能分享下运营 imax.im 的经验，让大家学习下。

数据库都设计有数据缓存的机制，倾向是你给多少内存就用多少的，所以不能单以占用内存大小来判断是否正常。

根据个人经验来说抽筋的原因其实很简单：运动太少了。解决方法就是经常锻炼就好了。

多年以前第一次徒步 10KM 的时候脚抽筋到要死掉的感觉，那会儿游泳半小时必抽筋。当时各种找抽筋原因，补钙啊，运动前热身什么的，没用。后来坚持运动，现在跑步 10KM 很轻松，游泳也不再抽筋。

当然运动之前拉伸一下能更好的防止运动受伤。

---补充一下---- 大部分抽筋实际上是人体对于超出自己舒适范围的运动的正常反应，告诉你该休息了。比如说一个人经常跑 5KM，那他的运动舒适区可能会在 5~10KM 之间，如果猛然去跑 20KM 的时候也会抽筋的。所以一般在进行远远超出舒适区的运动的时候都要逐步训练提高运动量，比如说对于经常跑 10KM 的人来说如果要跑马拉松的话那他必须要从 2~3 个月前开始逐步提高每次的跑量，最后必须在马拉松跑前几周内跑一次 35KM 左右的训练这样在跑马拉松的时候脚才不容易抽筋。

jQuery 只是一个库而已，只能让你简化一些操作，即使是在使用了 jQuery 的情况下会 js 也是必须的，严格来说写 Chrome 插件和做网页写 js 是不会有太大的差别的，只是在写 Chrome 插件的时候需要遵循一些特定的规则和使用一些特定的 api 接口。 现在 Chrome 商店里面看到的插件基本都用到了 jQuery，因为这东西能让工作变得简单很多。 正确的方法是按照你的需求去学，在写插件的过程中如果 jQuery 能解决的用 jQuery 解决，如果不行则自己用 js 解决，没有必要把 js 的东西都仔细学一遍，也没有必要吧 jQuery 的东西都仔细学一遍。 在实践中学习。

这……

显然是个推广贴。。。

感谢楼上回复。

看来问题的关键还是在于 application.css 里面的require_tree .，这东西会造成 stylesheets 里面的各种 css 重复加载，从而导致错误的产生。

在这里找到一个说明Customizing Twitter Bootstrap On Rails 3

#1 楼 @yesmeck 感谢你提供的代码，试了一下关键不是 import 两个文件的位置，而是需要在 bootswatch.less 中增加

@import "twitter/bootstrap/bootstrap";
@import "variables";

不过我还是不明白这些东西的处理顺序是什么，为什么要这么加。

#227 楼 @lgn21st 原来是这样，明白了。

#225 楼 @lgn21st 楼层太多了看不过来啊，@lgn21st 同学要是能要到更多的邀请码那就再好不过了。

求 SAE Ruby 邀请码一个 ****** # ***.*** 非常感谢！

这个要支持，做项目是最好的学习方法。同时我觉得考虑到新手比较多，除了老手带新手这种方法之外还可以有新手之间的相互交流，类似专题这种方式，就是同样是新手的某人在某一方面（比如说异常处理）做比较深入的研究，然后将研究的结果分享出来，这样别人就可以节省些学习的时间。同时老手在这当中帮忙把握方向之类的。