主页 / dba / 问题 / 246804
Accepted
Stockburn
Asked: 2019-09-03 15:30:51 +0800 CST

未知，AppDomain 66 (master.sys[runtime].65) 因内存压力而被标记为卸载

  • 772

我偶尔会在 SQL 错误日志中注意到这个错误：

由于内存压力，spid20s,Unknown,AppDomain 79 (master.sys[runtime].78) 被标记为卸载。

我正在使用 SQL Server 2016，SP1 CU5（我正在推动修补，但该公司反对）。

我读过的所有内容都指向非 CLR 特定的内存压力。有关于更改MemToLeave启动参数中的设置的建议。对于较新版本的 SQL Server 仍然是这种情况，还是有其他建议？

sql-server sql-server-2016

2 个回答

  1. Best Answer

    SQL Server 2012 中的内存架构发生了变化，因此无需再担心MemToLeave设置，尤其是在使用 64 位 SQL Server 时。而且，从 SQL Server 2016（您正在使用）开始，SQL Server 仅提供 64 位版本（请参阅“数据库引擎中的新增功能 - SQL Server 2016 ”页面顶部的“注释” ）。所以，不，不用担心MemToLeave。

    正确，“内存压力”错误并非特定于 SQLCLR。这些错误并没有告诉您内存压力的原因，而是告诉您内存压力会影响什么（我怀疑是否有任何可能的方法可以真正了解原因 - 我的意思是，如果有 10 个进程占用内存，哪个组合才是真正的原因？不一定是占用最大块的原因，因为这可能是完全有效的）。内存压力也会影响其他可能不会出现在错误日志中的区域，例如刷新计划缓存和/或缓冲池（即加载到内存中的数据页）。

    有几个使用 SQLCLR 的内置功能，部分列表如下：

    • 数据类型：
      • 层次 ID
      • 地理
      • 几何学
    • 功能：
      • FORMAT
      • PARSE
      • TRY_PARSE
      • AT TIME ZONE（从 SQL Server 2016 开始）
      • COMPRESS（但不是UNCOMPRESS；从 SQL Server 2016 开始）
    • 特征：
      • 变更数据捕获
      • 动态管理框架
      • 复制
      • 基于策略的管理
      • 主数据服务
      • SSISDB（“模糊查找”功能）

    其中一项或多项（或者可能是我在上面未列出的一项）是您系统中受到影响的内容。有两条线索，都在该(master.sys[runtime].78)信息的一部分中，告诉我们这一点：

    1. 数据库是master（假设您永远不会将自定义程序集加载到master;-)）

    2. 程序集的“所有者”（即AUTHORIZATION）是sys（我们不能将程序集的所有权分配给任何一个sys或INFORMATION_SCHEMA因为这些主体都没有SID）。如果要查看每个程序集的所有者，请执行以下操作：

      SELECT asm.[name] AS [Assembly],
       USER_NAME(asm.[principal_id]) AS [Owner],
       USER_SID(asm.[principal_id]) AS [OwnerSID]
FROM   sys.assemblies asm;

    你可以做的是：

    1. 您提到此错误“偶尔”出现，但并未准确定义此错误的频率。每小时一次不同于每天一次，每天一次不同于每周一次。内存压力会发生，所以除非每天超过几次，否则我不会花太多时间担心它。
    2. 添加更多内存（物理上和/或允许 SQL Server 使用更多的系统内存，如果您当前将 SQL Server 限制在较少的数量）
    3. 分析在 SQL Server 之外消耗内存的内容，以查看服务器上是否有可以卸载到其他服务器的不必要进程，或者可能完全关闭（即是否正在使用其他服务和/或远程桌面会话）然后运行使用大量内存的 SSMS 等？）
    • 11

  2. 可能会调查一下： https ://learn.microsoft.com/en-us/sql/relational-databases/memory-management-architecture-guide 。特别是查询当前分配的内容。它会给你一个专注于诊断的地方。

    我以前也遇到过这个问题，它最终被重复调用一个 CLR 过程，它在完成后永远不会关闭。

    • 7

相关问题