Re: Strange behaviour of the buffer pool

On Jul 17, 8:57 am, RoB <pluma...@gmail.com> wrote: > >My post to the news group is taking forever. In any case, I looked > >around a bit and it seems like the easiest way to get your resident > >section to become larger, other then BUFFERS in the $ONCONFIG, is the > >LOCKS parameter. What do you have that set to? The initial lock > >table is also allocated in the resident section when the server is > >brought online, then if it should have to grow dynamically, it will > >spill over into the virtual segments. > > >Jacques > > Yes, this system does not seem to be working well! > > The LOCKS is set to 2000000 and if I remember correctly that should > only occupy 200000 [locks] x 4 [bytes/lock] ~ 7.6 MB which still > wouldn't account for much of the 224 MB. > > Perhaps this is expected behaviour on this version but it still seems > to be quite an overhead. > > RoB Hmm, according to the code the resident segment size is computed based on the sum of the following number of lock hash buckets * sizeof lock hash structure (this structure is smallish, but still larger then 4 bytes) + number of locks * sizeof lock structure + (note this would be 2,000,000 if you have LOCKS set to that and the size of a lock structure is larger then 4 bytes, actually into the 30 byte range or larget on 64bit) number of BUFFERS * sizeof buffer header struct + number of BUFFERS * PAGESIZE + size of physical log buffer * 2 + size of logical log buffer * 3 Also looking at the code, it's been like this for a pretty long time. So the 2 dominate factors is going to the BUFFERS and LOCKS paramters.