关于奇怪的并行进程分析

在使用orabbix监控时,发现早上的七点左右出现性能抖动,DBtime瞬间提高。通过分析并行session、告警邮件、ASH报告和数据库负载信息,怀疑是SQL*Netvectordatafromclient等待事件导致。通过检查scheduler job,发现可能与自定义scheduler job有关,引发大量并行session。后续将深入跟踪,揭示问题根源。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在使用orabbix进行监控的时候,得益于使用 实时DB time监控的选项,对于几分钟内的性能抖动也能够狠容易的记录下来,而且会把这个监控的结果基本真实反应出来,不会随着两个快照的间隔被平均,这样性能问题的分析和排查如虎添翼,我直接通过性能抖动的情况就能够快速定位在哪个时间段内可能存在问题,然后借助ASH就可以得到一个更具有针对性的报告,可以精确到1分钟甚至秒级。
可以看到在早上的七点左右的时候还是有一些明显的性能抖动,DB time会瞬间提高。

这对于一个OLAP的系统来说还是有些不正常的。
并行session的情况如下,可以看到在问题发生的时间段里,产生了大量的并行session.

而且同时我也收到了orabbix的告警邮件。

监控项目: Session Active:153 
*UNKNOWN*:*UNKNOWN*
------------------------------------ 
故障时间:2015.08.27-07:22:04
所以这个问题还是需要重庆电脑维修关注一下,这种情况就犹如给一个静坐的人用针突然扎一下,会出现很明显的性能抖动。
首先为了进一步验证,得到了在快照时间内的负载信息,可以看到在问题发生的时间内DB time还是蛮高的。
BEGIN_SNAP   END_SNAP SNAPDATE            DURATION_MINS     DBTIME 
---------- ---------- --------------------------------- ---------- 
     36343      36344 27 Aug 2015 04:00              60         85 
     36344      36345 27 Aug 2015 05:00              60        118 
     36345      36346 27 Aug 2015 06:00              60        150 
     36346      36347 27 Aug 2015 07:00              60        180 
     36347      36348 27 Aug 2015 08:00              60        137 
     36348      36349 27 Aug 2015 09:00              60        140 
     36349      36350 27 Aug 2015 10:00              60         67 
     36350      36351 27 Aug 2015 11:00              60          8 
所以说得到了上面的信息,能够让我们更加清楚问题的背景和基本情况。

查看alert日志,在问题发生的时间段里,没有看到其它异常的信息。
Thu Aug 27 00:07:08 2015
Archived Log entry 63315 added for thread 1 sequence 688962 ID 0xa4527950 dest 1:
Thu Aug 27 00:07:23 2015
LNS: Standby redo logfile selected for thread 1 sequence 688964 for destination LOG_ARCHIVE_DEST_3
Thu Aug 27 00:07:32 2015
Archived Log entry 63317 added for thread 1 sequence 688963 ID 0xa4527950 dest 1:
Thu Aug 27 00:07:38 2015
Thread 1 advanced to log sequence 688965 (LGWR switch)
所以从数据库层面来说,可能没有什么明显的活动。
但是问题不可能无中生有,我们怎么去找到问题的根源呢,为了更加精确的定位问题,我们需要借助于ASH来还原那个时间段的问题情况。
为了排除Orabbix监控的延迟,我抓取的时间范围略大了些,是7分钟内的ash.
得到的报告如下,可以看到在问题发生的时间段内,取样数也确实蛮高的。
Sample Time Data Source
Analysis Begin Time: 27-Aug-15 07:15:00 V$ACTIVE_SESSION_HISTORY
Analysis End Time: 27-Aug-15 07:22:05 V$ACTIVE_SESSION_HISTORY
Elapsed Time: 7.1 (mins)
Sample Count: 177
Average Active Sessions: 0.42
Avg. Active Session per CPU: 0.05

top user event为:
Event Event Class % Event Avg Active Sessions
SQL*Net vector data from clientNetwork 39.55 0.16
Standby redo I/OSystem I/O 2.26 0.01
RFS writeSystem I/O 1.13 0.00
所以对于这个问题的分析可能会有一定的难度,因为矛头似乎都指向了备库相关的问题。

对于等待事件SQL*Net vector data from client可以参考 Doc ID 1311281.1
说法是可以忽略。我们可以先把这个问题放一放,来通过其他的思路来分析一下。
首先数据库的负载突然提高,如果单纯是因为备库的原因,为什么不是其它时间段内,白天的时候没有任何报警。白天的负载更高,更应该出现问题才对。
所以这种情况应该还是有一定的触发条件,但是查看了crontab也没有什么发现,那么很可能就是scheduler相关的。
我们怎么来推论呢。
首先的考虑就是后台的scheduler,结果查看还是默认的晚上10点左右,所以到早上的那个时间段应该不会有直接的影响。
那么scheduler狠可能就是用户自定义的。
限定在问题时间段内,得到的信息如下
 select owner,job_name,last_start_date,end_date,NEXT_RUN_DATE from dba_scheduler_jobs where last_start_date between to_timestamp('2015-08-27 05:00:00','yyyy-mm-dd hh24:mi:ss') and to_timestamp('2015-08-27 08:00:00','yyyy-mm-dd hh24:mi:ss')
 OWNER   JOB_NAME                       LAST_START_DATE             
------- -------------- ---------------------------------------------
APP_TEST   SYN_D     27-AUG-15 07.11.00.002185 AM ASIA/SHANGHAI
APP_TEST   SYN_E      27-AUG-15 06.15.00.809059 AM ASIA/SHANGHAI
APP_TEST   SYN_F      27-AUG-15 06.12.05.312974 AM +08:00       
APP_TEST   SYN_G      27-AUG-15 05.00.40.797679 AM ASIA/SHANGHAI
可以看到确实还是有scheduler job在运行,而且时间也基本是相符的。
   LOG_ID LOG_DATE                                 OWNER      JOB_NAME                   STATUS   
---------- ---------------------------------------- ---------- -----------------------------------
    241839 27-AUG-15 07.30.00.140947 AM +08:00      TEST_APP   SYN_D                     SUCCEEDED
    241836 27-AUG-15 07.05.46.398691 AM +08:00      TEST_APP   SYN_E                     SUCCEEDED
    241840 27-AUG-15 07.30.01.319849 AM +08:00      TEST_APP   SYN_F                     SUCCEEDED
    241841 27-AUG-15 07.35.00.912152 AM +08:00      TEST_APP   SYN_G                     SUCCEEDED
从以上的信息可以猜想可能是scheduler job引发的大量并行session的情况,我们后续继续进行跟踪,揭开问题的真实面纱。

<think>好的,用户想了解snpe-parallel-run的使用方法和示例教程。首先,我需要回忆一下SNPE工具的相关知识。SNPE是高通的神经网络处理引擎,用于在移动设备上加速AI模型推理。根据用户提供的引用内容,特别是引用[2]里提到的工具列表,snpe-parallel-run可能用于并行推理,但奇怪的是,在引用[2]列出的工具中并没有snpe-parallel-run这个命令,这可能意味着用户可能有拼写错误,或者这个工具是其他组件的一部分,或者需要特定的配置。 接下来,我需要检查用户提供的引用内容是否有相关线索。引用[5]提到使用数据并行在多个GPU上运行模型预测,这可能与并行运行相关,但使用的是TensorFlow的tf.estimator,而不是SNPE工具。不过,这说明用户对多GPU并行推理有兴趣,可能snpe-parallel-run是实现类似功能的SNPE工具。 由于官方文档中没有明确提到snpe-parallel-run,可能需要进一步查找SNPE的文档或社区资源。不过根据用户的引用[4],链接到高通的AI引擎页面,可能需要访问该页面获取更多信息。但假设无法直接访问,只能根据现有信息推断。 可能的思路是,snpe-parallel-run可能是一个自定义脚本或基于SNPE SDK的扩展工具,用于并行处理多个推理任务。例如,通过多线程或分布式处理来加速推理。或者,它可能与snpe-throughput-net-run相关,后者在引用[2]中提到,可能用于吞吐量测试,而并行运行可能涉及类似的方法。 接下来,我需要构建一个合理的回答,基于现有知识和可能的解决方案。可能需要指导用户如何利用现有的SNPE工具实现并行推理,例如使用多线程、多进程,或者结合SNPE的API进行开发。同时,引用相关的内容,如设置目标架构(引用[1]),或使用snpe-net-run进行基准测试(引用[2]),可能需要在回答中提到这些内容。 另外,用户可能需要示例代码或步骤,但由于SNPE的具体命令可能不包含snpe-parallel-run,可能需要建议替代方案,比如使用snpe-throughput-net-run或结合多GPU配置(引用[5]中的TensorFlow示例)。同时,提醒用户检查工具名称是否正确,或参考官方文档确认是否存在该工具。 最后,生成相关问题,帮助用户进一步探索SNPE的并行处理能力和优化方法。</think>### SNPE Parallel Run 使用方法解析 SNPE SDK中虽然没有直接名为`snpe-parallel-run`的官方工具[^2],但可以通过以下方法实现并行推理: 1. **多线程/多进程编程** ```python # Python多进程示例 from multiprocessing import Pool import subprocess def run_inference(model_file): cmd = f"snpe-net-run --container {model_file} --input_list input.txt" subprocess.call(cmd, shell=True) if __name__ == "__main__": models = ["model1.dlc", "model2.dlc", "model3.dlc"] with Pool(processes=3) as pool: pool.map(run_inference, models) ``` 通过进程池同时运行多个推理任务,需提前设置环境变量: ```bash export SNPE_TARGET_ARCH=aarch64-android # 根据目标设备设置[^1] ``` 2. **GPU并行配置** ```bash snpe-net-run --container model.dlc --use_gpu --perf_profile burst ``` 通过`--perf_profile`参数调整GPU资源分配策略,支持`sustained`/`burst`模式[^4] 3. **数据并行实现** 参考TensorFlow多GPU配置思路[^5],可创建多个SNPE运行时实例: ```python import threading def gpu_worker(gpu_id): os.environ["GPU_DEVICE_ORDINAL"] = str(gpu_id) # 初始化SNPE运行时并执行推理 threads = [] for i in range(4): t = threading.Thread(target=gpu_worker, args=(i,)) threads.append(t) t.start() ``` **优化建议:** - 使用`snpe-dlc-quantize`进行模型量化 - 通过`snpe_bench.py`分析各层耗时 - 结合ONNX Runtime进行跨平台验证[^3]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值