Databases Reference
In-Depth Information
To calculate how many pages, get the memory needed and divide by the page size. The
formula is sum of JVM heaps / page size .
The memory needed is 4 GB (4096 MB) and the page size is 2 MB (Hugepagesize is 2048
KB). The number of HugePages is 4096/2 = 2048 .
This 4 GB of reserved HugePages will be pre-allocated and cannot be used by other
applications, even when the JVMs are not running, so be sure to do the sizing properly.
It is a common mistake to reserve a large amount of memory in HugePages
and the host starts to swap. Remember to leave enough memory for the other
applications and the operating system. Avoid the swapping at all costs.
If you have the -Xverbose:gc,memory enabled, you can check if the JVM is using the
HugePages properly in the STDOUT logfile.
[INFO ][memory ] Using 2MB pages for Java heap.
With the PROD_Server01 started, checking the /proc/meminfo should also reveal
that HugePages are in use.
[wls@prod01]$ cat /proc/meminfo | grep Huge
HugePages_Total: 2048
HugePages_Free: 1024
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
Using HugePages provides some significant advantages:
F Because of the larger page size, the page table will be smaller in size. With
HugePages, a 10 GB heap size should use only 5120 page entries despite the
2621440 page entries present when using the default 4 KB page size. This
minimizes the CPU cost and the page table memory usage.
F A performance boost in memory operations because the TLB cache works more
efficiently, with more cache hits.
F The memory reserved for HugePages will never swap to disk.
F It forces a more controlled memory usage of the heap sizes.
Configuring the transaction (JTA) timeouts
In production environments, slowness in a legacy or external system (a database or web
service for example) can lead to a scenario where all WebLogic threads and resources
become busy waiting for response. The slowness can pile up the requests, generating
a hang scenario in WebLogic.
 
Search WWH ::




Custom Search