blocks|key|2064791|text|JMX只是一个套接字，它等待连接，并允许外部进程访问收集的数据。这样做的代价通常很低(当然，除非您用请求攻击JMX服务器)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2064792|JMX允许您深入了解Java+VM的内部结构。有一些命令可以运行和关闭GC。也就是说，JMX提供了一种使用公钥和身份验证的安全连接模式。有关详细信息，请阅读文档。|2064793|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

JMX is just a socket which waits for connections and allows external processes to access data which is collected anyway. Do the penalty is usually very low (unless you hammer the JMX server with requests, of course).

JMX allows you to get at the guts of your Java VM. There are commands to run a GC and to shut it down. That said, JMX offers a secure connection mode which uses public keys and authentication. Please read the docs for details.

blocks|key|1850824|text|这取决于JMX实现和您想要监控的东西的成本。我现在至少有一个JMX应用程序，它具有相对较高的内存开销。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1850825|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

it depends on the JMX implementation and on how expensive the stuff is you want to monitor. 
I now at least one JMX application, which has a relatively high memory overhead.

blocks|key|2064905|text|您可以通过使用安全身份验证来消除安全缺陷。只需保持JMX服务准备就绪并不会产生任何显著的开销，通常是个好主意。关于这一点，有一个基准here。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2064906|entityMap|0|LINK|mutability|MUTABLE|url|http://weblogs.java.net/blog/emcmanus/archive/2006/07/how_much_does_i.html^0|1U|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You can cross out security flaws by using secure authentication. Just keeping the JMX service ready does not incur any significant overhead and is generally a good idea. There's a benchmark <a href="http://weblogs.java.net/blog/emcmanus/archive/2006/07/how_much_does_i.html" rel="noreferrer">here</a> about this.

blocks|key|1850879|text|我们在生产服务器中使用了lambda探针，我们没有看到任何明显的开销。我可以推荐probe作为可用于生产的可靠产品(Tomcats5.5和6.0，JDK5和JDK6)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1850880|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

We are using lambda probe in production servers and we didn't see any significant overheads. I can recommend probe as reliable product ready for production using (Tomcats 5.5 and 6.0, JDK 5 and JDK 6).

blocks|key|1850901|text|JMX的开销很低，您可以通过使用SSL和身份验证来修复安全性。设置-Dcom.sun.management.jmxremote.ssl=true和-Dcom.sun.management.jmxremote.authenticate=true|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1850902|有关设置证书等的更多信息，请参阅here的此处。|offset|length|1850903|当你开始插装代码时，开销就成了一个问题。开销可能会很大，而且插装可能会影响应用程序的行为。你不会看到你得到了什么，即所谓的heisenberg+effect。|1850904|如果你想要低开销，我会使用JRockit自带的工具。它们利用JVM一直收集的信息。JVM保存哪些方法运行得最多的统计信息，以决定应该优化哪些方法。JVM还跟踪内存使用情况/模式，以决定选择哪个gc-stategy。JRockit将这种类型的数据公开给JRockit工具，而不会增加通常从单独的JMVTI-agent获得的检测开销。|1850905|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html|1|http://en.wikipedia.org/wiki/Uncertainty_principle|2|http://www.oracle.com/technology/products/jrockit/missioncontrol/index.html|3|http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/index.html^0|0|G|4|0|0|1P|H|1|0|D|7|2|42|5|3|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@$D|13|E|14|1|15]]|A|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@$D|17|E|18|1|19]|$D|1A|E|1B|1|1C]]|A|$]]|$1|J|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|U]]|V|$5|M|N|O|A|$P|W]]]]

The overhead from JMX is low and you can fix the security by úsing SSL and authentication. Set -Dcom.sun.management.jmxremote.ssl=true and -Dcom.sun.management.jmxremote.authenticate=true

See here for <a href="http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html" rel="noreferrer">here</a> for more information about setting up certificates etc. 

The overhead becomes a problem when you start to instrument the code. The overhead can be substantial and the instrumentation might affect the behaviour of your application. You will not see what you get, the so called <a href="http://en.wikipedia.org/wiki/Uncertainty_principle" rel="noreferrer">heisenberg effect</a>. 

If you want low overhead I would use the tools that come with <a href="http://www.oracle.com/technology/products/jrockit/missioncontrol/index.html" rel="noreferrer">JRockit</a>. They piggyback on the information the JVM collects all the time. The JVM keeps statistics of which methods are the running the most to decide which methods it should optimize. The JVM also keeps track of memory usage/patterns to decide which gc-stategy to select. JRockit exposes that kind data to the JRockit tools without adding the instrumentation overhead you normally would get from a separate <a href="http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/index.html" rel="noreferrer">JMVTI</a>-agent.

We are experiencing some slowdowns on our web-app deployed on a Tomcat 5.5.17 running on a Sun VM 1.5.0_06-b05 and our hosting company doesn't gives enough data to find the problem.

We are considering installing <a href="http://www.lambdaprobe.org" rel="noreferrer">lambda probe</a> on the production server but it requires to enable JMX (com.sun.management.jmxremote) in order to obtain memory and CPU statistics.

Does enabling JMX incur a serious performance penalty?

If we enable JMX, are we opening any security flaw? Do I need to setup secure authentication if we are only enabling local access to JMX?

Is anyone using the same (tomcat + lambda probe) without problems on production?

<h3>UPDATE</h3>

Looking at the answers it seems that enabling JMX alone doesn't incur significant overhead to the VM. The extra work may come if the monitoring application attached to the VM, be it JConsole, lambda probe or any other, is polling with excessive dedication.

Is a good idea to enable jmx (lambda probe) on a production server?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我们的web应用程序部署在运行在Sun VM 1.5.0_06-b05上的Tomcat 5.5.17上，并且我们的托管公司没有提供足够的数据来发现问题。我们正在考虑在生产服务器上安装，但它需要启用JMX (com.sun.management.jmxremote)才能获得内存和CPU统计信息。启用JMX会导致严重的性能...

问在生产服务器上启用jmx (lambda探测)是个好主意吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在生产服务器上启用jmx (lambda探测)是个好主意吗？EN