Oracle Enterprise Manager Java Application Diagnostic Expert (JADE) improves the availability, performance and provides in-depth diagnostics for Java applications with low overhead. It enables:

1. Production diagnostics with no application instrumentation, saving time in reproducing problems
2. Visibility into Java activity including in-flight transactions, allowing administrators to proactively identify issues rather than diagnosing after-the-fact (application hangs, crashes, memory leaks, locks)
3. Tracing of transactions from Java to Database and vice-versa, enabling faster resolution of problems that span different tiers
4. Differential heap analysis in production applications.

This is Auptyma‘s “Java Application Monitor”. It’s likely Auptyma was acquired by Oracle – its founder and CEO was previously Director of the CRM Performance Group at Oracle.

…similar solutions for addressing the scalability challenges:

On the Data Tier we see the following:

1. Adding a caching layer to take advantage of memory resources availability and reduce I/O overhead

2. Moving from a database-centric approach to partitioning, aka shards

On the Business Logic Tier:

3. Adding parallelization semantics to the application tier (e.g., MapReduce)

4. Moving to scale-out application models to achieve linear scalability

5. Moving away from the classic two-phase commit and XA for transaction processing (See: Lessons from Pat Helland: Life Beyond Distributed Transactions)

… steps in optimizing and tuning mysql is to identify the queries that are causing problems. How can we find out what queries are taking a long time tocomplete? How can we see what queries are slowing down the mysql server? Mysql has the answer for us and we only need to know where to look for it…

…where to best focus your attention when tuning the performance of your applications and database servers, and how to effectively find the “low hanging fruit” on the tree of bottlenecks. It’s not rocket science, but with a bit of acquired skill and experience, and of course good habits, you too can do this magic! [The talk is delivered by] Jay Pipes [who] is MySQL’s Community Relations Manager for North America.

If you want to keep producing high-performance software, you must be able to run reproducible, comparable performance tests. Ideally, you’ll have dedicated, standard hardware on which to run these tests; this should be representative of, if not directly comparable with, what your customers run in production. You’ll run a basic set of performance tests as part of your release cycle, plus more comprehensive benchmarks as required.So what should you test? What is important? You need to find a balance between the time it takes to run the tests and the information they actually give you. A large set of complex tests can tell you a huge amount about your application and even help you track down areas that have caused performance degradation, but that might be too time consuming to run for every release. Simpler tests that can run automatically in less than an hour would be better. Furthermore, your tests need to measure something using public interfaces that are stable between releases; otherwise, maintaining the tests will become an overhead.
Of course, the tests must exercise the operations and code paths that are important to your customers. They must measure the throughput of the common transactions or queries, based on the types of datasets and loadings seen on production systems. If practical, a captured production workload that can be rerun on demand would be ideal.

(Q): If you have to pick top 10 things that you must monitor on any server to look for performance and/or scalability issues…what would they be?
Richard McDougall (A): Off the top of my head, in no particular order:

1. CPU: Check idle time and run queue length.
2. If there’s a CPU bottleneck, check if it’s an application or kernel CPU utilization issue with mpstat: high percentages of users indicate it’s an application issue. High sys may point to high network load or lock contention.
3. Memory: Check MDBs memstat to ensure there is sufficient free memory
4. Network: Check that networks are not overloaded by observing the bytes xfered against the availability bandwidth per link.
5. CPU for network: check if any CPUs are 100% busy servicing network interrupts. CPUs at 100% in mpstat, or intrstat are possible candidates.
6. File system latency: check the application visible latency with DTrace at the system call level (perhaps fsstat, iosnoop, or an aggregation around system calls).
7. Storage latency: check disk latency with iostat
8. Application level lock contention: check application level locks are now visible with plockstat
9. Kernel level locks: Check for hot locks with lockstat.
10. Check MMU activity on SPARC using trapstat. Sometimes an application may be reporting as running 100% in user mode, but may actually be spending a significant amount of time in kernel mode servicing TLB misses. Trapstat will show the % of time spent using TLB misses. If a significant amount of time (>10%) is evident, then large MMU pages may help.