Support Wikipedia Follow My Heart: 十一月 2011

2011年11月28日星期一

Why VisualVM 1.3.3 cannot do CPU Time Sampling

Today I installed VisualVM 1.3.3 (the newest released version from visualvm.java.net). However, it appears that CPU Sampling Function is automatically disabled.

When I debug the VisualVM 1.3.3 through NetBeans, it appears the following exception information.


I searched the resource code and find that :



  1. in VisualVM 1.3.3, three new source files are added in plugin folder “Sample/CPU”. It appears that some detailed CPU usage information is available in the 1.3.3 version.

  2. in the new-added source “ThreadsCPU.java”, line 55. It writes that method “getThreadCpuTime” of ThreadMXBean is called, and expected return type is “long[]”. In contrast, in VisualVM 1.3.2 and former version, there is no such new code.

Interestingly, I found that there is “//NOI18N” comment in the end of the code like follows:




So let’s have a look at the javaDoc of JDK itself.


If we open the javadoc of OpenJDK, we can easily find that there is no such method in ThreadMXBean:


but if we open Sun Jdk (newer than 6u25), we can find the following hint:


So if users’ JDK is OpenJDK, or older version JDK (< 6u25), the “NoSuchMethodException” will definitely occured!

 

But the problem is WHY THE WHOLE CPU SAMPLING FUNCTION IS DISABLED ?

Let’s look at where the ThreadsCPU.java is invoked. It is in SampleImpl.java, line 551. Here we can easily find that the try-catch structure is so strong that normal logics are broken down.


try {
tcpu.getThreadsCPUInfo();
} catch (Exception ex) {
tcpu = null;

throw new RuntimeException(ex);

}



So let’s make some tiny change to it, as follows:





OK, we are DONE!


Now if users’ JDK does not support new getThreadCpuTime method, users can AT LEAST use functions same with VisualVM (Version 1.3.2).

2011年11月25日星期五

How to browse the fields of WMI Classes

We can use SQL-like language to query system-level information (including performance information) by WMI.

But the problem is that new users do not know what the definition of 'SQL Tables'. What kind of "Columns" do they have?

So it is very necessary for new users to check the content of each WMI classes.

******************************************************************************
Step 1: Run WBEMTEST.
(You can invoke it by inputting the name into Windows Start -> Run Dialog Box)

Step 2: Click the [Connection] Button, then you can see a jump-out dialog.

Step 3: In this [Connection] Dialog, change the Namespace (in the textfield) to "root\cimv2", and then click [Connect]. Then you find yourself retured back.

Step 4: Now click the [Enum Classes] button. And then choose [Recursive] Radio button with leaving the main text field blank. Then click [OK].

Step 5: Now you can see that all WMI Classes (e.g. Win32_System) are listed in the new Jump-out window. Now you can browse them using the scollbar.

Step 6: If you want to check the fields of certain class, just double-click it from the list. then you can browse its detailed information in a new window.


Use PerfMon to Find why your Windows Computer is Slow

I found a valuable post in other people's blog.
I think the knowledge about PerfMon (a tool embedded in Windows, majoring in System Performance Browse) can help you determine the bottleneck of your PC.


*********************************************************************************

Windows Perfmon: The Top Ten Counters

One of the things I love about Windows is Performance Monitor a/k/a PerfMon. It's an amazing tool that goes far too often unused - and when it does get used, it is often misinterpreted. So today I'm going to take you on the nickel tour through PerfMon, and the ten counters most valuable to determining overall system health and activity.

To open PerfMon, just go to the Start Menu, choose Run and type perfmon.
Bottleneck analysis
The most common use of PerfMon is to answer the burning question: why is my system running slow?

With the five performance counters listed below, you can quickly get an overall impression of how healthy a system is - and where the problems are, if they exist. The idea here is to pick counters that will be at low or zero values when the system is healthy, and at high values when something is overloaded. A 'perfectly healthy' system would show all counters flatlined at zero. (Perfection is unattainable, so you'll probably never see all of these counters flatlined at zero in real life. The CPU will almost always have a few items in queue.)
  • Processor utilization
    • System\Processor Queue Length - number of threads queued and waiting for time on the CPU. Divide this by the number of CPUs in the system. If the answer is less than 10, the system is most likely running well.
  • Memory utilization
    • Memory\Pages Input/Sec - The best indicator of whether you are memory-bound, this counter shows the rate at which pages are read from disk to resolve hard page faults. In other words, the number of times the system was forced to retreive something from disk that should have been in RAM. Occasional spikes are fine, but this should generally flatline at zero.
  • Disk Utilization
    • PhysicalDisk\Current Disk Queue Length\driveletter - this is probably the single most valuable counter to watch. It shows how many read or write requests are waiting to execute to the disk. For single disks, it should idle at 2-3 or lower, with occasional spikes being okay. For RAID arrays, divide by the number of active spindles in the array; again try for 2-3 or lower. Because a shortage of RAM will tend to beat on the disk, look closely at the Memory\Pages Input/Sec counter if disk queue lengths are high.
  • Network Utilization
    • Network Interface\Output Queue Length\nic name - is the number of packets in queue waiting to be sent. If there is a sustained average of more than two packets in queue, you should be looking to resolve a network bottleneck.
    • Network Interface\Packets Received Errors\nic name - packet errors that kept the TCP/IP stack from delivering packets to higher layers. This value should stay low.
To highlight a particular counter's line on the graph, select that counter in the lower pane. Then click the lightbulb icon on the toolbar above the graph. This will make the line for that counter turn thick and white (or black on some systems - I never found out why this changes).

Pay close attention to the scale column! Perfmon attempts to automatically pick a scale that will magnify or reduce the counter enough to produce a meaningful line on the graph ... but it doesn't always get it right. As an example, Perfmon often chooses to multiply Disk Queue Length by 100. So, you might think the disk queue length is sustained at 10 (bad!) when in fact it's really at 1 (good). If you're not sure, highlight the counter in the lower pane, and watch the Last and Average values just below the graph. In the screenshot below, I modified all of the counters to a scale value of 1.0, then changed the graph's vertical axis to go from 0-10.
To change graph properties (like scale and vertical axis as discussed above), rightclick the graph and chooseProperties. There are a number of things to customize here ... fiddle with it until you have a graph that looks good to you.
To get a more detailed explanation of any counter, rightclick anywhere in the perfmon graph and choose Add Counters. Select the counter and object that you are curious about, and click the Explain button.
This screenshot shows a very lightly-loaded XP system, with the Memory\Pages Input/Sec counter highlighted:
Click for larger image


All we see here is the Proccessor Queue Length hovering between 1 and 4, and two short spikes of Pages Input/Sec. All other counters are flatlined at zero, which is easy to check by highlighting each of them and watching the values bar underneath the graph. This is a happy system - no problems here!
But if we saw any of the above counters averaging more than 2-4 for long periods of time (except Processor Queue Length: don't worry unless it's above 10 for long lengths of time), we'd be able to conclude that there was a problem with that subsystem. We could then drill down using more detailed counters to see exactly what was causing that subsystem to be overloaded. More detailed analysis is beyond the scope of this article, but if there's enough interest I could do a second article on that. Leave a comment if you're interested!
General activity counters
Well, the system is healthy - and that's good ... but how hard is it working? Is the processor workin' hard, or hardly workin'? How much RAM is in use, how many bytes are being written to or read from the disk or network? The following counters are a good overview of general activity of the system.
  • Processor utilization
    • Processor\% Processor Time\_Total - just a handy idea of how 'loaded' the CPU is at any given time. Don't confuse 100% processor utilization with a slow system though - processor queue length, mentioned above, is much better at determining this.
  • Memory utilization
    • Process\Working Set\_Total (or per specific process) - this basically shows how much memory is in the working set, or currently allocated RAM.
    • Memory\Available MBytes - amount of free RAM available to be used by new processes.
  • Disk Utilization
    • PhysicalDisk\Bytes/sec\_Total (or per process) - shows the number of bytes per second being written to or read from the disk.
  • Network Utilization
    • Network Interface\Bytes Total/Sec\nic name - Measures the number of bytes sent or received.
In the graph below, I added these five counters to my existing 'bottlenecks' graph, and changed the vertical axis to go from 0-100. I highlighted the Working Set\_Total counter, which is currently at about 123 megabytes for the system. Notice how it shows a thick line at the top of the graph - you could assume that it was pegged at 100, if you didn't read the values bar (123,052,03 divided by a million is approximately 123 megabytes).
Click for larger image

And ... that's all for now. Hopefully this quick show-and-tell has given you enough information to use PerfMon more usefully in the future!

2011年11月24日星期四

How to run VisualVM in Ubuntu

Today I spent one hour struggling with running VisualVM in Ubuntu.
I am new hand in Linux OS. So I hope my experience can help people in similar conditions.
First, of course, you need to install Java Development Kit (JDK) into your ubuntu since it is not defauly installed.
The command I used is:

java –version (# make sure the path is correct, and “JDK” reveals in the path) (# if your installation of JAVA failed, you cannot get correct response by this command)
Second, it is time to install VisualVM.
VisualVM is free and open source software. If you install Sun-JDK, it is already binded. If you installed open-JDK like me, you need to download and install it independently.

After installation, the main code and resources of VisualVM can be found in default installation path (in my PC, it is “usr/lib/visualVM”), and the short cut start file (“jvisualvm”) will be created in “usr/lib”.
Third, before you directly run VisualVM, you MUST edit the auto-generated script file “jvisualvm” to match the java environment.
I hate using VI in Linux because I cannot remember hotkeys. So I installed leafpad (a simple notepad software) to edit txt files.


sudo chmod +w /usr/lib/jvisualvm (# use this command to change script file from “Readonly” mode to “Read & Write Mode”) sudo leafpad /usr/lib/jvisualvm (# use this command to invoke leafpad, to edit the content of script file -- jvisualvm)

The default content of script file MUST be changed, unless you cannot launch VisualVM successfully.
There is a section of code (as follows) in the file. (maybe starts from line 12). It means that the system checks all given paths (from [path1] to [path n]), if any path includes file “javac” in sub-folder “[path]/bin”, then VisualVM will use this path as “jdkhome”.
So here lies the problem.
WHEN YOU INSTALL VISUALVM, the content of this script file will not be updated according to your own JAVA ENVIRONMENT.
so I changed the this section of code as follows to solve the problem (by inserting my JDK path into condition part):
DO NOT FORGET TO SAVE THE FILE!
DO NOT FORGET TO REOPEN THE FILE TO CHECK YOUR CHANGE!
Now, you can successfully invoke VisualVM.
Enjoy monitoring!