Java, MySql increased performance with Huge Pages

[Resources updates: 2010.07.07, 2009.11.03, 2009.05.27]

Long running, large memory, high performant applications often have special needs with respect to their memory management. On Linux, Solaris and other modern OSes, the translation look-aside buffer (TLB) - whose page size of 4k for many CPUs/OSes - becomes a scalability issue in these extreme conditions. In order to get around TLB scalability issues, huge page sizes are used to reduce the impact on performance. This can be of use to installations with large scale Java, MySql and other large memory applications.
300% improvement: "Well, in my case, I was able to achieve an over 3x improvement in my EJB 3 application, of which fully 60 to 70% of that was due to using large page memory with a 3.5GB heap. Now, a 3.5GB heap without the large memory pages didn't provide any benefit over smaller heaps without large pages. Besides the throughput improvements, I also noticed that GC frequency was cut down by two-thirds, and GC time was also cut down by a similar percentage (each individual GC event was much shorter in duration). Of course, your mileage will vary, but this one optimization is worth looking at for any high throughput application." [20]

25% - 300% improvement: "These memory accesses are then frequently cache misses which introduces a high latency to the memory request. Increasing page sizes from 4K to 16M significantly reduces this problem as the number of tlb misses drops. Typically it will reduce runtimes by 25-30% but in an extreme case I've seen an SPH code run 3x faster simply by enabling large pages." [8]

In this article[11], the too common problem of an intermittant, ephemeral but huge reduction in performance was solved by recognizing that 5GB of memory was taken-up in the page tables, made up of 4k pages. Solution: use Linux huge page size support and make pages larger, reducing the page table size to 200MB.

"Many Java applications, especially those using large heaps, can benefit from what the operating systems call large or huge pages."[10]

"17.26 times faster" (Linux, Java, 64bit) [19]

"While 16 GB pages are intended to only be used in very high-performance environments, 64 KB pages are general-purpose, and most workloads are likely to see a benefit by using 64 KB pages rather than 4 KB pages."[7]

Java on an OS that supports large page sizes has better performance for many application. Which applications? Use tools[43] to see the TLB cache hit rate when these applications run. Different CPUs support different page sizes:
  • i386: 4K and 4M (2M in PAE mode)
  • ia64: 4K, 8K, 64K, 256K, 1M, 4M, 16M, 256M
  • PPC64: 4K and 16M
  • POWER5+: 4K, 64K, 16MB, 16GB (!!)
  • UltraSparc III: 8K, 64K, 512K, 4M
  • UltraSparc T2: 8K, 64K, 4M, 256M
Just add -XX:+UseLargePages to the JVM command line to use after setting up. For CPUs that support multiple sizes, use -XX:LargePageSizeInBytes=2m to define the page size you want to use (i.e. for 2MB pages, etc.).

Additional Huge Page resources


    Comments

    Dexter said…
    Wonderful resource..

    I need your assistance on Java code for restoring the backup file into MySQL. If you can provide any kind of assistance that will be great.

    Thanks
    16 April, 2009 18:26
    Anonymous said…
    Minor correction:

    "5GB of memory was taken-up in the TLB" should be "5GB of memory was taken-up in the page tables".
    08 July, 2010 13:35
    Glen Newton said…
    Correction made. Thanks! :-)
    08 July, 2010 18:52
    Gavin Carr said…
    Great resource - thanks Glen.

    FYI, link [54] is broken. Seems to be http://events.linuxfoundation.org/slides/lfcs09_hansen1.pdf now.
    04 March, 2011 12:13
    Post a Comment

    Popular posts from this blog

    Canadian Science Policy Conference

    The Canadian Science Policy Conference is to held in Toronto, October 28-30, 2009. While the five themes , sub-panels and speakers looking both interesting and relevant, I am disappointed and perhaps a little alarmed that there appears to be no (explicit) mention of research data issues, research data management or research data archiving, despite the series of Canadian consultations examining these issues ( National Consultation on Access to Scientific Research Data (NCASRD) , 2004; National Data Archive Consultation Building Infrastructure for Access to and Preservation of Research Data , 2002; Data Access in Canada: Issues for Global Change Research” (Royal Society of Canada), 1996 ) and indicating the pressing need for 1) A research data archiving strategy and policy; 2) A research data archive. I think this is an issue that has too long been neglected (although there are some positive signs, like International Polar Year ), impacting Canadian science and innovation, especiall
    Read more

    Project Torngat: Building Large-Scale Semantic 'Maps of Science' with LuSql, Lucene, Semantic Vectors, R and Processing from Full-Text

    Image
    Project Torngat is a research project here at NRC - CISTI   [ Note that I am no longer at CISTI and that I am now continuing this work at Carleton University - GN 2010 04 07 ] that looks to use the full-text of journal articles to construct semantic journal maps for use in -- among other things -- projecting article search results onto the map to visualize the results and support interactive exploration and discovery of related articles, term and journals. Starting with 5.7 million full-text articles from 2200+ journals (mostly science, technology and medical (STM)), and using LuSql , Lucene , Semantic Vectors , R , and processing , a two dimensional mapping of a 512 dimension semantic space was created which revealed an excellent correspondence with the 23 human-created journal categories: Semantic Journal Space of 2231 Journals Scaled to Two Dimensions This initial work was initiated to find a technique that would scale, and follow-up work is looking at integrating t
    Read more