数据库中间件DBLE学习(四) 学习配置wrapper.conf

前言

水，看似清澈，并非因为它不含杂质，而是在于懂得沉淀；最近越来越觉得沉淀的重要性，有时候看似走了很多弯路，浪费了一些时间和精力，觉得没什么用。可是过了一段时间兜兜转转的又回到了弯路上，这次能一眼认清迅速踏上捷径。这就侧面体现了沉淀的重要性。今天我们来学习的是Wrapper。

java service wrapper

Java开发的程序，一般有web程序，桌面级程序，还有后台服务。

• web应用现在多数都和容器打包在一起，例如tomcat。
• 桌面级应用，在Linux下面直接运行jar包。
• 后台服务，一般打成jar包。使用命令行或者脚本来调用执行。

今天我们要学的java service wrapper可以把Java程序包装成一个后台服务运行。除了这个功能之外，当JAVA程序挂掉之后，还能把服务自动拉起来，相当于一个守护进程的作用。这么做最大的好处就是，半夜服务进程出现异常宕机了，不用在去接告警电话了，它会自动重拉，可以让我们安安心心的睡个安稳觉。

当我们使用dble start之后，我们来看操作系统，默认启动了2个进程：

wrapper.png

我们可以手动把java这个进程干掉，看看会不会自动拉起来。

为了调试方便，在debug模式下存在三个可用的XA事务调试JVM参数undefined-DPREPARE_DELAY=10undefined-DCOMMIT_DELAY=10

wrapper1.png

通过观察dble的日志，我们可以发现在kill -9掉java服务进程之后，系统在几秒钟以内重新将java服务进程拉起。

上述演示的功能只是java service wrapper中的一个基本功能。对错误的检测，它还包括：

• 检测JVM是否挂起
• 检测应用程序是否死锁
• 检测应用错误
• 检测内存泄露
• 响应JVM退出代码 更多详细的内容可以参考wrapper

检测挂起Hung的原理

今天我们来说下它是如何检测Hung的。

Java Service Wrapper会定期ping JVM进程（默认情况下每5秒一次）并等待响应。如果在配置的时间段内(默认为30秒)未能响应，则wrapper确定其已经hung住。同时Wrapper还考虑了诸如整个系统负载之类的问题,以确保将误报率保持在最低水平。

我们可以将wrapper.debug = TRUE这个选项打开，打开后观察日志就可以发现ping的详细情况。

1.dble启动之后，通过操作系统命令查看，可以发现，启动了2个进程。其中一个是守护进程wrapperp。守护进程会开启一个Server Socket端口（根据配置的情况来定，我们配置的是32000）

wrapper3.png

2.而接下来就是wrapper(客户端)进程启动。JSW会在dble程序之外包装一层wrapper,wrap*

per会先启动JVM虚拟机，启动完虚拟机之后，客户端要和管理端发生socket通讯，通讯成功之后，wrapper(客户端)才会启动应用程序。

wrapper4.png

3.dble应用程序启动成功之后，管理端就会定期向客户端发送ping。客户端接收到ping的请求会返回一个包，同时告知管理端自己是ok的。

wrapper5.png

如果守护进程在一定时间内没有收到wrapper ping包的返回，守护进程就会认为客户端hung了，就会下发重启指令。

dble软件的wrapper.conf配置

dble使用wrapper进行管理，配置文件wrapper.conf里面的配置选项非常多。一般我们只是需要对JVM进行调整优化。关于JVM优化官方文档提出了建议：

1. MaxDirectMemorySize,设置最大可用直接内存。需要根据机器的情况进行计算，不然会导致服务无法正常启动。需要大于bufferPoolPageNumberbufferPoolPageSize，而这两个参数是在server.xml中配置的。undefinedbufferPoolPageNumber的默认配置是20 * 机器CPU线程数 (需要注意这里I5和I7的CPU可能会返回不同的结果)undefinedbufferPoolPageSize的默认配置是4×512×1024字节，默认是2MB 以下为官方建议值：undefineddble总内存=0.6 * 可用物理内存(刨除操作系统,驱动，其他软件的占用)undefinedXmx=0.4 * dble总内存undefinedMaxDirectMemorySize =0.6 * dble总内存undefined同样，当我们优化好了MaxDirectMemorySize后，我们也需要反过来优化server.xml中的bufferPoolPageNumber和bufferPoolPageSize。`bufferPoolPageNumber bufferPoolPageSize的结果需要小于MaxDirectMemorySize，否则就会out of memory。建议bufferPoolPageSize设置为2M，bufferPoolPageNumber设置为取整(MaxDirectMemorySize * 0.8 /bufferPoolPageSize)`
2. 为了调试方便，在debug模式下存在三个可用的XA事务调试JVM参数 -DPREPARE_DELAY=10 -DCOMMIT_DELAY=10 -DROLLBACK_DELAY = 10 当且仅当DEBUG模式下，在XA事务发生三段提交或者回滚之前会发生延迟，单位为秒 注：大部分情况下这个参数用以进行测试和本地调试。默认是没启用的。

后记

今天主要学习了wrapper的原理和一些优化配置。对于wrapper的进一步深入研究可以参考wrapper的官网。

1.Run as a Unix Daemonhttps://wrapper.tanukisoftware.com/doc/english/qna-unix-daemon.html