标签: memory

我们有一台 256 GB RAM 的机器。
SQL Server 的最大服务器内存设置为 180 GB。

在 180 GB 中，SQL Server 通常使用：

• 数据库缓存内存 - ~ 140-150 GB
• 计划缓存 - ~ 10 GB
• 被盗的服务器内存：~ 30 GB
• 可用内存：~ 9 GB
• 授予的工作空间内存：这通常相当低，峰值可能为 0.5-1 GB

缓冲区高速缓存命中率 - 始终徘徊在 99.9% 以上。
页面预期寿命是相当高的数字。

数据库数据文件的总大小 - 650 GB。
数据增长速度约为每天 500-1500 MB（但是！较旧的数据每 6-8 个月就会删除一次，因此基本上数据文件的增长速度要慢得多）。

问题

需要将SQL Server迁移到另一台机器。当 SQL Server 2022 发布时，就以它为目标。

它是混合 OLTP 和 OLAP 类型的工作负载，许多应用程序使用相同的数据库；大部分 RAM 被缓存的数据库页面使用，这意味着 SQL Server 不必一直从磁盘读取它。

感觉新机器 128 GB 就足够了，最大服务器内存设置为 ~ 110 GB，为操作系统留下 18-13 GB。

目标服务器将位于 Azure VM 中，您无法独立地扩展 …

我目前正在浏览《Pro SQL Server 2019 管理：现代 DBA 指南》，发现一件事让我有些困惑。

在第 5 章：配置实例中，有关最小和最大服务器内存的部分（第 139-140 页）说：

在许多环境中，您可能希望为最小和最大服务器内存提供相同的值。这将避免 SQL Server 动态管理其保留的内存量的开销。

但是，如果您有多个实例，则动态内存管理可能会有所帮助，以便在任何给定时间具有最重工作负载的实例可以消耗最多的资源。

...假设您有一个实例并且没有其他应用程序（例如 SSIS 包）在服务器上运行，您通常会将最小和最大内存设置设置为

• 内存 - 2 GB
• （内存/8）* 7

然而，“为最小和最大服务器内存提供相同的值”的建议与文档相矛盾，文档说：

不建议将最大服务器内存 (MB) 和最小服务器内存 (MB) 设置为相同或接近相同的值。

在什么情况下最好将最大服务器内存和最小服务器内存设置为相同的值？

或者我对建议有什么误解？

我们一直遇到 SQL Server 的内存问题。

当我们开始出现超时和登录错误时，我们首先意识到我们遇到了问题：

已成功与服务器建立连接，但随后在登录过程中出现错误。（提供者：TCP 提供者，错误：0 - 指定的网络名称不再可用。）

在我们的 sqlbox 上查看事件查看器，我们注意到大量内存不足错误：

系统内存不足，无法运行此查询。
有关详细信息，请参阅http://go.microsoft.com/fwlink/events.asp 上的帮助和支持中心。

在此之前唯一的即时警告是以下消息：

AppDomain 119 (Alerts.dbo[runtime].118) 已卸载。

在此之前大约 20 分钟，我们收到了许多与性能相关的消息和错误：

信息：
此计算机上的 Microsoft Operations Manager 代理从其 MOM 服务器收到新规则和配置设置。管理组：GGC

警告：
“ASP”服务的性能库“C:\WINDOWS\system32\aspperf.dll”的配置信息与存储在注册表中的可信性能库信息不匹配。此库中的函数不会被视为受信任的。

错误：
Microsoft Operations Manager 性能提供程序无法访问计算机上的性能计数器等等。Microsoft Operations Manager 不会监视这台计算机上的性能计数器，直到它们可用。

信息：
Microsoft Operations Manager 在上次失败后成功加载了计算机上的性能计数器，并将开始监视它们。

我怀疑上面的性能警报/错误与两个小时的“内存不足异常”有什么关系，但为了以防万一，我已经包含了这些消息。

最后，经过两个小时的红色内存错误后，以下信息消息预示着内存不足警报的结束：

由于“DBCC FREEPROCCACHE”或“DBCC FREESYSTEMCACHE”操作，SQL Server 遇到了 2 次出现“绑定树”缓存存储（计划缓存的一部分）的缓存存储刷新。

所以我们的 DBA 在某个时候调用了 freeprocache。尽管最终修复了内存不足的异常，我们注意到我们的执行计划仍然没有被存储。这个“问题”现在已经持续了整整 3 天，这意味着使用具有复杂计划的查询的应用程序面临着严重的性能困难。在某些情况下，计划开始再次被采用，但它们不会在缓存中停留很长时间。

我想知道是否有人可以帮助确定关注的领域。

A 部分代表查询计划被保留时的系统（计划被保留，但只保留一个小时左右），B 部分代表计划根本没有被缓存（检查 dm_exec_query_stats）

甲部

DBCC MemoryStatus 结果：

Memory Manager   KB 
VM Reserved 1828768 …

我已经安装了 IBM DB2 10.5.5，我想在那里创建一个新数据库。

当我输入命令时

db2 create database test1

我收到一条错误消息

SQL1084C  The database manager failed to allocate shared memory because an 
operating system kernel memory limit has been reached.  SQLSTATE=57019

以下是我运行“ipcs -l”时得到的输出

 ------ Shared Memory Limits --------
max number of segments = 10000
max seg size (kbytes) = 4882812
max total shared memory (kbytes) = 33554432
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 4096
max semaphores per array = 250
max semaphores …

我们的一个 SQL Server 出现了我以前从未见过的问题。

SQL Server（企业版）运行的数据库只有 70MB 的数据。但几个小时后，服务器需要 10 GB 或更多内存。几天后，服务器内存不足。我已经在 SSMS 中配置了最大内存参数，但它没有帮助。

你有什么想法怎么做才能找到问题吗？

这是 dbcc memorystatus 结果的链接：https ://drive.google.com/open ? id = 0B2FJAT6lteKJOEJmUFdqb0ZERFU

数据库版本：Microsoft SQL Server 2014 (SP2-CU5) (KB4013098)。企业版。这是一个虚拟机。

我检查了另一个线程，发现了这个查询：

SELECT TOP (21) [type] = COALESCE([type],'Total'), 
  mb = SUM(pages_kb/1024.0)
FROM sys.dm_os_memory_clerks
GROUP BY GROUPING SETS((type),())
ORDER BY mb DESC;

我在 SQL Server 上运行它并得到以下结果：

1. 总计 = 2452,9
2. CACHESTORE_SQLCP = 2141,5
3. MEMORYCLERK_SQLBUFFERPOOL = 160
4. MEMORYCLERK_SOSNODE = 33
5. USERSTORE_SCHEMAMGR = 30.94

cachestore 的值在它只运行了几个小时后就这么高，这是否正常？

运行此查询：

select value_in_use
from sys.configurations
where name = 'max …

是否可以限制 所使用的系统资源pg_dump？

我有一个使用PostgreSQL数据库的资源相当密集的服务器。它正在运行FreeBSD 10.2。服务器有 8 GB 内存。

我使用以下命令运行备份。

pg_dump -h <address> -U <user> -Fc <database> -f <location>

当备份完成时，相关的 postgres 进程的内存使用量不断上升。仅该进程就达到了 2.2 GB。此时内存几乎已用完并FreeBSD开始杀死进程。

我尝试更改备份的完成方式。例如，我尝试使用多个作业（因此将格式更改为目录）。

pg_dump -j 4 -h <address> -U <user> -Fd <database> -f <location>

没有差异。最终，内存使用量将达到上限并FreeBSD终止数据库备份（以及其他进程）。

我还尝试调整一些系统变量。有管理内核资源和资源消耗。这些影响了服务器使用的正在运行的 postgres 进程，但对进程使用没有影响pg_dump。在 FreeBSD 开始终止进程​​之前，它仍然上升到 2.2 GB。

我已经通读了pg_dump手册，除了多项作业之外，没有真正看到任何有帮助的内容。

此时我不太确定该怎么办。pg_dump有没有办法限制允许使用的资源？我不介意备份是否慢一些。只是不要在系统资源耗尽时操作系统必须开始终止进程​​。

我们在 Amazon 的 RDS 上运行了一个 db.m4.10xlarge 实例。它运行 3 个相当繁忙的数据库，并连接了一个副本实例。

在过去的几周里，我注意到交换空间的使用量一直从 0 稳步上升到现在的 80MB 左右。我不知道为什么它在有足够的空闲（可用？）RAM 时使用交换空间。我在下面列出了过去两周的图表：

同样的事情也发生在复制品上，这是我的另一个担忧，因为我们的复制品滞后正在以类似的方式继续增长。

文档说：

例如：SQL Server 标准版的缓冲池内存限制为 128GB，因此缓冲池中缓存的数据和索引页限制为 128GB。从 SQL Server 2016 SP1 开始，您可以为每个实例的列存储段缓存提供额外的 32GB 内存，并为每个数据库的内存中 OLTP 提供额外的 32GB 内存配额。此外，如果最大服务器内存没有上限，SQL Server 中的其他内存使用者可能会消耗内存，这将受到“最大服务器内存”或服务器上的总内存的限制。

我们正在使用列存储，因此我预计 SQL Server 将受到使用 128+32 Gb 内存的限制。不使用内存优化表。

但实际上超过 215 Gb 用于缓冲池：

内存文员

整个 sql 过程大约需要 300Gb。

从 sys.dm_os_process_memory 中选择 *

最大内存设置为 360Gb。服务器有380Gb。

我错过了什么？

版本：

Microsoft SQL Server 2017 (RTM-CU14) (KB4484710) - 14.0.3076.1 (X64)
2019 年 3 月 12 日 19:29:19 版权所有 (C) 2017 Microsoft Corporation Standard Edition（64 位），Windows Server 2016 Standard 10.0（Build 10.03） :)（管理程序）

更新 (2019-04-26) 有趣的是 - MEMORYCLERK_SQLBUFFERPOOL 由两条记录呈现。第 3 …

（基于磁盘，所以没有 Hekaton）表在内存中的持久化时间是否超过从它们读取数据的查询的生命周期？

如果是这样，是什么决定了它们在内存中停留的时间？

有没有办法管理它们在内存中持续多长时间？

重现问题的步骤

创建具有内存优化文件组和容器的数据库 使用非集群 pk 创建仅模式内存表 模拟插入和删除活动。我的结果是我有高索引未使用的内存，不会下降。

 USE master
 go
 DROP DATABASE IF EXISTS MemoryOptimizedTest
 CREATE DATABASE MemoryOptimizedTest
 GO
 USE MemoryOptimizedTest
 GO
 ALTER DATABASE MemoryOptimizedTest 
 ADD FILEGROUP imoltp_mod CONTAINS MEMORY_OPTIMIZED_DATA
 GO 
 
 ALTER DATABASE MemoryOptimizedTest ADD FILE (name='imoltp_mod1', filename='c:\imoltp_mod1') TO FILEGROUP imoltp_mod
 GO
 
 
 DROP TABLE IF EXISTS dbo.MyCache
 CREATE TABLE dbo.MyCache
 (
    PK int NOT NULL, 
    SecondInt int NOT NULL,
    ThirdInt int NOT NULL,
     CONSTRAINT PK_MyCache PRIMARY KEY NONCLUSTERED (PK)
 ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY)
 
 go

/* Generate activity …