Patent Application
20060143595
This disclosure relates generally to virtual machines, and in particular but not exclusively, relates to monitoring java virtual machines.
Enterprise software has transformed the way diverse enterprises, large and small a like, transact and manage day-to-day operations. Businesses use enterprise software (e.g., web based application servers) to control production planning, purchasing and logistics, warehouse management and inventory management, production, vendor management, customer service, finance, personnel management, and other basic business activities. As the enterprise software industry continues to mature, the various application and hardware resources enlisted to facilitate this diverse set of tasks are being amalgamated into robust, highly integrated solutions (e.g., SAP NetWeaver, SAP xAPPs, mySAP Business Suite, etc.).
To integrate diverse hardware and software resources, developers of enterprise software have leveraged cross platform engines capable of minimizing or even severing platform dependencies from the enterprise solution. The Java 2 Platform, Enterprise Edition™ (“J2EE”) (e.g., J2EE Specification, Version 1.4) is a Java based solution supported by the Java Virtual Machine (“JVM”) engine. J2EE simplifies application development and decreases the need for programming and programmer training by creating standardized and reusable modular components. The popularity of Java based solutions is evident as the Information Technology (“IT”) world has gravitated to the Java language.
As enterprise software is woven into the fabric of modern business, failure of an enterprise solution may no longer be a mere nuisance, but has the potential to wreak catastrophic havoc on a business. As such, robust, reliable software is evermore critical. The enterprise software industry is marching toward the ultimate goal of self-healing software capable of sustainable, uninterrupted operation, without human intervention. In pursuit of this goal, IT technicians can benefit from convenient tools capable of monitoring the health of their enterprise software. With appropriate monitoring tools, IT technicians can take appropriate action in a timely manner to ensure a healthful state of their software or to spot delinquent applications and prevent repeat offenders. Currently, JVMs do not provide adequate tools to monitor their internal operation on a real-time basis.
A system and method to monitor a virtual machine (“VM”) is described. The VM executes one or more applications. During executing of the one or more applications, local objects are created and stored within an internal heap maintained by the VM. Status data of the internal heap is published to monitoring memory external to the VM. In one embodiment, the VM is a Java VM (“JVM”).
When memory of the internal heap becomes scarce, one or more of the local objects may be garbage collected. Garbage collecting data can be copied into the monitoring memory, as one type of the status data.
In one embodiment, multiple JVMs may each execute one or more Java applications. Shared objects created during execution of these Java applications may be stored into a shared heap that is maintained external to the multiple JVMs. Shared status data regarding the shared heap may also be copied into the monitoring memory.
In an embodiment with multiple JVMs, shared classes may be loaded during execution of the Java applications and stored within the shared heap. These shared classes may be used to instantiate the shared objects.
In one embodiment, the status data stored in the monitoring memory may be retrieved in response to receiving a status query, and the status data transmitted to a monitoring console to display the status data.
Embodiments of the invention may include all or some of the above described features. The above features can be implemented using a computer program, a method, a system or apparatus, or any combination of computer programs, methods, or systems. These and other details of one or more embodiments of the invention are set forth in the accompanying drawings and in the description below.
Non-limiting and non-exhaustive embodiments of the invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
Embodiments of a system and method for monitoring java virtual machines (“JVMs”) using shared monitoring memory are described herein. In the following description numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the techniques described herein can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring certain aspects.
Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Collectively, Java applications 125 may provide the logic for implementing various sub-layers (e.g., business layer, integration layer, presentation layer, etc.) of AS instance 115. In one embodiment, AS instance 115 is a web application server, such as Web AS by SAP, .NET by Microsoft, or the like. It should be appreciated that various components of AS instance 115 have been excluded from
In one embodiment, Java applications 125 include compiled bytecode to be verified and interpreted by JVMs 105. For example, Java applications 125 may be servlets providing server-side logic to generate graphical user interfaces (“GUIs”) on remote clients and may further include JavaServer Page (“JSP”) extensions for providing dynamic content within the GUI. Java applications 125 may include business applications providing the business logic of an Enterprise JavaBean (“EJB”), applets providing client side logic, and the like.
During execution of Java applications 125, Java worker nodes 105 publish status data 130 to shared monitoring memory 135. Status data 130 includes operational health data of the internal workings of JVMs 120. This operational health data may include statistical data detailing heap utilization, garbage collecting activity, and the like. Once status data 130 is published to shared monitoring memory 135, monitoring console 110 can query shared monitoring memory 135 to display status data 130 for review by an Information Technology (“IT”) technician. Monitoring console 110 may be located locally on the same hardware machine executing AS instance 115, or advantageously, executed on a remote machine coupled to a network. Monitoring console 110 may further monitor an entire cluster of AS instances 115, all from a single remote machine.
The components of software environment 200 interact as follows. In one embodiment, web service interface 215 is loaded first. Web service interface 215 provides interface capabilities for the components of software environment 200 to communicate across an attached network. In one embodiment, web service interface 215 can be launched remotely from a command console. In a Java 2 Platform, Enterprise Edition (“J2EE”) environment, web service interface 215 is known as the WebService Based Start Service.
Once loaded and operating, web service interface 215 launches JVM control unit 220. In turn, JVM control unit 220 reserves and allocates memory to establish shared monitoring memory 135. Subsequently, JVM control unit 220 launches each native runtime process 205 to provide the runtime environments for JVMs 120. JVM control unit 220 is responsible for the life cycles of each native runtime process 205. JVM control unit 220 can launch a new native runtime process 205, terminate an existing native runtime process 205 at an end of its useful life cycle, or restart a hung, or otherwise problematic, native runtime process 205.
In one embodiment, web service interface 215, JVM control unit 220, and native runtime processes 205 are operating system (“OS”) runtime processes managed by the OS runtime environment. In one embodiment, web service interface 215, JVM control unit 220, and native runtime processes 205 are native machine code, such as compiled C++.
Upon commencement of a new native runtime process 205, the new native runtime process 205 will establish a new JVM 120 therein. During operation, each Java worker node 105 is assigned user requests by a dispatcher (not illustrated), services user sessions, and executes/interprets Java applications 125 on JVMs 120. Each JVM 120 establishes an internal heap 225 as a pre-reserved memory pool for future use by Java applications 125 as they are loaded. Internal heaps 225 are managed by each JVM 120 allocating and deallocating memory as is required by Java applications 125.
Java applications 125 include objects and classes. Objects and classes that are local or private only to a particular Java worker node 105 and not shared with other Java worker nodes 105 within AS instance 115 are called local classes 230 and local objects 235. When Java applications 125 are loaded and executed by JVM 120, local classes 230 and local objects 235 are stored within internal heaps 225 for use by Java applications 125 running on a single JVM 120. Classes include methods that perform tasks and return information when they complete those tasks. Objects are essentially reusable software components that model pieces of software programs in terms of properties and behaviors. Classes are used to instantiate an object with these properties and behaviors. In other words, local objects 235 inherit their properties and behaviors from the particular local class 230 used to instantiate (e.g., create) the particular local object 235.
As Java applications 125 consume internal heaps 225 by filling them with local classes 230 and local objects 235, memory within internal heaps 225 available to accept new local classes or new local objects may become scarce. As such, each JVM 120 includes a garbage collector 240 to implement a disciplined procedure for returning consumed resources back to the particular internal heap 225. In one embodiment, garbage collector 240 is a thread automatically executed by JVM 120 to reclaim dynamically allocated memory without explicit instructions to do so by the programmer of Java applications 125. When there are no more references to a local object 235 within internal heap 225, the particular local object 235 is marked for garbage collection. The memory consumed by the marked local object 235 is then reclaimed when garbage collector 240 executes. Performing regular garbage collection when available memory within internal heap 225 becomes scarce helps avoid resource leaks.
However, when available memory within internal heap 225 becomes scarce, performance of the particular Java worker node 105 suffers due to the garbage collecting activities. In practice, if internal heap 225 exceeds 80% capacity, garbage collecting activities of garbage collector 240 may result in the productive computing output of the particular Java worker node 105 grinding to a near halt. Although garbage collector 240 is relatively good at deleting unreferenced local objects 235 to reclaim consumed memory, not all idle local objects 235 are reclaimed for a variety of reasons. As such, the older a particular Java worker node 105 happens to be, the more likely that Java worker node 105 is to suffer from chronic garbage collecting activity.
Not all objects utilized by Java applications 125 are local to the particular Java worker node 105. In one embodiment, shared heap 210 stores shared classes 250 and shared objects 255 utilized by Java applications 125 executing on multiple Java worker nodes 105. Shared heap 210 is a memory pool external to JVMs 120 and accessible by Java applications 125 executing on multiple JVMs 120. In this embodiment, the first Java application 125 to instantiate and use a shared object 255, places the new shared object 255 into shared heap 210. Subsequently, other Java worker nodes 105 and Java applications 125 can use the shared object 255 without expensing time and computing resources to create the particular shared object 255. Sharing classes and objects within shared heap 210 not only saves computing time that would otherwise be consumed to create the same object multiple times, it also conserves available memory within internal heaps 225, since a single instance of a shared object 255 can replace multiple instances of the very same local object within multiple internal heaps 225.
The processes explained below are described in terms of computer software and hardware. The techniques described may constitute machine-executable instructions embodied within a machine (e.g., computer) readable medium, that when executed by a machine will cause the machine to perform the operations described. Additionally, the processes may be embodied within hardware, such as an application specific integrated circuit (“ASIC”) or the like. The order in which some or all of the process blocks appear in each process should not be deemed limiting. Rather, one of ordinary skill in the art having the benefit of the present disclosure will understand that some of the process blocks may be executed in a variety of orders not illustrated.
During operating of Java applications 125, shared monitoring memory 135 is updated with status data 130. Status data 130 may include a variety of information to monitor the internal workings of each JVM 120 in real-time (e.g., heap utilization statistics, garbage collecting statistics, etc.).
In a process block 315, a virtual machine (“VM”) monitor 260 updates shared monitoring memory 135 with heap utilization data. In the illustrated embodiment, VM monitor 260 is a sub-component of native runtime process 205. As such, in the illustrated embodiment, VM monitor 260 is external to JVM 120 and not executed/interpreted thereon. To gain access to the internal structures of JVM 120, a native application programming interface (“API”) 265 is provided by native runtime process 205. In one embodiment, native API 265 includes functions that can retrieve data from within JVM 120, such as from internal heap 225. VM monitor 260 calls the functions of native API 265, which return the requested data. In one embodiment, the functions may return utilization statistics of internal heap 225 (e.g., “hit rate” of various local objects, number of local objects, amount of internal heap consumed, available memory within internal heap, etc.). In response, VM monitor 260 copies/publishes the heap utilization data into shared monitoring memory 135. In one embodiment, VM monitor 260 may format/organize the heap utilization data prior to publishing it into shared monitoring memory 135. In one embodiment, VM monitor 260 updates shared monitoring memory 135 on a periodic basis (e.g., every 5 seconds or so).
As discussed above, during execution of Java applications 125, available memory within internal heap 225 may become scarce. If internal heap 225 approaches capacity (decision block 320), then process 300 continues to a process block 325. In process block 325, garbage collector 240 performs automatic garbage collection to delete unreferenced local objects 235 and reclaim the consumed memory within internal heap 225.
In a process block 330, shared monitoring memory 135 is updated with garbage collecting data in response to the garbage collection event in process block 325. In one embodiment, a callback function of native API 265 updates shared monitoring memory 135 with the garbage collection status data. Whenever a garbage collecting event occurs, JVM 120 invokes the callback function, which in turn makes a note of the garbage collecting event within shared monitoring memory 135. In yet another embodiment, the callback function transfers status data of the garbage collecting event to VM monitor 260, which in turn registers the garbage collecting event into shared monitoring memory 135. A history of garbage collecting events and related monitoring data may be saved concurrently within shared monitoring memory 135.
As discussed above, shared monitoring memory 135 is external to Java worker nodes 105. As such, shared monitoring memory 135 is insulated from Java worker nodes 105 in the event one or more of them crashes, hangs (e.g., enters an infinite loop), or otherwise fails. Accordingly, even if a JVM 120 crashes, the latest status data 130 just prior to the faulty JVM 120 going down is still available within shared monitoring memory 135. Vital information may be quickly obtained from shared monitoring memory 135 to determine the source of the error. In fact, this postmortem status data may already be displayed on monitoring console 110 for inspection by an IT technician without any additional effort to obtain it.
In the illustrated embodiment, monitoring console 110 can display both garbage collection statistics and heap utilization statistics. The garbage collecting activities of multiple JVMs 120 can be displayed at once. The garbage collecting monitoring data displayed may include a recent history for each JVM 120, while outputting long term records to log files. The garbage collecting monitoring data may include: amount of currently available memory within each internal heap 225, percentage of currently available memory, amount of consumed memory within internal heap 225, percentage of consumed memory within internal heap 225, absolute amount of available memory, start and stop time/date of each garbage collecting event, duration of each garbage collecting event, and the like.
The heap utilization monitoring data displayed may include: shared class utilization, shared object utilization, local class utilization, and local object utilization for each JVM 120. In one embodiment, the heap utilization data may simply be a snap shot of the most recent utilization statistics or include a recent history of the utilization statistics. The utilization data displayed may include hit rates, number of objects/classes currently residing in each heap, last time each object/class was utilized, and the like. The utilization statistics may also be output to a log file.
Furthermore, monitoring console 110 may display and monitor multiple AS instances 105 coupled to network 305. In this embodiment, monitoring console 110 may include multiple panels, tabs, or windows associated with each AS instance 105 and output long term records to separate log files for each AS instance 105.
In a process block 510, web service interface 215 receives the status query and parses shared monitoring memory 135 to retrieve the requested status data. In response, the retrieved status data is transmitted to monitoring console 110 (process block 515) and displayed by monitoring console 110 to a screen for inspection by a user, such as an IT technician or the like (process block 520).
In one embodiment, web service interface 215 and monitoring console 110 may negotiate a reporting contract dictating that web service interface 215 is to periodically update monitoring console 110 with status data 130 without need of first transmitting the status query (process blocks 505 and 510). In this case, web service interface 215 pushes status data 130 to monitoring console 110, as opposed to monitoring console 110 pulling status data 130 from web service interface 215.
Web dispatcher 630 implements a load-balancing mechanism distributing service requests from client nodes 610 among server nodes 615 within cluster 605. For example, web dispatcher 630 may implement a round-robin load-balancing mechanism or the like. Web dispatcher 630 may be one of server nodes 615 having the task of dispatching service requests among server nodes 615 of cluster 605 or a stand alone hardware node. The service requests are processed by server nodes 615 and subsequently provided to database nodes 625. Database nodes 625 offer up the requested data to server nodes 615, which in turn process and format the results for display on client nodes 610.
Eash AS instance 105 may further include its own dispatcher mechanism to distribute the requests assigned to it among its individual Java worker nodes 105. In one embodiment, Java worker nodes 105 are based on J2EE. AS instances 105 may further include other types of worker nodes including those based on the Microsoft .NET standard, the Advanced Business Application Programming (“ABAP”) standard developed by SAP AG, and the like.
One of client nodes 610 may execute monitoring console 110 to provide remote monitoring of AS instances 115, and in particular, remote monitoring of each worker node (including Java worker nodes 105, .NET worker nodes, and ABAP worker nodes). If an IT technician notices that one of the worker nodes has a low heap utilization, overactive garbage collection activity, or the like, the IT technician can take appropriate action including resetting the problematic worker node. Alternatively, scripts may run in concert with monitoring console 110 on a client node 610 to automatically address a problematic worker node based on a predefined response policy.
The elements of processing system 700 are interconnected as follows. Processor(s) 705 is communicatively coupled to system memory 710, NV memory 715, DSU 720, and communication link 725, via chipset 730 to send and to receive instructions or data thereto/therefrom. In one embodiment, NV memory 715 is a flash memory device. In other embodiments, NV memory 715 includes any one of read only memory (“ROM”), programmable ROM, erasable programmable ROM, electrically erasable programmable ROM, or the like. In one embodiment, system memory 710 includes random access memory (“RAM”), such as dynamic RAM (“DRAM”), synchronous DRAM, (“SDRAM”), double data rate SDRAM (“DDR SDRAM”) static RAM (“SRAM”), and the like. DSU 720 represents any storage device for software data, applications, and/or operating systems, but will most typically be a nonvolatile storage device. DSU 720 may optionally include one or more of an integrated drive electronic (“IDE”) hard disk, an enhanced IDE (“EIDE”) hard disk, a redundant array of independent disks (“RAID”), a small computer system interface (“SCSI”) hard disk, and the like. Although DSU 720 is illustrated as internal to processing system 700, DSU 720 may be externally coupled to processing system 700. Communication link 725 may couple processing system 700 to a network (e.g., network 305) such that processing system 700 may communicate over the network with one or more other computers. Communication link 725 may include a modem, an Ethernet card, a Gigabit Ethernet card, Universal Serial Bus (“USB”) port, a wireless network interface card, a fiber optic interface, or the like.
It should be appreciated that various other elements of processing system 700 have been excluded from
The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
