HPOVUA2003 slides

Monitoring of resource consumptionin Java-based application servers: 

Jarle Hulaas Jarle.Hulaas@epfl.ch Swiss Federal Institute of Technology in Lausanne (EPFL) Switzerland (Formerly at CUI, Uni Geneva) Dimitri Kalas kalas8@etu.unige.ch University of Geneva Switzerland Monitoring of resource consumption in Java-based application servers 10th HP-OVUA workshop, Geneva, Switzerland July 7, 2003

Overview: 

Overview What is Resource Management ? Our General Approach Some Details on our J-RAF Tool Management of a Servlet Engine Adapting J-RAF to Tomcat Assessment

What is Resource Management ?: 

What is Resource Management ? Physical resources: CPU (Virtual) Memory Network bandwidth Management of resources: Monitoring of consumption Controlling (i.e. limiting) it

Benefits of Resource Management: 

Benefits of Resource Management Software development Monitoring and profiling of distributed applications Security Prevention against Denial-of-Service attacks Reliability More robust behaviours in presence of resource shortage Accountability (liability) for resource consumption E-commerce Billing for resource consumption Quality-of-Service guarantees, load balancing

What about Java ?: 

What about Java ? Problem: Java offers no support for resource management ! Our solution: portable resource management through byte-code rewriting schemes

General Approach: 

General Approach Execute

Our Solution: 

Our Solution Program transformations to expose resource consumption Application classes and libraries, incl. JDK Rewritten programs unknowingly update accounting objects CPU: count the number of executed JVM instructions Memory: redirection of memory allocations Network bandwidth: wrapper libraries

Class Analysis for CPU monitoring: 

Class Analysis for CPU monitoring 0 bipush 10 2 istore_1 3 iconst_1 6 istore_3 7 goto 25 10 invokestatic #2 <Method java.lang.Thread currentThread()> 13 pop 14 ldc2_w #3 <Long 100> 17 bipush 100 19 invokestatic #5 <Method void sleep(long, int)> 22 iinc 3 1 25 iload_3 26 iconst_1 27 if_icmple 10 30 iload_2 31 iconst_1 32 if_icmpl1 3 35 iinc 2 -1 38 goto 44 41 astore_2 42 iconst_0 43 istore 3 44 return Exception table: from to target type 3 38 41 <Class java.lang.Exception>

Method Rewriting by J-RAF: 

Method Rewriting by J-RAF Object f (int x, MemAccObj mem, CPUAccObj cpu) { cpu.usage += 8; if (x < 0) { cpu.usage += 8; return null; } else { cpu.usage += 26; int y = g(x, mem, cpu); mem.checkAllocation(SIZEOF_FOO); Object o = new Foo(y, mem, cpu); mem.register(o); return o; } }

Generic Application Structure: 

Generic Application Structure Bytecode Rewriting

J-RAF in Action: 

J-RAF in Action CPU monitoring for some multi-threaded applet

Validation of the J-RAF approach: 

Validation of the J-RAF approach Tested on J2SE … arbitrary applications, as well as applet and mobile agent environments Sun 1.4.1 HotSpot Virtual Machine, IBM JDK 1.3.1 … and on J2ME (embedded devices) … dedicated system with Java processor from aJile Systems

Benchmarks for CPU accounting: 

Benchmarks for CPU accounting SPEC JVM98

Resource Mgmt for Servlet Engines: 

Resource Mgmt for Servlet Engines Reporting Requests HTML, streams Access rights Servlet Engines Provider’s Database End-user Resource Mgmt for Servlet Engines

Objectives: 

Objectives Fine-grained basis for: Usage-based billing (pricing policies are out of our scope) Identification of bottlenecks Badly programmed or malicious apps Load-balancing on clusters of servers

Required J-RAF extensions: 

Required J-RAF extensions Define a servlet as a coherent set of threads Flexible concept of client (end-user) context Enhanced detection of bandwidth consumption Remote reporting

Servlets as sets of threads: 

Servlets as sets of threads How to detect the start and end of a request processing ? Special rewriting of methods like doGet and doPost, to cope with Tomcat’s thread pooling Register and account for created sub-threads Add a RequestAccount class for aggregating usage of all these threads

User-level accounting : 

User-level accounting Periodically do: Summarize usage of all individual threads inside a servlet Summarize usage of all servlets run on behalf of a given user Report this usage to a database Problems that had to be solved: Overflow of counters at all levels Calibration of timeslices according to processing power

User context: 

User context Allow servlet programmers to define their own: Authentication schemes, IP-based or password-based Programmer must implement a ClientID interface Read usage rights from database User data reporting schemes Allow extensible reporting of user data, e.g. session IDs

Resulting Servlet Structure: 

Resulting Servlet Structure

Sample Log for a Given Client: 

Sample Log for a Given Client Servlet name Timestamp JVM ops/s In+Out Bandwidth [Bytes/s]

Performance Testing: 

Performance Testing Setting: Pentium-class PCs in a 100Mb LAN, Tomcat 4.1, MySQL 4.0.13 Generate many simultaneous connections with Jmeter 1.8.1 Different test servlets: Output of an empty page Streaming of factorials Download, ZIP-compress, and output a web page

Preliminary Performance Results: 

Preliminary Performance Results Overhead due to CPU monitoring Average overhead: same order of magnitude as for standard Java applications (~ 30 %)

Cons: 

Cons Purely a Java-level framework: Difficult to account for resources consumed by native code No real-time / resource reservation capabilities Increase of code size Restrictions on what servlets may do to play with thread priorities to perform introspection to inspect or modify accounting objects

Conclusions: 

Conclusions Initial work towards fine-grained management of Java servers Reasonable overheads Future work: Finalize management of memory Improve control vs monitoring Support for clusters of servers www.jraf2.org

Slide26: 

Thank you for your attention !