北京市住房与城乡建设厅网站,电脑行业网站模板,唐山市住房和城乡建设局官方网站,宁阳房产网文章目录 背景工具jconsole和jvisualvm 压测实战以太坊Java程序监控1.使用jconsole监控2.使用jvisualvm监控 问题分析堆内存使用异常通过调整内存策略来应对#xff1a; 交易虚增问题 背景 作为使用java技术栈的金融类公司#xff0c;确保Java程序在生产环境中的稳定性和性能… 文章目录 背景工具jconsole和jvisualvm 压测实战以太坊Java程序监控1.使用jconsole监控2.使用jvisualvm监控 问题分析堆内存使用异常通过调整内存策略来应对 交易虚增问题 背景 作为使用java技术栈的金融类公司确保Java程序在生产环境中的稳定性和性能至关重要。由于生产环境访问受限远程监控成为了主要的监控方式。本文将介绍如何使用一些工具来监控以太坊的Java应用程序并深入探讨技术细节。 工具 在本文中我们将主要使用两个工具jconsole 和 jvisualvm。 jconsole和jvisualvm jconsole和jvisualvm都是Java虚拟机JVM自带的监控工具无需额外安装。它们提供了丰富的功能来监控和分析Java进程的性能和健康状态。虽然它们都能胜任监控任务但它们各自具有不同的特点。 jconsole这个工具提供了图形用户界面用于监控Java进程。您可以通过特殊参数在被监控的远程Java进程启动时打开监控端口并在监控机器上打开jconsole输入相应的地址和端口以连接到远程进程。需要注意的是在某些情况下您可能需要在 /etc/hosts 中配置IP和名称的映射以解决连接问题。 jvisualvm与jconsole类似jvisualvm也提供了图形界面但它在线程查看方面更为方便线程以不同颜色进行标识使您更容易识别。如果您只关注单个Java进程的内存堆详细信息jconsole可能更适合。不过jvisualvm在某些方面更强大例如提供了Pending队列数量的直观显示。 注意jvisualvm比jconsole更强大特别是在线程查看方面。它还提供了更多的性能监控功能因此在大多数情况下jvisualvm可能是更好的选择。 压测实战 以太坊Java程序监控 在我们的案例中我们使用以太坊的Java程序作为示例该程序是一个大型Java应用程序。我们的机器资源有限4核8GB内存如何有效地监控这个高并发、高吞吐量的Java进程呢 首先让我们看一下如何使用jconsole和jvisualvm来监控这个Java进程。 1.使用jconsole监控 要使用jconsole监控远程Java进程首先需要在远程Java进程启动时加上特殊参数以打开监控端口。以下是一个示例命令 java -server -XX:NewSize3g -XX:MaxNewSize3g -XX:InitialHeapSize6g -XX:MaxHeapSize6g -XX:SurvivorRatio4 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port7979 -Dcom.sun.management.jmxremote.sslfalse -Dcom.sun.management.jmxremote.authenticatefalse -jar ethereumj-core-1.5.0-SNAPSHOT-all.jar 接下来在本地运行jconsole命令并输入远程Java进程的IP和端口例如192.168.213.49:7979。如果出现连接问题请确保您的 /etc/hosts 文件中已配置IP和名称的映射。 jvisualvm比jconsole好的地方是线程查看很方便有不同颜色标出如果只看单个进程还是jconsole的内存堆详细 如下是监控系统的拓扑图概略 一个形象的说法是此类命令讲究**“里应外合”**里应就是被监控的远程java 进程启动时带上特殊参数打开那个监控端口外合就是我监控的机器一般是我笔记本电脑开始jconsole图形解密并输入对应的地址和刚才那个端口* 2.使用jvisualvm监控 jvisualvm的使用方式与jconsole类似也分为两步。首先您需要添加服务器的IP地址然后使用“添加JMX连接”来输入端口信息。 jconsole和jvisualvm可以同时连接同一台服务器的同一个端口 不仅如此jvisualvm还具有一些优势例如提供了Pending队列数量的直观显示使您更容易分析性能数据。 总结一下jvisualvm通常更加强大并且适用于大多数监控任务。它允许您同时连接到同一台服务器的同一个端口使监控更加灵活。 问题分析 在实际监控过程中我们可能会遇到各种性能问题。让我们来分析一些可能的问题和解决方法。 堆内存使用异常 之前的pending队列是异步的模式下堆内存使用一直居高不下 恢复同步模式后经过运行内存使用量下降了cpu也恢复正常 通过调整内存策略来应对 Eden大 survivor和old小 不能8:1 因为这里的交易都是大量瞬时产生异步发出后或者记入区块后就没有用了应该消亡了 以太坊的内存图谱和我的基金资金结算交易系统的很像都是大量临时对象起来ephemeral后续不用了老年代比较小 永久代的内容还是会慢慢增加加上ethereumj本身可能的问题还是需要每日重启节点 这里的重启是指银行的业务节点可以是loadbalance下的双活重启在晚间业务低谷先重启另外一台这台负责全部流量再重启这台 交易虚增问题 春峰在压测时发现JMeter联不上后来就也用JConsole了 比起2个多月之前的测试cpu进步很大稳定在40%线程数量也保持稳定目前看内存泄露的风险不大注意测试持续了12个小时这个是首次这么长时间;而且tps有1285系统也没崩掉 但是监控到一个问题 原来一直是200多的交易每区块但是突然变成5156最大了原来到每个区块是因为Pending队列还是List的清理的时候并发错误但是一直在挖那个区块 原因 区块是有效了各节点都认可但是trytoConnect的时候清理出错结果Pending队列没有清理写入leveldb也有问题导致这个本来应该是事务的操作没有完成结果就反复出同样的块了 code: 另外一段记录在区块链研究的性能测试报告那块了