36、服务器CPU与内存监控全解析

服务器CPU与内存监控全解析

在服务器的运维管理中，CPU和内存的监控至关重要，它们的性能直接影响着服务器的整体运行效率和稳定性。本文将详细介绍如何监控服务器的CPU和内存，以及相关的关键指标和操作方法。

1. 监控CPU

1.1 Windows计数器

• % Processor Time ：该指标反映了服务器CPU的使用率。理想情况下，服务器的CPU使用率应保持在20% - 50%的范围内。偶尔的使用率高峰是正常的，但如果CPU使用率持续超过80%，就需要找出导致CPU使用率上升的进程，因为这可能意味着即将出现CPU瓶颈。
• % Privilege Time ：此计数器用于识别内核或系统进程对服务器的影响。系统进程的执行应消耗不到总CPU的30%。如果该值持续超过30%，可能表示某个Windows服务出现了问题。
• Context Switches/Sec ：它记录了SQL Server线程在处理器之间切换的次数。每秒超过5000次的上下文切换可能会对CPU造成较大负担，但在做出判断之前，还需要参考其他计数器，如Processor Queue Length和Compilations/Sec。同时，服务器的基线数据也是一个重要的参考，通过跟踪基线数据的变化，可以及时发现系统性能的逐渐变化。
• Processor Queue Length ：该计数器显示了等待处理器资源进行处理的就绪线程数量。每个处理器的就绪线程数超过2个时，就应该对CPU进行调查，因为这意味着进程在等待运行机会，可能会影响应用程序处理请求的速度。

1.2 SQL Server计数器

• Batch Requests/Sec ：用于衡量SQL Server实例接收到的批处理请求数量，通常代表了SQL Server的活动水平。每秒批处理请求数超过1000的服务器通常负载较重，虽然繁忙的数据库服务器不一定是坏事，但可能会导致CPU问题。因此，需要对服务器进行基线评估，并密切关注该指标。
• SQL Compilations/Sec ：表示SQL Server实例上发生的编译次数。SQL Server在首次执行查询时会生成编译并将执行计划存储在过程缓存中。如果应用程序频繁执行即席查询，无法重用执行计划，就会导致CPU使用率增加。SQL Server的编译次数应低于批处理请求数的10%，否则可能表示应用程序没有充分利用执行计划的重用。
• SQL Recompilations/Sec ：代表SQL Server实例上发生的重新编译次数。重新编译通常是由于统计信息更新、架构更改、执行计划使用的索引更改或指定重新编译选项等原因引起的，这是一个CPU密集型过程，尤其是对于复杂查询。SQL Server的重新编译次数应低于编译次数的10%，如果超过该阈值，需要找出重新编译的原因，特别是在应用程序升级后。

1.3 使用计数器组合识别CPU瓶颈

在使用Windows计数器时，可以将多个计数器的结果结合起来，以更准确地识别CPU瓶颈。当CPU使用率持续超过80%，且处理器队列长度超过阈值时，就需要进一步调查CPU，确保不是SQL Server导致了CPU瓶颈。在建议购买额外的CPU之前，可以参考相关方法来识别消耗大量CPU的查询，并尝试优化这些查询的性能。

1.4 用于监控CPU的动态管理视图（DMVs）

SQL Server提供了多个用于监控CPU的动态管理视图，理解线程、工作线程、调度程序和任务之间的关系对于理解这些视图至关重要。具体关系如下：
1. SQL Server启动时会生成多个线程，并将工作线程与之关联。
2. 查询或批处理会被拆分为一个或多个任务。
3. 任务在查询或批处理的执行期间被分配给一个工作线程。
4. 工作线程被分配给一个调度程序，每个调度程序对应一个处理器来运行。

以下是一些重要的DMV及其作用：
- sys.dm_os_threads ：列出SQL Server启动时创建的线程信息，可用于监控可执行文件内的失控线程，并为其他CPU DMV提供关联信息。
- sys.dm_os_workers ：提供SQL Server内分配给线程的工作线程的信息。当工作线程准备运行时，它会移动到可运行队列的前端并尝试运行最多1000次，之后会移动到队列的末尾。该视图还返回有关工作线程的各种信息，如执行的任务数量、工作线程的状态、使用的IO等。以下是一个常用的查询示例，用于比较工作线程的活动时间和挂起时间：

SELECT tl.session_id,tl.status,tl.command AS command,
t2.state AS worker_state,
w_suspended = CASE t2.wait_started_ms_ticks
WHEN 0 THEN 0 ELSE t3.ms_ticks - t2.wait_started_ms_ticks END,
w_runnable = CASE t2.wait_resumed_ms_ticks WHEN 0 THEN 0 ELSE t3.ms_ticks -
t2.wait_resumed_ms_ticks END  
FROM sys.dm_exec_requests AS tl INNER JOIN sys.dm_os_workers AS t2
ON t2.task_address = tl.task_address CROSS JOIN sys.dm_os_sys_info AS t3  
WHERE tl.scheduler_id IS NOT NULL and session_id> 50  -- Identifies non - system processes

• sys.dm_os_schedulers ：列出调度程序和分配给它们的工作线程的信息。该视图包含多个重要列，如每个调度程序关联的工作线程数量、等待调度程序时间的工作线程数量等。监控该视图可以及时发现调度程序与基线数据的偏差，因为等待调度程序时间的工作线程数量增加会增加CPU瓶颈的可能性。以下是一个用于收集调度程序统计信息的查询示例：

SELECT scheduler_id,parent_node_id,current_tasks_count, runnable_tasks_count,
current_workers_count, active_workers_count, work_queue_count, load_factor  
FROM sys.dm_os_schedulers  
WHERE scheduler_id < 255  -- Identifies Schedulers that are --used by regular queries

• sys.dm_os_tasks ：提供SQL Server实例内每个活动任务的信息，包括任务执行的物理IO、任务状态、任务运行的调度程序等。还可以通过该视图找出导致任务创建的查询或批处理。以下是一个示例查询：

SELECT r.session_id,task_state,pending_io_count, r.scheduler_id,command,cpu_time,
total_elapsed_time,sql_handle  
FROM sys.dm_os_tasks t
join sys.dm_exec_requests r on t.request_id = r.request_id and t.session_id = r.session_id  
WHERE r.session_id > 50 -- Identifies non - system processes

此外，sys.dm_exec_query_optimizer_info DMV可以捕获SQL Server优化器的信息，帮助确定编译对系统的成本。同时，sys.dm_exec_requests中的cpu_time列可用于按CPU时间对当前运行的查询进行排序，以找出使用最多CPU的查询；sys.dm_exec_stats中的total_worker_time列可用于找出一段时间内使用最多CPU的查询。

2. 监控内存

2.1 SQL Server的内存使用情况

SQL Server在处理每个查询时都需要使用内存。如果请求的数据页不在内存或缓冲池中，SQL Server会从物理磁盘中检索这些页并加载到内存中。为了减少物理磁盘IO，SQL Server会尽量将频繁访问的页保留在内存中，并使用最近最少使用（LRU）算法来决定哪些内存页应该被移除。如果内存不足，SQL Server会移除频繁访问的页，这会导致磁盘IO增加和查询执行时间延长。

此外，SQL Server还使用内存来存储内部结构，如连接、执行计划和各种内部进程。内存问题会影响这些内部结构，进而影响服务器的性能。例如，内存不足时，SQL Server可能会移除执行计划，导致后续查询需要重新编译，增加CPU的负担。

2.2 关键内存计数器及推荐值

计数器名称	描述	推荐值
Memory: Pages Input/Sec	为解决硬页错误从磁盘读取页的速率	< 10 Pages
Memory: Available MBytes	服务器上的可用内存	> 300 MB
Memory: Pages/Sec	写入或读取磁盘的页数	< 100
Memory: Page Faults/Sec	每秒平均发生的硬页和软页错误数	使用基线数据
Memory: Page Reads/Sec	为解决页错误从磁盘读取页的速率	< 5
SQL Server Buffer Manager: Buffer Cache Hit Ratio	在缓冲池中找到页而无需访问磁盘的百分比	> 90（接近99%）
SQL Server Buffer Manager: Checkpoint Pages/Sec	通过检查点或其他方法每秒刷新到磁盘的页数	使用基线数据确定推荐值
SQL Server Buffer Manager: Page Life Expectancy	页在缓冲池中允许保留的时间（秒）	> 300
SQL Server Buffer Manager: Lazy Writes/Sec	惰性写入程序进程每秒将脏页从缓冲区移动到磁盘的次数	> 30
SQL Server Memory Manager: Memory Grants Pending	等待工作区内存的进程数量	应接近零
SQL Server Memory Manager: Target Server Memory	SQL Server希望拥有的内存量	高值或上升值表示内存压力
SQL Server Memory Manager: Total Server Memory	近似的服务器内存	服务器RAM

2.3 使用任务管理器监控内存

可以使用任务管理器来快速监控内存。在任务管理器的性能选项卡中，查看物理内存部分，即可了解可用内存的情况。如果可用内存少于100MB，就需要评估是哪些应用程序消耗了大量内存。可以切换到进程选项卡，按内存使用列对数据进行排序，从而找出内存密集型应用程序。

2.4 使用Windows计数器监控内存

• Available MBytes ：该计数器表示服务器上剩余的可用内存（以MB为单位）。它是零化、空闲和备用内存列表中的空间总和。由于该计数器表示的是最后一次观察到的值，而不是平均值，因此需要长时间监控该值，以确保服务器不会出现内存不足的情况。如果运行SQL Server的服务器上同时运行多个应用程序，且内存持续低于期望的阈值，可以考虑将这些应用程序迁移到其他服务器。因为SQL Server在内存不足的情况下性能会受到影响，所以需要密切监控该阈值。

通过以上对CPU和内存的监控方法和关键指标的了解，我们可以更好地管理服务器的性能，及时发现并解决潜在的问题，确保服务器的稳定运行。

总结

服务器的CPU和内存监控是一个复杂而重要的工作，需要综合使用多种方法和工具。通过对关键计数器和动态管理视图的监控，我们可以及时发现性能瓶颈，并采取相应的措施进行优化。在实际操作中，建议定期收集和分析服务器的性能数据，建立服务器的性能基线，以便更好地判断服务器的运行状态。同时，要注意多个指标之间的关联，避免只关注单一指标而忽略了其他潜在的问题。希望本文介绍的方法和技巧能够帮助你更好地监控和管理服务器的CPU和内存性能。

服务器CPU与内存监控全解析（续）

3. 综合监控与问题排查流程

为了更高效地监控服务器的CPU和内存，我们可以建立一个综合的监控与问题排查流程。以下是一个简化的 mermaid 流程图，展示了这个流程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始监控]):::startend --> B{CPU使用率是否持续>80%}:::decision
    B -->|是| C{处理器队列长度是否超阈值}:::decision
    C -->|是| D(调查CPU瓶颈原因):::process
    D --> E{是否为SQL Server导致}:::decision
    E -->|是| F(优化SQL查询):::process
    E -->|否| G(检查其他系统进程):::process
    B -->|否| H{内存可用MB是否<300MB}:::decision
    H -->|是| I(评估内存消耗应用):::process
    I --> J{是否可迁移应用}:::decision
    J -->|是| K(迁移内存密集型应用):::process
    J -->|否| L(增加服务器内存):::process
    H -->|否| M(继续监控):::process
    F --> M
    G --> M
    K --> M
    L --> M
    M --> A

这个流程首先检查 CPU 使用率，如果持续超过 80% 且处理器队列长度超过阈值，就开始调查 CPU 瓶颈的原因。确定是否是 SQL Server 导致的瓶颈后，分别采取优化 SQL 查询或检查其他系统进程的措施。如果 CPU 使用率正常，则检查内存可用量，如果低于 300MB，就评估内存消耗应用，并根据情况决定是否迁移应用或增加服务器内存。最后，无论采取何种措施，都继续进行监控，形成一个闭环的监控与问题排查系统。

4. 监控的最佳实践

4.1 建立基线数据

定期收集服务器的性能数据，建立 CPU 和内存使用的基线。基线数据可以反映服务器在正常运行状态下的性能指标，帮助我们更准确地判断服务器是否出现异常。例如，通过对比当前的上下文切换次数与基线数据，我们可以及时发现系统性能的逐渐变化。

4.2 多指标综合分析

不要只关注单一的计数器或指标，而是要综合考虑多个指标。例如，在判断是否存在 CPU 瓶颈时，不仅要关注 CPU 使用率，还要结合处理器队列长度、上下文切换次数等指标。同样，在监控内存时，要同时关注多个内存计数器，如可用内存、页输入/输出速率等。

4.3 自动化监控与报警

使用自动化监控工具，如 PerfMon 等，定期收集和分析服务器的性能数据。设置合理的报警阈值，当指标超过阈值时及时发出警报，以便管理员能够及时处理问题。例如，当 CPU 使用率持续超过 80% 或内存可用量低于 100MB 时，自动发送邮件或短信通知管理员。

4.4 定期审查与优化

定期审查服务器的性能数据，根据分析结果对服务器进行优化。例如，根据 SQL Server 的编译和重新编译次数，优化应用程序的查询，减少不必要的编译和重新编译。同时，根据内存使用情况，调整 SQL Server 的内存配置，确保服务器有足够的内存来处理请求。

5. 常见问题及解决方案

5.1 CPU 使用率过高

• 问题表现 ：CPU 使用率持续超过 80%，服务器响应变慢，应用程序处理请求的速度下降。
• 可能原因 ：SQL Server 查询复杂、系统进程异常、硬件资源不足等。
• 解决方案 ：使用 DMV 找出消耗大量 CPU 的查询，优化 SQL 查询；检查系统进程，关闭不必要的服务；如果硬件资源不足，考虑升级 CPU 或增加服务器数量。

5.2 内存不足

• 问题表现 ：磁盘 IO 增加，查询执行时间延长，SQL Server 频繁重新编译查询。
• 可能原因 ：应用程序内存泄漏、SQL Server 内存配置不合理、服务器上运行过多的应用程序等。
• 解决方案 ：使用任务管理器找出内存密集型应用程序，优化应用程序代码，避免内存泄漏；调整 SQL Server 的内存配置，确保其有足够的内存；如果服务器上运行过多的应用程序，考虑迁移部分应用到其他服务器。

5.3 上下文切换频繁

• 问题表现 ：CPU 负担加重，系统性能下降。
• 可能原因 ：SQL Server 线程调度不合理、硬件资源不足等。
• 解决方案 ：参考其他计数器，如处理器队列长度和编译次数，判断上下文切换是否正常；如果硬件资源不足，考虑升级 CPU 或增加服务器数量。

总结与展望

通过本文的介绍，我们详细了解了服务器 CPU 和内存的监控方法、关键指标以及问题排查和优化的技巧。监控服务器的 CPU 和内存是确保服务器稳定运行的关键，需要我们综合运用多种方法和工具，建立完善的监控体系。

在未来，随着服务器技术的不断发展，监控的方法和工具也会不断更新和完善。例如，人工智能和机器学习技术可能会被应用到服务器监控中，实现更智能的性能预测和问题诊断。同时，随着云计算和容器化技术的普及，服务器的监控也将面临新的挑战和机遇。我们需要不断学习和掌握新的技术，以适应不断变化的服务器环境，确保服务器的高效运行。

希望本文能够帮助你更好地监控和管理服务器的 CPU 和内存性能，如果你在实际操作中遇到任何问题，欢迎随时交流和探讨。