MP中通常会出现Partition情况如：

    在系统忙的时候，负责MP节点间通讯的管理进程Bridge，过于忙碌，而其管理的工作受到影响导致，不能通知节点间的状态，那么就会有Partition出现。

2.解决方法

    方法一：修改UBB中的参数，是Bridge管理进程被占用尽量小；

    方法二：改变当前程序部署框架，这个对我们当前Bridge占用量是非常大的；

2.1UBB优化

    建议一：设置了BRTHREADS=Y，用到了多线程Bridge, , 建议升级到135或更高补丁，或设置成N, 参看：135. Bug9759594 tux9.1 : multithread bridge hang

        建议二：客户设置了SVCTIMEOUT，秒为单位，超时时间到了会杀进程，建议不设，如果应用非要设置， 建议加大TCCB的超时，10秒太短。经常有进程被超时，会通过Bridge管理进程发送消息给其他节点。

建议三：客户设置了JSL超时 "-T 2"，时间为两分钟IDLE即杀链接，如果LICENSE够用， 建议最好不设，或按经验设置20分钟以上。

    建议四：客户的SPINCOUNT=0，针对BBL抢锁不利，建议增加到128或更多。

    建议五：客户设置了"DBBLWAIT 5"， 建议到10, 和"BBLQUERY 30"，建议扩大到120。

        建议六：客户设置了太多的MSSQ会加剧问题，建议REPLYQ都注释掉，虽然会导致MIN和MAX的自适应波动不起作用。

    建议七：彻底解决coredump问题。

2.2框架优化

    将JSL和JREPSVR部署在每个Slave机器上， 即六个APP1-6服务器上， 而不是只部署在Master和Backup上， 即"Scheduler1"��"Scheduler2"上。这时候： 

    (1) 如果路由器或防火墙能改(含F5)，即将外部对Web服务器的地址映射到这几个Slave的监听地址上；

    (2) 如果没有这个映射，只需要在Web端， 修改Jolt访问的服务器地址即可；

原因说明：目前所有请求都从Scheduler1或Scheduler2节点上转发到六个Slave上，请求处理完再转发回来，会大量占用Bridge，会影响其MP的管理工作。

这个是最好的一种方案。

路过，顶