标签: memory

我正在考虑扩大规模而不是扩大规模。因此，我很想知道将 MySQL 内存存储引擎用于 500+ GB 的数据库是否可行，因为有一台服务器，具有这种内存？我应该提到对表的查询主要是临时查询。

我相信我发现会出现的一个问题是对 MEMORY 表的查询可能会导致创建临时表。临时表在转换为 MyISAM 表之前有一个硬性限制，即最多使用4 GB的 RAM。这当然会完全杀死性能。临时表的内存限制可以通过将tempdir设置为 ramdisk 来解决。

您还预见到哪些其他类型的问题？

我有一个在生产系统上运行的 SQL Server 2008 R2 实例。我不是 DBA；我更像是一名开发人员，但我的客户目前问我：将内存从 SQL Server 释放回服务器有多重要？如果我们将内存释放回操作系统，是否会影响对实例的后续查询的性能？

我正在运行 Litespeed（使用 suExec、PHP SAPI）、MySQL、DirectAdmin，在具有 16 核 Xeon CPU 和 2GB RAM 的 VPS 上命名。

目前，仅使用了 2048 个中的 300 MB。这听起来可能很愚蠢，但是如何让 vps 使用更多 RAM？

我的.cnf：

[client]
port            = 3306
socket          = /var/lib/mysql/mysql.sock


[mysqld]
port                                            = 3306
socket                                          = /var/lib/mysql/mysql.sock
skip-locking
key_buffer                                      = 512M
max_allowed_packet                              = 8M
table_cache                                     = 4096
sort_buffer_size                                = 16M
read_buffer_size                                = 8M
join_buffer_size                                = 2M
read_rnd_buffer_size                    = 32M
myisam_sort_buffer_size                 = 128M
myisam_repair_threads                   = 1
myisam_recover
max_heap_table_size                             = 8M
tmp_table_size                                  = 8M
thread_cache_size                               = 8
thread_concurrency                              = 8
query-cache-type …

我们有一个似乎正在泄漏内存的 SQL 服务器。内存消耗会随着时间线性增加，直到服务器完全耗尽内存，从而导致严重的性能问题。

SQL 服务器包含 6 个小型（平均超过 50MB）数据库和一个稍大一些（大约 2GB）的数据库。

该服务器目前是 VMware 5.1 中的虚拟服务器。它的平均工作负载非常轻（~1% cpu，<10 批请求/秒，< .5 mb/s IO 典型；峰值推到~10% cpu，300 批请求/秒，5 mb/s IO）。

目前，它有 8GB 分配给 VM。其中，4GB 设置为 SQL Server 中的最大服务器内存。但是，SQL 服务器进程使用的内存远不止于此——通常在重新启动后的 12 小时内使用大约 6GB。

除了主要的读取工作负载外，该服务器还运行许多 SSIS 包，以将数据传入和传出到公司结构内的其他系统。这利用 MySQL 通过 ODBC（安装了 5.2.6 驱动程序）连接到内部 MySQL 集群和 ConnX 以连接 OpenVMS 系统。

操作系统：Windows 2012 SQL：2012 Enterprise VM 设置：4 个 CPU 内核，8GB，用于操作系统、数据和日志的独立虚拟卷。

问题： 1) 关于为什么 SQL Server 进程不会遵循服务器上设置的限制的任何想法？2) 有没有人知道在 SQL Server 中分析内存使用情况的好方法？我们可以看到页面预期寿命正在下降，更多的内存被分配给进程，但是有什么方法可以查看 SQL 将内存分配给什么（即过程缓存、缓存结果等）。

我的笔记本电脑上有 6GB 的 RAM，为了进行测试，我在 PostgreSQL 9.3 中创建了一个 5000 万行的表。然后我想在表上创建一个索引。

表和结果索引一起（或表总大小的两倍）可以放入 5GB 的 RAM，我设置maintenance_work_mem为 5GB，仍然CREATE INDEX使用外部排序和大约 1.4GB 的临时文件。为什么呢？

我对它应该能够在 RAM 中进行排序的期望是不合理的吗？

test=# set maintenance_work_mem to '5GB';
SET
test=# create table t1 as (select i::int, random() as f from generate_series(1, 50000000) i);
SELECT 50000000
test=# select pg_size_pretty(pg_relation_size('t1'));
 pg_size_pretty 
----------------
 2111 MB
(1 row)

test=# create index on t1(f, i);
CREATE INDEX
test=# select pg_size_pretty(pg_relation_size('t1_f_i_idx'));
 pg_size_pretty 
----------------
 1504 MB
(1 row)

在服务器日志中：

LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp22623.1", size 1073741824 …

我知道这样做不是很好的做法，但我的公司负担不起我试图为我们的问题找到合适的解决方案。我读过这篇文章，我可以用 SQL Server 2005 做同样的事情，但我希望有更好（更快？）的方法。

问题如下：

我们有一个在 Windows Server 2003 上运行的 ASP.net 网站 (ASP2)，它也托管我们的 SQL Server 2005 数据库并安装。

最近，我们注意到 SQL Server 2005 实例的 VM 已提交内存空间增长，几乎达到了我们设置为 1.7 GB 的 VM 保留空间（嗯太多了？）。

运行 SQL Server 的 PC 服务器有 4 GB 的 RAM 和最多 3.5 GB 的可用磁盘空间，用于 SQL Server 2005 安装。数据库本身在 350 GB 共享上（有两个分区：分别是 C 和 D 驱动器）。

因此，在 VM 空间方面，我原以为我们有足够的空间并且将 VM 限制设置为 1.7 GB（理想情况下为 2 GB）就足够了。

数据库本身的大小不到 500 MB。

当我们的 VM Committed 值接近 VM Reserved 值时，服务会显着减慢。我知道的唯一方法是停止所有 SQL 服务服务并重新启动它们。但是在 24 小时内，VM …

在工作中，我们遇到了一个问题，现在已经发生了不止一次。

问题是查询处于将 HEAP 转换为 MyISAM 的状态并且它使我们的服务器瘫痪（在这种状态下的查询无法自我终止，并且只有在我们的案例中似乎需要 FOREVER 的操作之后才会评估终止标志）

以下全局 MYSQL 变量出现在我们面前：

| tmp_table_size      | 17179869184 |
| max_heap_table_size |  8589934592 |

任何想法我们应该做什么？

我们是否应该调整 tmp_table_size 和 max_heap_table_size 的大小以具有相同的值？

那会有帮助吗？

我想知道为什么 SQL Server 不使用所有可用内存 - 当我非常确定存在内存瓶颈时 100%。比如我管理的一台服务器，从使用91%的内存开始，逐渐增加到98而不是100。23:00重启后增加趋势如下：

1. 重启后为 58%，整晚达到 79%。我想这应该是由于采取了隔夜备份。
2. 到第二天 11:00 时为 82%。
3. 12:00 前 90%
4. 全天稳定趋势，直到 23:00 内存利用率增加到 93%
5. 95% 次日早上 08:00
6. 97% 在 17:00
7. 98% 第二天 14:00 并留在那里。

什么可能导致这 2% 未被利用？Windows 操作系统是否有可能阻止它？如果是这样，我如何证明 Windows 确实将其保留给自己？

我指的是服务器的整体内存使用情况 - 即操作系统。最大内存配置已经设置得远远超出服务器的当前内存。我手头有一个用于跟踪内存利用率的监控工具。

服务器的内存利用率不低于或高于 98%。这是一个专用的、单实例的、两个数据库 SQL Server，没有其他服务、应用程序等在其上运行。SQL Server 可能正在使用大部分分配的内存 - 即 98% - 但我的问题是为什么它不使用其余的 2%？我不确定我在质疑那 2% 时是否变得太暴躁了？

感谢在Monitor memory usage 中查询Determining Current Memory Allocation我确认 Memory_usedby_Sqlserver_GB 是 64 GB 总 RAM 中的 60。我无法在DMV的输出中找到RAM 和总 RAM的列（可能是由于 SQL Server 2008 R2），但我可以确认它是 64 …

假设我们有两个客户使用的实例：我和我的朋友 Ivan。我们每个人都有自己的数据库。我们每个人都只是在读书。

我是个坏人，所以我无情地对数据库进行表扫描。我的表也很大，所以它们不适合内存。Ivan 是个好人，所以他的所有查询都包含在一个索引中，所以他根本没有理由访问磁盘。

他会注意到任何问题吗？

AFAIK，我将有一堆线程SUSPENDED处于等待磁盘的状态，否则不会产生太多负载，因此 Ivan 应该会做得很好。

我的问题是，对于具有 TB 级 RAM 的实例，SQL Server 需要很长时间来增加它的内存使用量，同时我们会间歇性地等待 MEMORY_ALLOCATION_EXT，这会减慢我们的处理速度，直到 SQL Server 达到其最大内存。

我们有 SQL Server 2019 企业版的故障转移群集实例 (FCI)，节点上有数 TB 的内存。在通常的用例中，我们只允许每个节点有 1 个 SQL Server 实例，因此我们将最大服务器内存设置为接近节点内存的 85%，但我们也将最小服务器内存设置得相对较低，以防 SQL Server 发生故障到另一个节点，并且需要在减少内存占用的情况下联机才能跛行。

• 我很清楚，如果我将最小内存设置得更高，SQL Server 将一次消耗所有内存。原来 SQL Server 在启动时不会分配最小内存。
• 我知道 SQL Server 会在需要时从操作系统动态消耗更多内存，最终它将达到最大服务器内存。
• 我知道运行一个大查询或 DBCC checkdb 来提取大量数据将迫使 SQL Server 从操作系统消耗更多内存。

有没有其他方法可以强制 SQL Server 快速增加其内存使用量？