简体   繁体   中英

Maximum number of MBeans in JMX

Is there a maximum number of MBeans a JMX application can support? If there is, what is that?

Thanks in advance.

不,您仅受分配给JVM的堆的限制。

I work with a rather large application that is multi tenant. We changed our interaction with a library and we end up with several MBeans per tenant. This lead to lots of MBean registrations (tens of thousands). We observed that this starts hockey sticks pretty fast in terms of time to register a bean(at 2,000 it takes a couple of seconds). We observed a lot of thread blocking within mbean registration, specifically:

  • com.sun.jmx.mbeanserver.Repository.contains(ObjectName):461
  • com.sun.jmx.mbeanserver.Repository.addAllMatching(Map, Set, ObjectNamePattern):229
  • com.sun.jmx.mbeanserver.Repository.addMBean(DynamicMBean, ObjectName, RegistrationContext):415
  • com.sun.jmx.mbeanserver.Repository.ObjectNamePattern.matchKeys(ObjectName):190

The addAllMatching and matchKeys appear to iterate through all entries, rather than use a Map.get . The other two are lock acquires or synchronization.

We had plenty of free heap, and CPU usage was nominal (3-5%). Other parts of our application behaved normally. In short, there's contention around creating MBeans, as the number of MBeans grow, in an exponential fashion. All this was on JDK 11.

What's worse, we disabled JMX and the issue persisted. The solution involved ensuring that the library did not attempt to register mbeans through configuration.

In short: yes it becomes impractical to add MBeans after ~2000. I've not tested this on diverse environments, so individual experiences may vary.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM