The same application behaves strange in java 10.
In Java 10 CPU usage shows much higher when compared to running in Java 8 or Java 7 even if the GC rate is low.
Related
I am trying to run a Java program which finds Poly divisible numbers. However, I have found that it is significantly slower on my Windows computer in comparison to the speed it runs at on a Macbook Pro.
There was another question I found here: Java code running faster on Mac with slower processor than on my Windows computer? with a similar problem, however it has no conclusive answer to why it is slower.
Do you know any reason why this may be and how this could be fixed.
Windows Specs:
i7 7700k # 4.2 GHz (4 Cores, 8 threads)
16 GB RAM # 3000MHz. (DDR4)
Timings: https://gist.github.com/JosephBywater/f79f5e8277d148c26804c85c2c6a399a
Macbook Pro Early 2015
Intel i5 (unknown model, possibly i5 5257U) # 2.7 GHz
8 GB RAM # 1867 MHz. (DDR3)
Timings: https://gist.github.com/oliverdunk/ad3dd134b653c43c9928
Code https://github.com/oliverdunk/Polydivisbles
I have two machines with exactly the same hardware settings: Intel i7 CPU (4 cores, 8 threads or virtual cores) 16GB memory. The only difference is that one machine runs Windows 7, and the other hosts Ubuntu.
My multi-threading program has 8 threads doing similar tasks. I noticed that when it is running on the windows machine, only 4 virtual cores are running with 30% CPU usage, and the rest 4 virtual cores have 0 CPU usage. When the same program runs on the Ubuntu machine, all the 8 virtual cores have roughly equal CPU usage of 30%.
Besides, the program runs significantly faster on the Ubuntu machine.
Why does java not use all the CPU cores on windows? Is there anything particular with the jre/OS setting?
More details on System info:
Windows 7 64 bit, Oracle 64 bit java 1.7
Ubuntu 14.04 LTS 64 bit, OpenJDK 64 bit java 1.7
More details on the task:
One thread read file, initiate instances, feed them to input buffer (LinkedBlockingQueue).
Eight threads calculate some measures for each given instances. The calculation results are fed to output buffer (LinkedBlockingQueue).
One thread write the results to file (sort of intensive I/O here).
I'm developing a JavaFX desktop application using Java 7. The application I'm developing uses 10-12 background threads which gets system information or makes HTTP request. I also use some JNA and JNI code.
When i limit the heap size to 40 MB, it's fairly enough and the application runs without a problem with total ~100 MB memory.
However since Oracle is dropping support for Java 7 in April, I decided to upgrade the application to Java 8, the upgrade went smoothly, not much code change required, but i noticed the total memory consumption increased to 130+-20 MB. I researched about this problem, and found out Java 8 introduced Metaspace, I think that may be the problem, but in Java 7 I never set the PermGenSize so in the end I have no idea why the application uses more memory.
Just so you know Metaspace usage is about 33-36 MB in VisualVM.
Any help would be appreciated , thanks
-------SOLVED---------
The problem was; the JDK I was using was 64 bit, since 64 bit JDK on Windows only contains server mode, I installed a 32 bit JDK 8 and started using it in client mode, since then the RAM usage is about 80 MB.
I have a little Java application that I wrote for recording my work activities. Since I have it open all day, every day, one of the things that originally concerned me as to choice of language is the amount of memory it would use.
Happily, under Windows XP I it would typically consume about 5 MB when minimized and 12 or so when maximized, and happily runs with -Xmx5M (memory consumption according to Windows Task Manager).
When I upgraded my home PC with newer hardware, and at the same time, to Windows 7 64, (although I installed and am using the 32 bit JVM), I immediately noted that the JVM for this application now reports 68 MB+ always... and that's with -Xmx5M -Xss16K, according to Task Manager's "Working Set".
Both the old and new machines had/have 4 GB of RAM, of which 512 MB is used by video. Both were running recent builds of Java 6 - about update 15 for WinXP, and now update 24 for Win7. The application footprint on disk is 70 K in 12 classes. Moreover, my work computer is still Windows XP, running Java 6_24, and it shows about 12 MB for this identical application - and by identical I mean literally that, since the two systems are sync'd for all my development tools.
As a developer, I need to understand the reasons why my applications appear to chew up so much memory.
Can anyone shed some light on this, and suggest how to meaningfully reduce the memory footprint for a Java 6 application?
Edit
The answer may be in an excessive PermGen size. According to JVisualVM, I have a heap of:
Size: 5.2 MB, Used: 4.3 MB (peak) and Allocated 6.2 MB.
but for the PermGen
Size: 12.5 MB, Used: 4.6 MB (peak) and Allocated 67.1 MB.
So is it possible that the 68 MB shown in Task Manager in Win 7 is simply requested but unassigned virtual memory?
EDIT 2
Reducing PermGen to 12 MB had no effect on the process RAM, but JVisualVM did show it reduced (apparently 12 MB constitutes some sort of minimum, because going lower than that had no effect in JVVM).
The 64 bit OS uses 64 bits as the size of pointers while a 32 bit OS uses 32 bits. That might just be one of the reasons though.
Remember that everything in Java is a pointer (for the most part) so when switching to a 64 bit machine, with 64 bit memory addresses, your pointers double in size.
There is an option in the JVM (-XX:+UseCompressedOops) to turn on compressed object pointers. This will put your memory usage near the levels you saw on 32 bit machines.
For the 64-bit JVM you can specify an option that will reduce the overhead of 64-bit addressing. As long as the heap is under 32GB it can essentially compress the pointers back to 32-bit. In a typical Java application this saves about 40% of the memory. See Compressed oops in the Hotspot JVM for more details. Here's the option for it:
-XX:+UseCompressedOops
Note that if you use a 32-bit JVM on a 64-bit OS that you won't pay the overhead of 64-bit memory addresses (although there's a different overhead to pay there in translation, yet it's very minor).
I believe that Windows 7 doesn't report memory use the same as XP either (I don't have a reference offhand though). So for a fair comparison of 32-bit vs 64-bit you need to run both on the same version of Windows.
This has nothing to do with the operating system being 64-bit - Windows XP and Windows 7 use RAM in very different ways.
Because of this, Windows 7 will almost always report all programs as using more memory than Windows XP did. Don't worry about this - this is just a result of Windows 7 using your memory the way it should be: as a cache.
While it's not the whole story, the PermGen size is 30% larger on 64-bit plaforms:
-XX:MaxPermSize - Size of the Permanent Generation.
[5.0 and newer: 64 bit VMs are scaled
30% larger; 1.4 amd64: 96m; 1.3.1
-client: 32m.]
Java 6 HotSpot VM Options
Hi I'm trying to test my JAVA app on Solaris Sparc and I'm getting some weird behavior. I'm not looking for flame wars. I just curious to know what is is happening or what is wrong...
I'm running the same JAR on Intel and on the T1000 and while on the Windows machine I'm able to get 100% (Performance monitor) cpu utilisation on the Solaris machine I can only get 25% (prstat)
The application is a custom server app I wrote that uses netty as the network framework.
On the Windows machine I'm able to reach just above 200 requests/responses a second including full business logic and access to outside 3rd parties while on the Solaris machine I get about 150 requests/responses at only 25% CPU
One could only imagine how many more requests/responses I could get out of the Sparc if I can make it uses full power.
The servers are...
Windows 2003 SP2 x64bit, 8GB, 2.39Ghz Intel 4 core
Solaris 10.5 64bit, 8GB, 1Ghz 6 core
Both using jdk 1.6u21 respectively.
Any ideas?
The T1000 uses a multi-core CPU, which means that the CPU can run multiple threads simultaneously. If the CPU is at 100% utilization, it means that all cores are running at 100%. If your application uses less threads than the number of cores, then your application cannot use all the cores, and therefore cannot use 100% of the CPU.
Without any code, it's hard to help out. Some ideas:
Profile the Java app on both systems, and see where the difference is. You might be surprised. Because the T1 CPU lacks out-of-order execution, you might see performance lacking in strange areas.
As Erick Robertson says, try bumping up the number of threads to the number of virtual cores reported via prstat, NOT the number of regular cores. The T1000 uses UltraSparc T1 processors, which make heavy use of thread-level parallelism.
Also, note that you're using the latest-gen Intel processors and old Sun ones. I highly recommend reading Developing and Tuning Applications on UltraSPARC T1 Chip Multithreading Systems and Maximizing Application Performance on Chip Multithreading (CMT) Architectures, both by Sun.
This is quite an old question now, but we ran across similar issues.
An important fact to notice is that SUN T1000 is based on UltraSpac T1 processor which only have 1 single FPU for 8 cores.
So if you application does a lot or even some Float-Point calculation, then this might become an issue, as the FPU will become the bottleneck.