April 25, 2012 at 8:18 am
We are in the process of upgrading our production and disaster recovery 64-bit SQL servers from 72GB to 192GB. After first upgrading our disaster recovery server to 192GB, I set the max server memory to 186GB for the buffer pool. The production server has its max server memory set to 65GB. On the production server when I query sys.dm_os_sys_info, it shows 72GB for physical memory, 65GB for bpool_committed, and 65GB for bpool_visible which is what I would expect to see. However, after the disaster recovery server upgrade, querying sys.dm_os_sys_info shows 192GB for physical_memory, 48GB for bpool_committed, and 168GB for bpool_visible.
Should I not be see 186GB for bpool_visible since that is what I set as the max server memory for the buffer pool?
April 25, 2012 at 9:29 am
When committed reaches target, visible will reach that same level. Visible and target match on all my instances except 1. Why are you concerned about the visible value? Or just wondering?
EDIT: "except 1"
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 25, 2012 at 10:57 am
I am wondering because bpool_visible is the number of 8K pages that are accesible to the buffer pool. If max server memory is set to 186GB then I would expect bpool_visible to reflect the same which seems to be the case on the production server which has yet to be upgraded.
April 25, 2012 at 11:04 am
What else is running on the server? Can you account for 24GB of committed memory from processes other than SQL Server's buffer pool?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 25, 2012 at 11:09 am
Nothing else is running on the server. It is a dedicated SQL Server box. No SSIS, SSRS, etc. No, I cannot account for the missing 18Gb (difference between max server memory and bpool_visible) hence the forum question.
April 25, 2012 at 11:31 am
I say 24 because I think bp_visible is the amount SQL Server in theory could allocate per the VAS on the server and 192 - 168 = 24...so in theory it would take processes outside the buffer pool occupying 24GB to knock that number down to 168. Stumped...
I wonder what it will say once the buffer pool is warmed up and target = committed, if you can get it that high.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 25, 2012 at 12:21 pm
Yeah I dont know. That is one thing I was wondering as well is if bpool_visible would increase after the buffer pool started getting filled with data. Once we perform our planned failover this coming weekend to upgrade the prod server, we will definitely use the entire amount of RAM allotted to the buffer pool on the current standby. Of course, I am hoping to find out before then so I dont have to monkey with settings when it is in production if I find out something is wrong.
April 25, 2012 at 12:36 pm
An interesting tidbit...have a look around this page for "bpool_visible"
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 25, 2012 at 12:58 pm
Interesting. It seems in 2012 visible and target will report the exact same numbers. The 2008 documentation says they can report different numbers. On both the production and standby server, bpool_commit_target and bpool_visible report the same numbers, its just I dont understand why both dont report the full amount allocated. Strange.
April 26, 2012 at 7:18 am
Anyone else having any ideas?
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply