Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up! 

News February 2015

jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

Site24x7
Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up!


jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 171 contents

First a big thank you to you, my readers! Last month the newsletter contained a small mistake on the AtomicIntegerFieldUpdater. You didn't all see it, because many of you wrote in to tell me, and the first correction (by reader Nils Kilden-Pedersen) was quick enough that I was able to correct the newsletter as it was going out. Kudos to you all being so sharp! (The correct version is that AtomicIntegerFieldUpdater.getAndIncrement(object) is atomic).

A note from this newsletter's sponsor

Site24x7.com : Deep dive Application Performance Monitoring
Fix performance issues with Java, .NET and Ruby platforms.
*** Monitor one app instance starting at $9 ***.

In this month's extracted tips are several high-level ones, but I want to start with Ross Mason's article. You know when you have a background process that's doing heavy IO - the virus scan kicked in or backups have started, etc, and that slows the whole system down? Have you wondered why it was that when something is reading/writing to disk intensively it slows down everything - including the completely unconnected program you are running? Ross explains that the page cache gets used exclusively by the intensive IO application and any other IO operations get queued - which means that even if your program does almost no IO, that tiny IO operation it does gets queued up until the current flush completes, pausing your program. And of course that sequence of tiny IO operations getting queued continues to repeat until the intensive IO is finished. This has many implications, not least the following extracted tip:

"If an application thread is writing while the kernel is flushing and a GC starts at this time, the GC cannot proceed until the flush completes which then lets the application thread proceed to a safepoint. This can make a long pause (in the GC log, you would see a long pause but not very much usr nor sys time)."

Other tips I'll highlight are:

"A zero copy request (eg FileChannel.transferTo) has the kernel copy data directly from disk to a socket without going through the application, improving application performance and reducing context switches."

"If building a segmented block data structure where elements can be added, it is efficient to leave spare capacity in a block to allow inserts to be performed without having to split the block on each insert."

And three high-level checklist tips from Srinath Perera' article, notthing new, but nice to have together:

"Unix 'Load average' represents the number of processes waiting in the OS scheduler queue. Load average will increase when any resource is limited (e.g. CPU, network, disk, memory etc.). A load average of more than 4x number of cores is a (too) high load."

"If performance targets are not being met and the machine has unused capacity, you should: test increase concurrent request load; check for locks; increase thread pool size; check the network has additional capacity."

"If performance targets are not being met and the machine is fully loaded, you should: check for other processes loading the machine; CPU profile the application if its CPU usage of the application is high; check if garbage collection is taking more than 10% of application elapsed time; check for IO load; check if the machine is paging."

Now on to all our usual sections: links to tools, articles, news, talks and as ever, all the extracted tips from all of this month's referenced articles including those gems above.

A note from this newsletter's sponsor

New Relic - Try New Relic today and get your free Data Nerd shirt!
Free SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

News

Java performance tuning related news.

Tools

Java performance tuning related tools.

A note from this newsletter's sponsor

Get total visibility in just 15 minutes with AppDynamics PRO,
A performance monitoring tool for Java/.NET apps.
It installs in minutes. Start your FREE TRIAL today.

Articles

Jack Shirazi


Back to newsletter 171 contents


Last Updated: 2017-06-27
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news171.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us