I’ve received questions about HugePages_Rsvd a few times in the last few months. After googling for HugePages_Rsvd +Oracle and not seeing a whole lot, I thought I’d put out this quick blog entry.
Here I have a system with 600 hugepages reserved:
# cat /proc/meminfo | grep HugePages
Next, I boot up this 1.007GB SGA:
SQL*Plus: Release 126.96.36.199.0 - Production on Tue Jul 8 11:25:14 2008 Copyright (c) 1982, 2008, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 1081520128 bytes Fixed Size 2166960 bytes Variable Size 339742544 bytes Database Buffers 734003200 bytes Redo Buffers 5607424 bytes Database mounted. Database opened. SQL>
Booting this SGA only used up 324 pages:
# cat /proc/meminfo | grep HugePages HugePages_Total: 600 HugePages_Free: 276 HugePages_Rsvd: 195
If my buffers are 700 MB and my variable SGA component is 324 MB, why weren’t 512 hugepages used? Let’s see what happens when I start using some buffers and library cache. I’ll run catalog.sql and catproc.sql and then check hugepages again:
# cat /proc/meminfo | grep HugePages HugePages_Total: 600 HugePages_Free: 237 HugePages_Rsvd: 156
That used up another 39 hugepages, or 78 MB. At this point my SGA usage still leaves about 305 MB of unbacked virtual memory. If I were to run some OLTP, the rest would get allocated. The idea here is that it really makes no sense to do the allocation overhead until the pages are actually touched. It makes no sense to go to all the trouble in VM land if the pages might never be used. Think about an errant program that allocates a sizable amount of hugepages just to rapidly die. While that’s not Oracle, the Linux guys have to keep a pretty general-purpose mindset. This really goes back to the olden days of Unix when folks argued the virtues of pre-allocating swap to ensure there would never be a condition where a swap-out couldn’t be satisfied. The problem with that approach was that before calls like vfork() became popular there was a ton of overhead on large systems just to retire VM resources of very short lived processes, such as those which fork() only to immediately exec().
OK, so that was a light-reading blog entry, but some googler, someday, might find it interesting.
Yes, that was a come-on title…so surprising, isn’t it? 🙂