Jarle Hulaas [e-mail]

1
Monitoring of resource consumptionin Java-based
application servers

• Jarle Hulaas Jarle.Hulaas_at_epfl.ch
• Swiss Federal Institute of Technology in Lausanne
  (EPFL)
• Switzerland
• (Formerly at CUI, Uni Geneva)
• Dimitri Kalas kalas8_at_etu.unige.ch
• University of Geneva
• Switzerland

10th HP-OVUA workshop, Geneva, Switzerland July
7, 2003
2
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

3
What is Resource Management ?

• Physical resources
• CPU
• (Virtual) Memory
• Network bandwidth
• Management of resources
• Monitoring of consumption
• Controlling (i.e. limiting) it

4
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

5
What about Java ?

• Problem Java offers no support for resource
  management !
• Our solution portable resource management
  through byte-code rewriting schemes

6
General Approach
Execute
7
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

8
Class Analysis for CPU monitoring
0 bipush 10 2 istore_1 3 iconst_1 6 istore_3 7
goto 25 10 invokestatic 2 ltMethod
java.lang.Thread currentThread()gt 13 pop 14
ldc2_w 3 ltLong 100gt 17 bipush 100 19
invokestatic 5 ltMethod void sleep(long, int)gt 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 ltClass java.lang.Exception
gt
9
Method Rewriting by J-RAF

• Object f (int x, MemAccObj mem, CPUAccObj cpu)
• cpu.usage 8
• if (x lt 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

10
Generic Application Structure
Bytecode Rewriting
11
J-RAF in Action

• CPU monitoring for some multi-threaded applet

12
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

13
Benchmarks for CPU accounting
SPEC JVM98
14
Resource Mgmt for Servlet Engines
Resource Mgmt for Servlet Engines

Servlet Engines
Access rights
HTML, streams
Requests
Reporting
End-user
Providers Database
15
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

16
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

17
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 Tomcats thread pooling
• Register and account for created sub-threads
• Add a RequestAccount class for aggregating usage
  of all these threads

18
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

19
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

20
Resulting Servlet Structure
21
Sample Log for a Given Client
Servlet name
Timestamp
JVM ops/s
InOut Bandwidth Bytes/s
22
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

23
Preliminary Performance Results
Simultaneous requests Empty page Streaming factorials ZIP page
1 700 84.9 10.5
20 28.8 23.9 20.7
50 48.3 22.8 30.8
Overhead due to CPU monitoring

• Average overhead same order of magnitude as
  for standard Java applications ( 30 )

24
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

25
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

26

• Thank you for your attention !