负载均衡不能盲目求多

        我们的一个业务之前一直是由一个tomcat再运行，基本上没什么架构可谈，简单的client----tomcat----oracle这样的一个顺序。知道有一天，我们的tomcat频繁的down服务，用netstat命令查看链接数处于ESTABLISHED状态的有1000~2000个！好吧！我这里吐槽一下，我来这里之前这里的16G内存的Linux服务器居然用的是32位的OS！！

        我调过了tomcat和JVM的基本设置，但是受限于32位OS的内存和句柄限制，对于业务也没有什么明显的缓解，于是开始着手搭建负载均衡。

        一上来由于没有其它的服务器能够立刻上线，又因为32位的操作系统浪费了大量的内存，所以我就用了一个奇葩的单机多实例- -（请不要学我，这里对于单点故障完全没有任何益处）我在服务器上同时运行了4个tomcat和1个负载均衡的程序，这里我试验过varnish、nginx和现在正在使用的haproxy。

        一开始虽然运行了4个tomcat但是OS的限制依旧很明显，但是处理队列的增加明显的减少了运行队列的等待情况，链接数也有原来的6000+变到了2000附近，处于ESTABLISHED状态的链接更是减少到了400附近。

        就这样又平稳的运行了一个多月，终于新的服务器到位了，OS也换成了64位的了。于是我把之前的4个tomcat迁移到了新的服务器上，于是乎新的问题出现了。由于新服务器（应该和64位的OS有关系）处理能力的提升，虽然处理速度变快了，但是后面的数据库却出现了明显的压力。

        通过观察和测试，平均我每启动一个tomcat，数据库服务器的负载压力立刻就会提升10（load average），用vmstat命令看R的增长也在10左右。于是原来的4个tomcat直接就把负载在10以内的数据库服务器压到了40，这还是非高峰期！

        鉴于这种情况再DBA的协助调整下，一方面对于数据库做了些优化，但是效果不明显，所以我把tomcat的数量削减到了2个，就这样到现在运行了1周的时间里面访问速度不但比之前的4个tomcat负载还要好，服务器也几乎没有出现过程序故障（这里再吐槽一下DELL R710的网卡驱动太和谐了）。

        到这里这个问题也就基本上解决了，负载均衡虽然可以增加处理队列，增加对请求的处理速度，但是再搭建的同时也要考虑一下应用对数据库的负载压力。只有找到一个良好的平衡点才能让业务运行又快又平稳！