Microsoft SQL Server memory utilization - sql-server

I'm confused about memory utilization of SQL Server. Before migration I've been using 2GB RAM and memory usage was a 1.87GB. After I migrated my server with 16GB physical memory. But it's not approximately 1.87GB it will be 5Gb or higher than. SQL Server data hasn't changed.
Here is memory usage of my current server. Do you have any idea about this? PLS

It uses more memory because it can. It's used for caching purposes; indexes, query plans, data.
You can limit the memory usage in the Server Memory Server Configuration Options

Related

SQL Server is not releasing memory after Daily Load

We have a SQL Server 2012 Enterprise Edition, 128GB of RAM, Windows 2008R2. The SQL Server job runs every day at 3 AM and takes 5 hrs to load data into the database. During this process, SQL Server utilizes 123GB (max memory allocated).
After the job completes, SQL Server is not releasing the RAM.
Queried memory utilization where buffer pool shows 97GB. Users don't access database during this time. I restarted SQL Server services to bring RAM down. I didn't find a correct answer related to this issue. Why is it not releasing the RAM? How can we bring RAM utilization down?
SQL Server Job -> SSIS package -> Import data from Mysql to SQL Server database
Thanks
This is by design once SQL Server uses memory, it keeps hold of it and does not release it back to OS.
Your Task Manager may show all/nearly all memory used by SQL Server but if you want to see how much memory SQL Server is actually using you can use the following query.
SELECT (physical_memory_in_use_kb/1024) AS Memory_usedby_Sqlserver_MB
FROM sys.dm_os_process_memory;
By design, SQL Server holds on to the RAM that is has allocated. Much of the RAM is used for the buffer pool. The buffer pool is a cache that holds database pages in memory for fast retrieval.
If SQL Server were to release some memory, and someone were to run a query that requests it right afterwards, the query would have to wait for expensive physical I/O to produce the data. Therefore, SQL Server tries to hold as much memory as possible (and as configured) for as long as possible.
The RAM settings here specify the min server memory and the max server memory. Careful setting of the max memory setting allows room for other processes to run. The article quotes a complicated formula for determining how much room to leave:
From the total OS memory, reserve 1GB-4GB to the OS itself.
Then subtract the equivalent of potential SQL Server memory allocations
outside the max server memory control, which is comprised of stack
size 1 * calculated max worker threads 2 + -g startup parameter 3 (or
256MB by default if -g is not set). What remains should be the
max_server_memory setting for a single instance setup.
In our servers, we usually just wing it and set the max memory option to several GB below the total physical memory. This leaves plenty of room for the OS and other applications.
If SQL Server memory is over the min server memory, and the OS is under memory pressure, SQL Server can release memory until it is at the min server memory setting.
Reference: Memory Management Architecture Guide.
One of the primary design goals of all database software is to
minimize disk I/O because disk reads and writes are among the most
resource-intensive operations. SQL Server builds a buffer pool in
memory to hold pages read from the database. Much of the code in SQL
Server is dedicated to minimizing the number of physical reads and
writes between the disk and the buffer pool. SQL Server tries to reach
a balance between two goals:
Keep the buffer pool from becoming so big that the entire system is low on memory.
Minimize physical I/O to the database files by maximizing the size of the buffer pool.
When SQL Server is using memory dynamically, it queries the system
periodically to determine the amount of free memory. Maintaining this
free memory prevents the operating system (OS) from paging. If less
memory is free, SQL Server releases memory to the OS. If more memory
is free, SQL Server may allocate more memory. SQL Server adds memory
only when its workload requires more memory; a server at rest does not
increase the size of its virtual address space.
...
As more users connect and run queries, SQL Server acquires the
additional physical memory on demand. A SQL Server instance continues
to acquire physical memory until it either reaches its max server
memory allocation target or Windows indicates there is no longer an
excess of free memory; it frees memory when it has more than the min
server memory setting, and Windows indicates that there is a shortage
of free memory.
As other applications are started on a computer running an instance of
SQL Server, they consume memory and the amount of free physical memory
drops below the SQL Server target. The instance of SQL Server adjusts
its memory consumption. If another application is stopped and more
memory becomes available, the instance of SQL Server increases the
size of its memory allocation. SQL Server can free and acquire several
megabytes of memory each second, allowing it to quickly adjust to
memory allocation changes.
If, for some reason:
You absolutely MUST have that memory back
You know you do not need it for a while
You are willing to pay a penalty for virtual memory allocation and physical I/O to retrieve data from disk the next time you need that memory
Then you can temporarily reconfigure the database max server memory setting to a lower value. This can be done through the SSMS user interface, or you can use an sp_configure 'max server memory' followed by reconfigure to make the changes programatically.
Full disclosure: I did not try it myself.
You should not try it on your production environment before testing it somewhere else.
This is from a DBA answer:
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'max server memory', 4096;
GO
RECONFIGURE;
GO
4096 should be replaced by the value that you find acceptable as the minimum.
Should be followed by a similar command to increase the memory back to your original maximum.

SQL Server 2012 memory use is 1000 x size of database - is this right?

I understand from a search here that SQL Server 2012 will continue to use memory until it meets the limit set for it, but the usage I see is hard to believe. The database is about 26MB at the moment, but the memory usage is over 30GB. Is this to be expected or is there some other problem lurking somewhere?
There is nothing wrong. The memory allocated to SQL Server can be changed to almost any value you'd like. I'd say 30GB is certainly overkill for a 26MB DB if it is the only DB on the instance. The memory allocated to SQL Server is used for numerous functions, e.g. sorting queries, plan caches, etc. The 30GB you're seeing means that 30GB of your system memory is reserved for SQL Server.
For a better understanding, you'll want to look into your target memory too. Target memory is how much memory is needed for SQL Server work, based on your configuration. In your case, I bet target memory equals max memory and SQL Server is trying to consume all the memory. Here is how you can check that:
SELECT *
FROM sys.dm_os_performance_counters
WHERE counter_name in ('Total Server Memory (KB)', 'Target Server Memory (KB)')
More information from Brent Ozar:
So how much memory is SQL using? I’ll make this easy for you. SQL
Server is using all of the memory. Period.
No matter how much memory you put in a system, SQL Server will use all
it can get until it’s caching entire databases in memory and then
some. This isn’t an accident, and there’s a good reason for it. SQL
Server is a database: programmers store data in SQL Server, and then
SQL Server manages writing that data to files on the hard drive.
Programmers issue SELECT statements (yes, usually SELECT *) and SQL
Server fetches the data back from the drives. The organization of
files and drives is abstracted away from the programmers.
To improve performance, SQL Server caches data in memory. SQL Server
doesn’t have a shared-disk model: only one server’s SQLserver.exe can
touch the data files at any given time. SQL Server knows that once it
reads a piece of data from the drives, that data isn’t changing unless
SQL Server itself needs to update it. Data can be read into memory
once and safely kept around forever. And I do mean forever – as long
as SQL Server’s up, it can keep that same data in memory. If you have
a server with enough memory to cache the entire database, SQL Server
will do just that. Why Doesn’t SQL Server Release Memory?
Memory makes up for a lot of database sins like:
Slow, cheap storage (like SATA hard drives and 1Gb iSCSI)
Programs that needlessly retrieve too much data
Databases that don’t have good indexes
CPUs that can’t build query plans fast enough
Throw enough memory at these problems and they go away, so SQL Server
wants to use all the memory it can get. It also assumes that more
queries could come in at any moment, so it never lets go or releases
memory unless the server comes under memory pressure (like if other
apps need memory and Windows sends out a memory pressure
notification).
By default, SQL Server assumes that its server exists for the sole
purpose of hosting databases, so the default setting for memory is an
unlimited maximum. (There are some version/edition restrictions, but
let’s keep things simple for now.) This is a good thing; it means the
default setting is covering up for sins. To find out if the server’s
memory is effectively covering up sins, we have to do some
investigation.
Docs on SQL Server memory configuration: https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/server-memory-server-configuration-options
Here is how you can set a fixed amount for Min/Max memory on SQL Server: https://technet.microsoft.com/en-us/library/ms191144(v=sql.105).aspx

How to reduce Physical Memory usage in SQL Server

I have 32 GB physical memory server. When I am starting my server its taking 18gb memory when the server and SQL Server 2008 R2 will up. But after few hours SQL Server will be taking up 23gb or more cached size going 4939 or more. What is the cause of this problem and how can I see which queries making this problem?`
SQL loves memory, it'll use what it needs to, especially when caching data. The very nature of caching data is using memory. If your concerned about leaving a little memory for the server or other processes running on your server, then set a max memory amount to SQL.

SQL SERVER 2008 - Memory Leak while storing Millions of records

I need some help very badly.
I'm working on a project where a bulk of data is entered all the time. It's a reporting software.
10 Million records in an average is stored per day and it could keep on increasing as users increase.
As of now, SQL SERVER CONSUMES 5gb of RAM on the task manager. I have an 8GB ram on my server now.
How do other enterprises manage such situations?
SQL Server uses memory efficiently and takes as much as it can. It's also usually clever enough to release memory when needed.
Using 5GB means:
SQL Server is configured to 5GB or SQL Server has simply reserved this memory during normal usage
It's left 3GB because it doesn't need to use it
Nothing is wrong... and I'd probably configure the SQL Server max mem to 6.5GB...
Late addition: Jonathan Kehayias blog entry
SQL Server typically uses as much memory as it can get it's hands on, as it then stores the more frequently accessed data in memory to be more efficient, as disk access is slower then memory access.
So nothing is wrong with it using 5gb of memory.
To be honest, it's leaving 3gb of memory for other applications and the operating system, so there might not be anything wrong with this. (If this is all that server is designed to do.).
To configure the memory limit, do the following:
In SQL Server Enterprise manager, right click on the server name, and go to properties.
Click on the Memory option
Reduce the maximum server memory to what you think is appropriate.
Click ok.
I highly doubt that this is in fact a memory leak. The increase of SQL Server's memory usage is by design, simply because it caches a lot of stuff (queries, procedures).
What you will most likely see is that if the available memory that is still left runs low, SQL server will 'flush' its memory, and you would see in fact that memory will be freed in the end.

MS-SQL Express 2005/2008 multi instance CPU and memory utilization

With SQL Express (either 2005 or 2008 edition) there is a limit of 1GB memory and 1 CPU that can be used. What I'm wondering, is if two instances are installed on the same machine, would they use the same CPU and same 1GB of memory? Or, would they use potentially two different CPU's and 2GB memory?
The limitations are per-instance. Each instance is limited to its own 1 CPU and 1GB RAM.
You can have up to 16 instances of SQL Server Express Edition on a system.
Also in MSDE, the predecessor to SQL Server Express, the limitations were per-instance.
I can't speak for sure, but most likely they would be able to use separate CPUs and memory. It would be pretty tricky for them to coordinate to share memory like that. My suspicion is that each instance will run the same irrespective of other instances being present (at least in the respect you're talking about).
Suppose your system has 4 CPU and suppose 4 GB memory, and 2 instances of sql express, then each express will make utilization of one CPU and 1 GB Memory .
Hope it helps

Resources