我们公司的一些应用程序使用Geode服务，我们正在使用Geode成员组配置以及维护不同的区域。
我们一直在努力将我们的应用程序从Geode 1.6版本迁移到最新的1.12版本。
如果我们使用旧的服务器和定位器启动脚本参数，我们看到升级后的性能急剧下降，当我们删除这些参数时，一切都很好。
我们现在计划采取了解参数（早期使用的）和可用的路线，以确定服务器和定位器的最佳配置，以获得新的Geode版本的最佳效果。
我想知道是否有人有什么最佳实践或建议来完成这项任务。
以下是新旧版本的 Geode 定位器和服务器启动脚本的配置。
---旧配置 (在Geode 1.6版本中效果很好，但在Geode 1.8之后的任何版本中都不适用)
gfsh start locator --locators=$locators_str --name=${EC2_HOSTNAME}.aws.compnaynamedigital.net --initial-heap=2G --max-heap=2G --dir=/opt/compnayname/geode/locator --J=-Dlog4j.configurationFile=/opt/compnayname/geode/log4j2-locator.xml --J=-DCLUSTER=${ECS_CLUSTER} --J='-javaagent:/opt/compnayname/geode/jmxtrans-agent-1.2.6.jar=/opt/compnayname/geode/jmxtrans-agent-locator.xml' --J=-Dgemfire.distributed-system-id=${DISTRIBUTED_SYSTEM_ID} --J=-Dgemfire.member-timeout=30000 --J=-Dgemfire.max-num-reconnect-tries=0 --J=-Dgemfire.jmx-manager=true --J=-Dgemfire.jmx-manager-start=true --J=-Dgemfire.jmx-manager-port=1099 --J=-Dgemfire.http-service-port=0 --J=-Dgemfire.log-level=info --J=-Dgemfire.log-file-size-limit=10 --J=-Dgemfire.log-disk-space-limit=10 --J=-Dgemfire.disable-auto-reconnect=true
---新配置 (适用于所有版本)
gfsh start locator --locators=$locators_str --name=${EC2_HOSTNAME}.aws.compnaynamedigital.net --J=-Xmx2048m --dir=/opt/compnayname/geode/locator --J=-Dlog4j.configurationFile=/opt/compnayname/geode/log4j2-locator.xml --J='-javaagent:/opt/compnayname/geode/jmxtrans-agent-1.2.6.jar=/opt/compnayname/geode/jmxtrans-agent-locator.xml'
---旧配置 (在Geode 1.6版本中效果很好，但在Geode 1.8之后的任何版本中都不适用)
gfsh start server --locators=$locators_str --name=${EC2_HOSTNAME}.aws.compnaynamedigital.net --initial-heap=${GEODE_INIT_HEAP} --max-heap=${GEODE_MAX_HEAP} --group=${SERVER_GROUP} --dir=/opt/compnayname/geode/server --classpath=/opt/compnayname/geode/services-geode.jar --J=-Dlog4j.configurationFile=/opt/compnayname/geode/log4j2-server.xml --J=-DCLUSTER=${ECS_CLUSTER} --J='-javaagent:/opt/compnayname/geode/jmxtrans-agent-1.2.6.jar=/opt/compnayname/geode/jmxtrans-agent-server.xml' --J=-Dgemfire.distributed-system-id=${DISTRIBUTED_SYSTEM_ID} --J=-Dgemfire.member-timeout=30000 --J=-Dgemfire.max-num-reconnect-tries=0 --J=-Dgemfire.socket-buffer-size=16777215 --J=-Dgemfire.off-heap-memory-size=${GEODE_OFF_HEAP} --J=-XX:+UseParNewGC --J=-XX:+UseConcMarkSweepGC --J=-XX:CMSInitiatingOccupancyFraction=60 --eviction-heap-percentage=70 --critical-heap-percentage=90 --J=-Dgemfire.http-service-port=0 --J=-Dgemfire.log-level=info --J=-Dgemfire.log-file-size-limit=10 --J=-Dgemfire.log-disk-space-limit=10 --J=-Dgemfire.disable-auto-reconnect=true ${ADDTL_GEODE_SERVER_OPTS}
---新配置 (适用于所有版本)
gfsh start server --locators=$locators_str --name=${EC2_HOSTNAME}.aws.compnaynamedigital.net --J=-Xmx${GEODE_MAX_HEAP} --group=${SERVER_GROUP} --dir=/opt/compnayname/geode/server --classpath=/opt/compnayname/geode/services-geode.jar --J=-Dlog4j.configurationFile=/opt/compnayname/geode/log4j2-server.xml --J='-javaagent:/opt/compnayname/geode/jmxtrans-agent-1.2.6.jar=/opt/compnayname/geode/jmxtrans-agent-server.xml'
我们正在使用完全相同的环境（阅读AWS）来测试新旧配置，并执行相同的测试来测量响应时间。我们为不同的成员组使用3个Geode定位器和3个Geode服务器。
唯一的区别是Geode版本
我们其实是在做一个计数操作（我们写了一个计数函数，在Geode区域上执行，来统计下载数据中存在的记录，这其实是数据草图(https:/datasketches.apache.org。)). 在同样的测试环境下，对同样的数据进行的这个计数操作，在使用超过1.8的任何Geode版本的旧配置时，响应速度都非常慢。
另一个令人惊讶的事情是，如果我在我的本地笔记本电脑中使用旧的配置（我的笔记本电脑同时作为定位器和服务器），使用任何大于1.8的Geode版本（包括最新版本的Geode），那么我没有看到这个问题。不知何故，这些额外的配置导致了分布式基础设施中AWS环境的缓慢。
如果需要更多信息，请让我知道，我将很高兴提供更多细节。
任何有关这方面的信息都将被感激。
我看到的主要区别是包含了 --J='-javaagent:/opt/xyz/geode/jmxtrans-agent-1.2.6.jar=/opt/xyz/geode/jmxtrans-agent-server.xml' 中的启动参数。这似乎是一个第三方Java代理暴露的几个 JVM 衡量标准，通过 JMX.
你知道代理本身是否修改了字节代码吗，我在过去看到过这种方法对Geode应用程序的负面影响（虽然与性能无关）。您是否尝试过将代理升级到最新的可用版本(1.2.10)?. 顺便说一下，Geode已经通过以下方式暴露了很多指标和信息。JMX 有什么理由让你依赖另一个外部工具来完成这个任务吗？
我们已经看到升级后的性能急剧下降。
你是如何衡量性能的，你在哪里看到性能下降，你是否在完全相同的机器上执行完全相同的工作负载，其中唯一的区别是Geode版本？这里有几个角色在发挥作用。
也就是说，诊断和排除性能降低的问题是一个漫长而又复杂的过程，所以我的建议是打开一个 "性能降低 "的分析报告。Geode JIRA票务 与所有相关信息和文物。
干杯。