oracle iis coldfusion 障害調査めも

Last updated at 2025-02-27Posted at 2025-02-18

APサーバーまたはDBサーバーのCPUやメモリ使用率が90%-100%に急上昇した場合、以下の方法で原因を特定できます。

データベース（DB）側の調査

リソースを大量に消費しているSQLを特定

SELECT sql_id, sql_text, elapsed_time, cpu_time, executions
FROM v$sql
WHERE elapsed_time > (SELECT AVG(elapsed_time) * 2 FROM v$sql)
ORDER BY elapsed_time DESC
FETCH FIRST 10 ROWS ONLY;

長時間実行されているSQLを特定できます。

現在のアクティブセッションを確認

SELECT sid, serial#, username, status, blocking_session, event, wait_class
FROM v$session
WHERE status = 'ACTIVE';

大量のアクティブセッションが発生しているかどうかを確認します。

CPU消費の多いSQLを特定

SELECT sql_id, cpu_time, sql_text
FROM v$sql
ORDER BY cpu_time DESC
FETCH FIRST 10 ROWS ONLY;

CPU使用率が高いSQLを特定できます。

ロックやデッドロックを確認

SELECT blocking_session, sid, serial#, wait_class, event
FROM v$session
WHERE blocking_session IS NOT NULL;

ブロッキングセッションがある場合、ロックが発生している可能性があります。

Oracleのアラートログを確認

alert_.log をチェック。

ORA-エラー、ディスクI/Oの問題が発生していないか確認。

APサーバー（IIS + ColdFusion）側の調査

IISの負荷を確認

w3wp.exe プロセスのCPU・メモリ使用率を確認（タスクマネージャー or リソースモニター）。

IISのログ（C:\inetpub\logs\LogFiles\W3SVC1\）を確認し、大量アクセスがないか調査。

ColdFusionのパフォーマンス監視

cf.exe プロセスのCPU・メモリ使用率を確認。

ColdFusion管理コンソールで、スロークエリやスレッドの状態をチェック。

異常なHTTPリクエストを確認

高頻度のリクエストがあるかログを分析：

findstr /i "500" C:\inetpub\logs\LogFiles\W3SVC1*.log

特定のURLへの異常なアクセスが集中していないか確認。

OSレベルの調査

Windowsのシステムログを確認

イベントビューアー（eventvwr.msc） → Windowsログ → アプリケーションとシステムを確認。

ディスクI/Oのボトルネックを確認：

perfmon

LogicalDisk の % Disk Time が高すぎないかチェック。

タスクマネージャーやリソースモニターで確認

どのプロセスがCPU・メモリを消費しているか特定。

w3wp.exe や cf.exe の使用率が高ければアプリケーションの問題。

oracle.exe の使用率が高ければDBのクエリ負荷が原因。

その他の可能性

自動実行タスクの影響

Windowsタスクスケジューラー（taskschd.msc）を確認。

DB内の DBMS_SCHEDULER ジョブが実行されていないか確認。

ネットワークの問題

netstat -ano を使用し、大量のTCP接続がないか確認。

ping や tracert でネットワーク遅延をチェック。

まとめ

DBのSQL負荷を最優先でチェック（重いSQL、アクティブセッション、ロック）。
APサーバーのIIS・ColdFusionのログを確認（異常リクエストの有無）。
Windowsのシステムログやタスクマネージャーを活用し、どのプロセスが原因か特定。
IISやColdFusionのモニタリングツールを使い、リクエストの状況を詳しく調査。

まずはDB側のSQL負荷を調べ、次にAPサーバーのログとWindowsのイベントログを分析するのが効率的です。

当 AP 服务器或 DB 服务器的 CPU 或内存使用率突然升高到 90%-100% 时，可以从以下几个方面排查原因：

检查数据库（DB）端

查找高资源占用 SQL

SELECT sql_id, sql_text, elapsed_time, cpu_time, executions
FROM v$sql
WHERE elapsed_time > (SELECT AVG(elapsed_time) * 2 FROM v$sql)
ORDER BY elapsed_time DESC
FETCH FIRST 10 ROWS ONLY;

这个 SQL 可以找出执行时间较长的 SQL 语句。

检查当前活动会话

SELECT sid, serial#, username, status, blocking_session, event, wait_class
FROM v$session
WHERE status = 'ACTIVE';

看是否有大量活动会话在等待资源。

检查哪些 SQL 占用最多 CPU

SELECT sql_id, cpu_time, sql_text
FROM v$sql
ORDER BY cpu_time DESC
FETCH FIRST 10 ROWS ONLY;

这可以帮助找出 CPU 消耗最高的 SQL 语句。

监控锁和死锁

SELECT blocking_session, sid, serial#, wait_class, event
FROM v$session
WHERE blocking_session IS NOT NULL;

如果有锁等待情况，可能导致查询性能下降。

检查 Oracle 警告日志

位置通常在 alert_.log

可能包含 ORA- 错误、磁盘 I/O 问题等信息。

检查 AP 服务器（IIS + ColdFusion）

IIS 负载分析

打开任务管理器或资源监视器，查看 w3wp.exe 进程的 CPU 和内存占用情况。

查看 C:\inetpub\logs\LogFiles\W3SVC1\ 目录下的 IIS 日志，看是否有大量请求。

ColdFusion 性能

监控 cf.exe 进程的资源使用情况。

访问 ColdFusion 管理控制台，查看慢查询日志和线程状态。

是否有异常 HTTP 请求

通过日志分析是否有某些 URL 请求特别多，比如：

findstr /i "500" C:\inetpub\logs\LogFiles\W3SVC1*.log

过滤出高频访问的 URL，看看是否有异常流量攻击或无效请求。

系统级别排查

Windows 系统日志

事件查看器（eventvwr.msc） → Windows 日志 → 应用程序和系统，查看是否有异常事件。

查找磁盘 I/O 瓶颈：

perfmon

查看 LogicalDisk 相关指标，如 % Disk Time 是否过高。

使用 Resource Monitor 或 Task Manager

确定是哪个进程占用了 CPU 和内存。

如果 w3wp.exe 或 cf.exe 进程占用高，可能是应用层问题。

如果 oracle.exe 占用高，可能是 SQL 查询导致。

其他可能性

是否有自动任务在运行

检查 Windows 任务计划程序（taskschd.msc）。

检查数据库的 DBMS_SCHEDULER 任务是否正在执行。

网络连接问题

使用 netstat -ano 检查是否有大量 TCP 连接。

运行 ping 或 tracert 看是否有网络延迟问题。

总结

优先检查数据库 SQL 负载（高消耗 SQL、活跃会话、锁）。
分析 AP 服务器日志（IIS/ColdFusion 请求是否异常）。
查看 Windows 系统日志和任务管理器，确定是 AP 端还是 DB 端导致资源占满。
结合 IIS 和 ColdFusion 监控工具，排查 Web 应用请求情况。

你可以先看数据库 SQL 是否占用过多资源，然后结合 AP 服务器日志和 Windows 事件日志，快速缩小排查范围。

当AP服务器或DB服务器的CPU或内存使用率突增到90%-100%时，需通过以下多维度排查定位问题：

一、AP服务器排查流程

1. 确定资源占用进程

任务管理器/资源监视器：
- 打开任务管理器，按CPU或内存排序，定位高负载进程（如w3wp.exe对应IIS工作进程、ColdFusion进程）。
- 使用资源监视器（resmon）查看磁盘、网络、句柄等关联资源。

2. 分析IIS及ColdFusion

IIS日志分析：
- 路径：C:\inetpub\logs\LogFiles
- 检查请求量激增的时段、响应时间（time-taken字段）、HTTP错误（5xx/4xx），筛选耗时长的请求（如time-taken>5000表示5秒以上）。
ColdFusion日志：
- 检查coldfusion-out.log和coldfusion-error.log，定位应用异常（如死循环、内存泄漏）。
- 使用ColdFusion Admin监控请求队列、内存使用及JVM状态。

3. Windows系统级排查

性能监视器（PerfMon）：
- 添加计数器：Processor(_Total)\% Processor Time（总CPU）、Process(*)\% Processor Time（进程级CPU）、Memory\Available MBytes（内存）。
- 关注ASP.NET Applications\Requests/Sec和Requests in Application Queue（IIS请求堆积）。
事件查看器：
- 检查系统日志（Windows Logs -> System）和应用日志，筛选警告或错误事件（如硬件故障、驱动问题）。

二、DB服务器排查流程

1. 实时会话与SQL分析

查询活跃会话：

SELECT sid, serial#, username, status, sql_id, event, program 
FROM v$session 
WHERE status = 'ACTIVE';

高负载SQL定位：

SELECT sql_id, sql_text, executions, cpu_time/1e6 "CPU_sec", elapsed_time/1e6 "Elapsed_sec", disk_reads
FROM v$sql 
ORDER BY cpu_time DESC 
FETCH FIRST 10 ROWS ONLY;

关注高CPU_TIME、EXECUTIONS或DISK_READS的SQL。

2. 检查锁与等待事件

锁阻塞分析：

SELECT blocker.sid, blocker.sql_id, waiter.sid AS blocked_sid
FROM v$session blocker, v$session waiter
WHERE blocker.sid = waiter.blocking_session;

等待事件：
```
SELECT event, COUNT(*) AS sessions 
FROM v$session 
WHERE status = 'ACTIVE' 
GROUP BY event 
ORDER BY sessions DESC;
```
- 常见问题事件：db file sequential read（索引扫描等待）、log file sync（提交延迟）、enq: TX - row lock contention（行锁争用）。

3. 日志与系统检查

Oracle告警日志：
- 路径：$ORACLE_BASE\diag\rdbms\<DB_NAME>\<INSTANCE_NAME>\trace\alert_<INSTANCE_NAME>.log
- 检查ORA-错误、空间不足（表空间、归档日志）、死锁。
Windows事件查看器：
- 系统日志中排查硬件错误、存储问题（如磁盘响应慢）。

4. 补充工具（若无AWR）

手动快照对比（需SYSDBA权限）：

-- 开始快照
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

-- 等待5-10分钟后再次创建快照
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

-- 使用两个快照ID生成报告
SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(<db_id>, <instance_id>, <start_snap>, <end_snap>));

注意：Oracle SE2可能不支持AWR，可改用动态视图实时分析。

三、关联性分析

AP与DB联动：
- 若AP服务器因DB响应慢而堆积请求，需优化慢SQL或索引。
- 若DB因AP突发高并发查询而负载激增，需考虑限流或缓存。
网络排查：
- 使用ping、tracert检查AP到DB的网络延迟。
- 通过资源监视器查看TCP重传或连接数异常。

四、快速缓解措施

AP服务器：
- 重启异常IIS应用池或ColdFusion服务。
- 临时扩容或负载均衡分流请求。
DB服务器：
- 终止阻塞会话：ALTER SYSTEM KILL SESSION 'sid,serial#';
- 优化紧急SQL或添加临时索引。

五、根治建议

AP层：
- ColdFusion代码审查（避免N+1查询、内存泄漏）。
- IIS启用动态压缩、调整队列长度（appConcurrentRequestLimit）。
DB层：
- 定期收集统计信息，优化执行计划。
- 对高频SQL绑定变量，避免硬解析。

通过以上步骤，可系统性定位资源瓶颈根源，针对性优化。

（由于技术原因，联网搜索暂不可用）

分析AWR（Automatic Workload Repository）报告是诊断Oracle数据库性能问题的核心方法，尤其是当数据库出现CPU、I/O或锁争用等问题时。以下是手动生成AWR报告后的详细分析流程和关键关注点：

一、AWR报告的核心结构

AWR报告通常包含以下关键部分：

数据库概要信息（DB Time、实例名、版本等）
负载概况（Load Profile）
实例效率百分比（Instance Efficiency Percentages）
等待事件（Top 5 Timed Foreground Events）
时间模型统计（Time Model Statistics）
SQL统计（SQL ordered by Elapsed Time、CPU Time等）
段I/O统计（Segments by Physical Reads/Logical Reads）
内存和缓存效率（Buffer Pool Statistics、PGA Aggr Target Stats）

二、分析流程与关键指标

1. 整体负载评估

DB Time vs. Elapsed Time
- DB Time：数据库所有会话花费的总时间（单位：分钟）。
- Elapsed Time：快照时间段的实际时间（单位：分钟）。
  判断依据：
- 若 DB Time >> Elapsed Time，说明数据库存在高并发或长事务。
- 若 DB Time ≈ Elapsed Time，数据库负载较轻。
负载概况（Load Profile）
关注每秒钟关键操作的频率：
- Logical Reads/s（逻辑读）：高值可能表明索引缺失或SQL效率低。
- Physical Reads/s（物理读）：高值可能表明缓存不足（Buffer Cache太小）。
- Hard Parses/s（硬解析）：高值表明SQL未绑定变量，需优化应用代码。

2. 性能瓶颈定位

Top 5 等待事件（Top 5 Timed Foreground Events）
这是AWR报告中最重要的部分，直接反映数据库的瓶颈资源：

等待事件	含义	优化方向
`DB CPU`	CPU资源消耗	优化高CPU SQL或增加CPU资源
`db file sequential read`	单块读（索引或主键扫描）	检查索引效率或I/O性能
`db file scattered read`	多块读（全表扫描）	优化SQL避免全表扫描
`log file sync`	事务提交等待日志写入	优化提交频率或提升日志磁盘性能
`enq: TX - row lock contention`	行锁争用	减少事务锁持有时间

判断依据：

若等待事件集中在db file sequential read，需检查高频索引扫描的SQL。
若log file sync占比较高，可能因频繁提交小事务或日志磁盘慢。

时间模型统计（Time Model Statistics）
查看时间分配比例：
- sql execute elapsed time：SQL执行总时间。
- DB CPU：CPU消耗时间占比（理想应接近总时间的80%以上）。
- parse time elapsed：解析时间占比高则需优化硬解析。

3. SQL优化

Top SQL（SQL ordered by Elapsed Time/CPU Time）
- 重点关注以下SQL：
  - 高Elapsed Time且高Executions：频繁执行的慢SQL。
  - 高CPU Time：消耗CPU资源的SQL（可能含全表扫描、复杂计算）。
  - 高Disk Reads：物理读多的SQL（需优化索引或缓存）。
优化步骤：
1. 提取SQL文本，检查执行计划（EXPLAIN PLAN或SQL Monitor）。
2. 确认是否缺少索引、统计信息过期或存在全表扫描。
3. 绑定变量改造以减少硬解析（若Hard Parses高）。
示例分析：
```
SELECT * FROM orders WHERE order_date > SYSDATE - 30; -- 全表扫描
```
优化方案：
- 为order_date字段添加索引。
- 若数据量大，使用分区表。

4. 内存与缓存效率

Buffer Pool Statistics
- Buffer Hit Ratio：理想值应>90%。
  - 若低于90%，考虑增大DB_CACHE_SIZE。
- Free Buffer Waits：高值表明缓存不足或存在大量脏块。
PGA Aggr Target Stats
- PGA Cache Hit %：理想值应>80%。
  - 若过低，需调整PGA_AGGREGATE_TARGET。

5. I/O与存储分析

Segments by Physical Reads/Logical Reads
- 高频物理读的表或索引可能需优化：
  - 增加缓存（KEEP池）。
  - 重建索引或压缩表。
- 高频逻辑读的段可能因索引效率低或SQL写法问题。

三、分析示例

场景：CPU 100%问题

查看Top 5等待事件：
- 若DB CPU占主导，结合SQL ordered by CPU Time找到高CPU SQL。
- 示例SQL：SELECT * FROM large_table WHERE unindexed_column = ?（全表扫描）。
优化方案：
- 为unindexed_column添加索引。
- 若无法加索引，考虑物化视图或查询重写。

场景：I/O瓶颈

查看Top 5等待事件：
- db file sequential read或db file scattered read占比高。
关联Segments by Physical Reads：
- 确认高频物理读的表（如orders表）。
优化方案：
- 优化相关SQL的执行计划（避免全表扫描）。
- 将表迁移到SSD存储或增加DB_CACHE_SIZE。

四、工具辅助

SQL Tuning Advisor：自动生成SQL优化建议。

DECLARE
  task_name VARCHAR2(30);
BEGIN
  task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id => 'abc123');
  DBMS_SQLTUNE.EXECUTE_TUNING_TASK(task_name);
END;

AWR Diff Report：对比两个时段的AWR报告，定位变化点。

SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML(
  begin_snap_id => 100, end_snap_id => 200,
  compare_begin_snap_id => 150, compare_end_snap_id => 250));

五、总结

优先级顺序：
- 先看Top 5等待事件，确定瓶颈类型（CPU/I/O/锁）。
- 再分析Top SQL，定位具体SQL。
- 最后检查内存和I/O配置。
优化闭环：
- 每次优化后重新生成AWR报告验证效果。
- 长期监控基线性能，避免回归。

通过系统化分析AWR报告，可精准定位数据库性能问题的根源，减少盲目调优。
（由于技术原因，联网搜索暂不可用）

在ColdFusion中，通过获取和分析Heap Dump（堆转储）是诊断内存泄漏或对象占用过高问题的有效方法，尤其当应用出现内存缓慢增长、频繁Full GC或最终导致OutOfMemoryError时。以下是具体操作步骤和分析指南：

一、生成Heap Dump的常用方法

ColdFusion基于Java（JVM），可使用标准JVM工具生成Heap Dump：

1. 使用命令行工具

jmap（JDK自带）：

# 查找ColdFusion的Java进程ID（PID）
jps -l | grep "jrun.jar"

# 生成Heap Dump（替换<PID>）
jmap -dump:live,format=b,file=C:\coldfusion_dump.hprof <PID>

适用场景：生产环境紧急诊断（需JDK安装权限）。

jcmd（JDK 7+推荐）：

# 生成Heap Dump（更轻量）
jcmd <PID> GC.heap_dump C:\coldfusion_dump.hprof

2. 通过JVM参数自动生成

在ColdFusion的JVM启动参数中添加以下配置（jvm.config文件）：

# 内存溢出时自动生成Heap Dump
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=C:\coldfusion_oom_dump.hprof

# 触发Full GC时生成（可选）
-XX:+HeapDumpBeforeFullGC
-XX:+HeapDumpAfterFullGC

路径参考：

Windows默认位置：{ColdFusion安装目录}\cfusion\bin\jvm.config

二、分析Heap Dump的工具

1. Eclipse Memory Analyzer（MAT）

下载地址：Eclipse MAT
分析步骤：
1. 打开.hprof文件，MAT会自动生成内存泄漏分析报告。
2. 关键功能：
  - Histogram：按类统计对象数量和内存占用。
  - Dominator Tree：识别内存支配者（大对象）。
  - Leak Suspects：自动检测潜在内存泄漏点。
3. 示例分析：
  若发现coldfusion.xml.Node或coldfusion.runtime.TemplateProxy类实例过多，可能因未释放模板缓存或XML解析残留。

2. VisualVM（JDK自带）

启动方式：
```
jvisualvm
```
分析步骤：
1. 加载Heap Dump文件（文件 -> 装入）。
2. 使用类视图筛选ColdFusion相关包（如coldfusion.*、railo.*）。

3. FusionReactor（商业工具）

功能：
- 实时监控ColdFusion内存使用。
- 一键生成Heap Dump并在线分析。
- 自动关联请求与内存分配（需安装FusionReactor插件）。

三、Heap Dump分析实战

场景：内存缓慢增长

步骤1：定位大对象
- 在MAT中打开Heap Dump，点击Dominator Tree。
- 按Retained Heap降序排列，查看占用最高的对象。
  常见嫌疑对象：
- byte[]或char[]：可能因大文件操作或缓存未释放。
- coldfusion.runtime.CFPage：未释放的页面实例（检查自定义标签或单例滥用）。
步骤2：追踪引用链
- 右击可疑对象，选择Merge Shortest Paths to GC Roots -> exclude weak references。
- 查看哪些线程或静态变量阻止了垃圾回收。
  示例：
- 某个Session对象持有未释放的查询结果集（Query对象）。
步骤3：代码关联
- 结合ColdFusion日志（coldfusion-out.log），查找频繁操作的页面或组件（.cfm/.cfc）。
- 检查代码中的缓存策略、未关闭的资源（如文件句柄、数据库连接）。

四、ColdFusion内存泄漏常见原因

1. 未释放的缓存或作用域

问题代码：

<!--- 缓存未设置过期时间 --->
<cfset application.myCache = {}>
<cfset application.myCache[key] = largeData>

修复方案：
使用内置缓存框架（如<cfcache>）或定期清理。

2. 循环引用或单例滥用

问题代码：

<!--- CFC单例持有其他对象引用 --->
<cfcomponent singleton="true">
  <cfproperty name="data" type="array">
</cfcomponent>

修复方案：
避免在单例中存储可变数据，改用Request或Session作用域。

3. 第三方库或自定义标签泄漏

排查方法：
在Heap Dump中检查非ColdFusion核心类（如JDBC驱动、自定义Java库）的对象堆积。

五、优化建议

1. JVM参数调优

调整jvm.config中的内存参数（根据物理内存调整）：

# 初始堆大小
-Xms4096m
# 最大堆大小
-Xmx8192m
# 年轻代大小（避免Full GC频繁）
-XX:NewSize=2048m
-XX:MaxNewSize=2048m
# 使用G1垃圾回收器（JDK 7+）
-XX:+UseG1GC

2. 代码最佳实践

及时释放资源：

<!--- 关闭查询结果集 --->
<cfquery name="qData" datasource="dsn">
  SELECT * FROM large_table
</cfquery>
<cfset qData.close()>

限制缓存大小：

<!--- 使用软引用缓存 --->
<cfset cache = createObject("java","java.util.Collections").softValuesMap()>

3. 监控与告警

启用ColdFusion健康监控：
在ColdFusion Administrator中配置内存阈值告警。
路径：Server Settings -> Monitoring -> Memory。

总结

通过Heap Dump分析，可以精准定位ColdFusion应用中的内存问题。关键步骤包括：

生成Dump：使用jmap或JVM参数自动触发。
分析工具：MAT、VisualVM或FusionReactor。
常见问题：缓存泄漏、循环引用、资源未关闭。
优化措施：调整JVM参数、修复代码逻辑、启用监控。

建议在非高峰时段定期生成Heap Dump进行预防性分析，避免内存问题累积到生产故障。
（由于技术原因，联网搜索暂不可用）

在诊断内存问题时，使用性能监视器（如Windows的PerfMon或Linux的vmstat/top）进行详细监控是必要且高效的，尤其是在以下场景中：

一、为何需要性能监视器？

1. 实时性与趋势分析

实时监控：性能监视器可提供秒级或分钟级的内存使用数据，帮助捕捉瞬时内存峰值（如突发性内存泄漏）。
长期趋势：通过历史数据，识别内存缓慢增长的潜在泄漏（例如：每日内存使用量递增1%）。

2. 关联性分析

多维度关联：将内存使用与CPU、磁盘I/O、网络流量等指标结合，定位根本原因。
示例：
- 内存使用突增时，若伴随磁盘I/O激增，可能是交换空间（Swap）被频繁使用。
- 内存压力下，若Hard Faults/sec（缺页中断）飙升，说明物理内存不足，系统频繁使用虚拟内存。

3. 低开销与便捷性

轻量级：合理配置的性能监视器（如采样间隔5秒）对系统负载影响极小（通常<1% CPU）。
快速部署：无需修改代码或重启服务，即可开始监控。

二、性能监视器的核心配置（以Windows为例）

1. 关键内存计数器

在PerfMon中添加以下计数器（路径：性能监视器 -> 添加计数器）：

计数器	作用
`Memory\Available MBytes`	剩余可用物理内存（低于10%需警惕）。
`Memory\Pages/sec`	每秒页交换次数（持续>100可能表明内存不足）。
`Process(w3wp)\Private Bytes`	IIS工作进程的私有内存占用（检测应用内存泄漏）。
`Process(java)\Working Set`	ColdFusion（JVM进程）的内存占用（需结合JVM堆参数分析）。
`.NET CLR Memory(冷融合进程)\% Time in GC`	ColdFusion的GC时间占比（>20%表明GC压力大）。

2. 推荐配置

采样间隔：
- 紧急诊断：1秒（高精度，但日志文件较大）。
- 日常监控：5-15秒（平衡精度与开销）。
日志格式：
- 二进制（.blg）适合长期记录，CSV适合导入Excel分析。
触发器：
设置内存阈值告警（如Available MBytes < 1024时触发日志记录）。

三、性能监视器与Heap Dump的互补性

1. 性能监视器的优势

实时告警：提前预警内存不足，避免系统崩溃。
资源关联：定位内存问题是否由其他资源（如磁盘、网络）间接引发。

2. Heap Dump的优势

对象级分析：精确到类和实例的内存占用（如发现coldfusion.runtime.Query对象堆积）。
泄漏根因：通过引用链追踪，找到未释放的代码位置。

3. 联合使用流程

性能监视器发现异常：
- Available MBytes持续下降，Pages/sec飙升。
生成Heap Dump：
在内存接近耗尽时，通过jmap或JVM参数自动生成Dump。
MAT分析Dump：
定位泄漏对象（如缓存未释放的Struct或Query）。
代码修复验证：
修改后，通过性能监视器观察内存是否稳定。

四、实际场景示例

场景：ColdFusion内存泄漏

现象：
Process(java)\Working Set每日增长5%，最终触发OutOfMemoryError。
监控配置：
- 添加Process(java)\Private Bytes和.NET CLR Memory\% Time in GC。
- 设置采样间隔5分钟，连续记录一周。
分析步骤：
- 发现Private Bytes持续增长，但JVM堆内存（通过jstat -gc <PID>）未满，表明是堆外内存泄漏（如JNI库或直接内存未释放）。
- 结合Heap Dump分析，发现ByteBuffer对象未回收，最终定位到某第三方文件处理组件的Bug。

五、替代方案（非Windows环境）

1. Linux/Unix工具

vmstat：

vmstat 5        # 每5秒输出一次内存、Swap、I/O统计

smem：

smem -p -s swap -r | grep java   # 按Swap使用排序，查找高内存进程

pidstat：

pidstat -r -p <PID> 5            # 监控指定进程的内存和缺页中断

2. 容器化环境

Docker Stats：

docker stats --format "table {{.Container}}\t{{.MemUsage}}"   # 实时监控容器内存

Kubernetes Metrics Server：
通过kubectl top pod查看Pod内存使用。

六、总结

必须使用性能监视器的场景：
- 实时监控内存趋势，预防崩溃。
- 初步定位内存问题是否与其他资源（CPU、磁盘）相关。
需结合Heap Dump的场景：
- 精确分析对象级内存泄漏。
- 需要修改代码修复根因时。

建议策略：

日常监控：配置性能监视器，设置阈值告警。
异常时：生成Heap Dump并分析。
优化后：通过性能监视器验证内存是否稳定。

通过性能监视器与Heap Dump的联动，可高效解决内存问题，避免“盲人摸象”式调优。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up