[Gllug] HugePages

James Courtier-Dutton james.dutton at gmail.com
Fri Oct 29 13:30:28 UTC 2010


On 29 October 2010 13:45, Kostas Georgiou <k.georgiou at atreides.org.uk> wrote:
> On Thu, Oct 28, 2010 at 06:02:53PM +0100, Steve Parker wrote:
>
>> The reason I ask, is that we have a 72Gb server running JRockit with
>> 48Gb+ JVMs in a 60Gb block of hugepages; with no swapping, and 3Gb free
>> of the 12Gb "normal" memory that is left, performance is dismal - "ls"
>> in an empty directory can take many seconds. If we bring down the
>> hugepages, things seem much better. But the apps guys say that their JVM
>> has to be all in hugepages, so if there's only 20Gb hugepages, then
>> their JVM can't store more than 20Gb data in RAM (which is the design
>> that we have been told we must work with).
>>
>> Does anybody have much experience with hugepages? This is RHEL5.3, on 2
>> x quad-core hyperthreaded Intel Xeon 5570s
>
> Remember that you are in a NUMA machine, you have 12Gb/3Gb available/free
> memory after your hugepages but it doesn't mean that all nodes have
> memory left. Your ls could be running in a memory starved node and you
> can guess the rest. I'll be interested to see what numactl --hardware
> gives after boot and later on.
>
> Here is an interesting article for the effects of NUMA in mysql
> http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
>
> Kostas

I have found out that he is using 20GB of SWAP. I suspect that is the
cause of his problem.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list