异构平台轮询出现问题 10912

最新推荐文章于 2025-07-29 10:40:33 发布
最新推荐文章于 2025-07-29 10:40:33 发布
阅读量1.1k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： NGOD
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/MiltonZhong/article/details/14502297
本文记录了一次异构轮询出现故障后的排查过程，主要关注IEPG与SM之间的交互问题，通过分析日志文件定位到区域码配置错误导致的服务异常。
异构轮询又问题  查哪些服务器啊
黄维升 11:18:02 
报什么错
MiltonZhong 11:18:10 
10912
黄维升 11:18:14 
IEPG,MAP
黄维升 11:19:07 
iepg的日志在iepg/iepg-jetty/iepg/log下
黄维升 11:19:26 
MAP的在sm/coship-sm/sm/log/下
MiltonZhong 11:20:29 
  IEPG1日志就卡在这里了
MiltonZhong 11:20:44 
系统繁忙什么的
黄维升 11:21:05 
这个跟故障没关系
黄维升 11:21:16 
你看现在的时间
黄维升 11:21:18 
11：21
黄维升 11:21:25 
你找这附近的日志
MiltonZhong 11:21:37 
那女的说很早就这样了
MiltonZhong 11:21:45 
恩
黄维升 11:21:47 
注意查一下错误代码表
黄维升 11:21:57 
10912的话是发给SM没回复
黄维升 11:22:08 
证明鉴权的过程是正常的
黄维升 11:22:15 
你应该直接找SM的日志
黄维升 11:22:24 
不需要看IEPG
黄维升 11:22:44 
这个你有没有
11:22:45 
对方取消在线传输，转为发送离线文件“Portal消息框提示列表-2012.7.24修正.doc”(193.00KB)。 

黄维升 11:22:51 
我记得都发你们的了
11:23:05 
 

黄维升 11:23:12 
发出NGOD-S1 Session Setup请求后已过10秒，尚未收到session manager的响应后，中间件触发10912事件。
黄维升 11:23:24 
Setup请求是在鉴权之后发出的
黄维升 11:23:36 
所以PT是生成的，鉴权过程没有问题
黄维升 11:23:40 
不然不会有SETUP
黄维升 11:23:45 
直接看MAP日志吧
MiltonZhong 11:32:02 

黄维升 11:32:20 
不是这些
黄维升 11:32:26 
看会话流程
黄维升 11:32:32 
之前跟你们讲的那些
黄维升 11:32:40 
从setup请求开始
黄维升 11:32:44 
一步步分析
MiltonZhong 11:34:22 

MiltonZhong 11:34:26 
这个有没有问题
黄维升 11:34:34 
有
黄维升 11:34:44 
看上面的区域码是多少
黄维升 11:35:02 
qamname
MiltonZhong 11:36:33 
qam_name=1001
黄维升 11:36:48 
区域码不对
MiltonZhong 11:36:57 
？
黄维升 11:37:09 
盒子是不是重启过
MiltonZhong 11:38:02 
早上8点多的时候重启过
MiltonZhong 11:38:10 
8点30分
黄维升 11:38:51 
那就是了
黄维升 11:39:01 
手动把区域码改为3160吧


进入电视机的 系统设置  然后按 96956   进入一个界面，进入双向....................设置区域代码
SoC 内的 CPU、GPU、DSP、NPU 协同执行结构图解析：多异构协同的最新实战体系
努力分享一些人工智能、计算机视觉、影像等相关的知识干货！
05-26 2479
随着移动端 AI 能力迅速演进，SoC（System on Chip）内部的多种异构计算单元（CPU、GPU、DSP、NPU）之间的协同执行能力成为衡量芯片智能算力的关键指标。本文基于截至 2025 年 5 月最新主流国产芯片（如海思昇腾、地平线旭日、联发科天玑、高通骁龙 8 Gen 系、寒武纪思元等）在实际落地应用中的公开结构与技术资料，深入解析 CPU-GPU-DSP-NPU 协同执行的体系结构、执行路径与调度逻辑。文章结合 Android NNAPI、Vulkan Compute、自定义调度器等工程实
05 如何做到异构数据的同步一致性
周壮的博客
04-18 1230
因缓存中同一个订单的基本信息和商品是存储在一起的，更新时需要把缓存中的数据读取至同步程序并替换掉此次变更的内容（如某一个发生变更的商品信息），再回写至缓存中即可。还是以上述修改微博为例，在“Binlog 订阅及转发模块”转发 Binlog 数据前，会按业务规则判断转发的 Binlog 数据是否在并发后仍需要串行消费，比如上面提到的同一条微博的多次修改就需要串行消费，而多条微博间的修改则可以并行消费，它不存在并发问题。基于上述格式的数据同步的实现代码会非常简单，但缺点是，上述格式产生的数据量较大。
轮询不得不考虑的异常 close 事件侦听
点滴
06-01 534
最近想在服务端做个功能，用到了 长轮询， 不管是用eggjs 、 expressjs, 在开发过程中不断的会发现一些未处理的异常抛出。 errno: "ECONNRESET" code: "ECONNRESET" syscall: "read" 最后发现 原来长连接未侦听 close 的事件， 流程大概是这样的 1、用户建立请求 pending状态 2、服务端 emit 事件 用于执行特定任务 3、执行完成 或者 时间到了， response 返回信息 如果在 2 和3 的环节之间 用户 close
异构平台轮询出现问题，错误代码：10912
MiltonZhong
03-03 1335
解决方法： 查看日志 MAP的在sm/coship-sm/sm/log/ 根据故障发生的时间来查找相关的错误日志，注意查一下错误代码表，10912的是发给SM没回复，证明鉴权的过程是正常的，应该直接找SM的日志。 错误代码表： 问题解释： 发出NGOD-S1 Session Setup请求后已过10秒，尚未收到session manager的响应后，中间件触发1
国产算力平台 × NVIDIA GPU 混合部署全流程实战：昇腾 / 寒武纪与异构推理系统集成解析
努力分享一些人工智能、计算机视觉、影像等相关的知识干货！
05-06 2644
随着国产 AI 芯片（如昇腾、寒武纪）的日趋成熟，越来越多的企业在构建 AI 推理平台时开始考虑 **昇腾/寒武纪与 NVIDIA GPU 的混合部署架构**。本篇文章基于 2025 年实际生产部署经验，从架构设计、驱动适配、模型格式转换、异构调度、容器化部署到性能调优等维度，系统性拆解国产芯片与 NVIDIA GPU 的融合路径，涵盖 MindX SDK、MagicMind SDK、TensorRT 引擎的兼容适配，结合 Kubernetes + Helm 的多实例调度模式，构建一套高可用、可迁移、支持模
实现基于轮询的任务调度系统
weixin_30978239的博客
07-29 679
任务调度系统是现代操作系统中不可或缺的一部分，它负责管理和分配系统中的资源给不同的任务。它能够确保每个任务在合理的时间得到处理，同时也保证系统的高效率和稳定性。在多任务操作系统、网络服务器、云计算平台等场景中，任务调度系统的作用尤为关键。轮询调度策略是一种简单的任务调度方式，它周期性地为每个任务分配CPU时间，按照任务列表的顺序依次执行每个任务一小段时间片。这种策略常被用于早期的系统或一些不需要高级调度算法的场景，例如一些简单的嵌入式系统和某些实时操作系统。
万字长文解密数据异构最佳实践（含完整代码实现）！！
冰河的专栏
03-08 1618
这是我看过的最好的数据异构解决方案！！
电商平台架构
cs123dn_ll的专栏
01-10 3776
设计理念 1 时间换空间 1.1 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）， 反向代理缓存，应用端的缓存(memcache)，内存数据库，Buffer、cache机制（数据库，中间件等）。 1.2 索引 ...
Python HTTP负载均衡：轮询与权重分发策略
weixin_73725158的博客
04-16 718
self.weighted_servers = weighted_servers # 格式：{server: weight}通过合理选择负载均衡策略，开发者可在Python应用中构建高效、可扩展的服务架构，有效应对流量高峰与节点异构性问题。selected_server = balancer.get_server() # 按4:2比例分配请求。selected_server = balancer.get_server() # 按序返回服务器地址。权重分发根据服务器性能（如CPU、内存）分配请求比例。
异构环境下平滑加权轮询Reduce任务调度算法研究.docx
最新发布
08-12
针对上述问题，研究者提出了在异构环境下针对Reduce任务的动态平滑加权轮询调度算法。该算法的主要目标是根据节点的计算能力和数据本地性这两个关键因素，动态选取最优的Reduce计算节点，以此提高任务执行效率。 在...
藏经阁-360病毒样本大规模异构实时扫描平台.pdf
09-09
藏经阁-360病毒样本大规模异构实时扫描平台 藏经阁-360病毒样本大规模异构实时扫描平台是基于阿里云的实时扫描平台，旨在实时对木马病毒样本进行鉴定和处理。该平台采用分布式队列Gearman和内存方式减少磁盘IO，...
车联网数据流的多维服务质量改进异构计算最早完成时间调度算法
04-26
本研究旨在解决车联网中的数据流分布式处理调度问题，提出一种多维服务质量（QoS）改进的异构计算最早完成时间（HEFT）调度算法，以提高车联网中数据处理的效率和用户体验。 #### 三、关键技术与方法 ##### 3.1 ...
正确的SM会话日志
MiltonZhong
03-03 6898
02/27/14 16:15:09,770   INFO    SID[285544368599760921]-inited:0x9811cb8,10.135.252.17:45550 02/27/14 16:15:09,770   DEBUG   SID[285544368599760921]-current state: 2 and will set state: 0 02/27/14 1
点播的时候出现 “S1-10921” 的错误
MiltonZhong
02-27 3206
简单点说，这个是区域频点的问题所致。 排除方法： 1. 到“自助服务”的系统设置中，点击96956，进入设置，检查portal地址和区域码，重要的是检查VOD部署参数中的“频点频率”是否和中心的ERM中的频点频率是否一致；如下图： -1表示未开启，这里正常的是706000000 2.检查地市的IEPGM中的区域频点是否和ERM中的区域频点是否一致，如不一致，VO
异构平台运维工作文档
MiltonZhong
03-20 1977
目   录 第1章    业务巡检    4 第2章    系统巡检    4 2.1    BO巡检    4 2.1.1    AAA1    6 2.1.2    AAA2    8 2.1.3    BMS,IEPGM,BOSSAGENT    10 2.1.4    IEPG1    13 2.1.5    IPEG2    15 2.1.6    IPEG3    1
梅州“天华专区-高清影院-动作战争”《英雄本色3》《低俗小说》无法点播。此影片在中心试没有的，在地市正常状态也应该是没有的，但是梅州还在上架里。
MiltonZhong
04-19 1943
联系技术将这两部影片从上架记录表中删除，处理完毕。 t_res_cloumn_map是上架表、v_column_resource_relation是关系视图 ，影片查询SQL如下，然后进行删除。 select * from t_res_cloumn_map where resource_id='16939102' select * from t_res_cloum
查询“信用额度”
MiltonZhong
06-25 1818
以下是查询结果，望有所帮助 卡号; 8757003737130205 环境：省中心 1.首先在BMS查看这个卡号的信息; 据bossagent彭军解释，信用额度是不在BMS中显示的。BMS不实现显示信用额度功能。 2.在BossAgent日志中排查，是存在信用额度的，如下： 从用户接口中查到： 其中amount=9999表示信用额度。 "maintai
SM会话正常，区域码正确，有流到IPQAM，机顶盒锁频正确。不能点播怎么办
MiltonZhong
02-28 1648
1.有流到IPQAM，一般不关VS的事情了 （如果IPQAM没有流，那么，将VS的SID（1859647725）给VS的人，让他们支持下） 2.那么就要确定是否有流到机顶盒了，如果确定有信号强度，但是没有码流，怎么办？ 1).重新注入一部片源进行测试 2）找IPQAM的人支持 因为： 有流的话，就是机顶盒到IPQAM的网络不通，即IPQAM推出来的流无法到达机顶
修改网络ID
MiltonZhong
03-19 1565
1点半进行，操作之前要通知局方机房值班的人员，要求他们在我们操作完成后重新播发配置表. 今晚梅州需要做网络ID的调整。 涉及到的表有两张，步骤如下： 注意要在梅州的MYSQL数据库上操作 1.备份 BMS： create table T_CHANNEL_BAK0318 as select * from T_CHANNEL; IEPG: create tab
平滑加权轮询 最小连接
03-20
<think>嗯，用户想了解平滑加权轮询和最小连接这两种负载均衡算法的实现和比较。首先，我得先回忆一下这两种算法的基本概念。 平滑加权轮询，之前看过引用4提到，它通过动态调整权重来分配请求，每轮选权重最大的服务器，然后调整临时权重，这样可以更均匀地分配，避免简单轮询带来的不均衡问题。比如，每个服务器有初始权重，每次选中后减去总权重，再重新加上自己的权重，这样就能平滑分配，而不是突然减少权重。 然后是最小连接算法，应该是指选择当前连接数最少的服务器来处理新请求。这样可以避免某些服务器过载，把请求分散到压力较小的节点上。引用2里提到平衡性很重要，最小连接应该能提高平衡性，尤其是当服务器处理能力不同的时候。 接下来需要比较它们的实现方式。平滑加权轮询可能需要维护每个服务器的当前权重，并在每次选择时更新这些权重。而最小连接则需要实时跟踪每个服务器的活跃连接数，可能需要一个计数器，每次请求来的时候遍历所有服务器找到连接数最少的。 性能方面，平滑加权轮询的时间复杂度可能比较低，因为每次选择只需要比较权重，O(n)的时间。而最小连接每次都要遍历所有服务器找最小值，也是O(n)，不过如果有大量服务器，可能需要更高效的数据结构，比如优先堆，这样查找最小值可以更快，O(1)的时间，但更新连接数时可能需要O(log n)的时间。 适用场景的话，平滑加权轮询适合服务器处理能力相近但权重不同的情况，比如引用5提到的带权重的随机算法，这里加权轮询能更好地利用高性能服务器。而最小连接适合处理长连接或任务处理时间差异大的情况，比如有些请求处理时间较长，用最小连接可以动态调整，避免某些服务器积压太多请求。 优缺点方面，平滑加权轮询的优点是平滑分配，权重高的服务器能按比例处理更多请求，缺点是无法实时感知服务器状态，比如某个服务器突然变慢，它还是会继续分配请求。而最小连接能动态根据当前负载调整，更灵活，但需要维护连接数，可能增加系统开销，尤其是在高并发时频繁更新连接数可能会有性能问题。 用户可能需要知道在什么情况下选择哪种算法。比如，如果服务器配置差异大且希望按权重分配，平滑加权轮询更合适。如果是实时负载变化大，需要动态调整，最小连接更好。此外，引用3提到负载均衡的目标是提高资源利用和可用性，这两种算法在不同场景下各有优势。 最后，用户可能还想了解如何在实际中实现这些算法，比如代码结构或者具体步骤，是否需要考虑线程安全等问题。例如，平滑加权轮询中的权重调整是否需要加锁，而最小连接中的计数器是否需要原子操作等。</think>### 平滑加权轮询 vs 最小连接负载均衡算法分析 #### 一、**算法原理与实现** 1. **平滑加权轮询（Smooth Weighted Round Robin, SWRR）** - **核心思想**：根据服务器权重动态分配请求，通过调整临时权重实现平滑分配。每轮选择当前权重最高的服务器，选中后将该服务器权重减去总权重，其他服务器权重按原值累加[^4]。 - **实现步骤**： 1. 初始化每个服务器的权重（如权重为$W_i$）。 2. 每轮选择当前临时权重最大的服务器。 3. 将选中服务器的临时权重减去总权重（例如总权重为$W_{\text{total}} = \sum W_i$）。 4. 所有服务器的临时权重增加其原始权重。 - **代码示例（Python伪代码）**： ```python servers = [{'weight': 3, 'current': 3}, {'weight': 2, 'current': 2}, {'weight': 1, 'current': 1}] total_weight = 6 for _ in range(10): selected = max(servers, key=lambda x: x['current']) selected['current'] -= total_weight for s in servers: s['current'] += s['weight'] ``` 2. **最小连接（Least Connections）** - **核心思想**：将新请求分配给当前活跃连接数最少的服务器，适用于处理时间差异较大的场景（如长连接服务）[^2]。 - **实现步骤**： 1. 维护每个服务器的活跃连接数计数器。 2. 每次请求选择计数器值最小的服务器。 3. 分配请求后递增该服务器的计数器，请求完成后递减。 - **代码示例（Python伪代码）**： ```python servers = [{'connections': 0}, {'connections': 0}, {'connections': 0}] def select_server(): return min(servers, key=lambda x: x['connections']) ``` --- #### 二、**性能与适用场景对比** | **维度** | **平滑加权轮询** | **最小连接** | |-------------------|---------------------------------------------------|---------------------------------------------| | **时间复杂度** | $O(n)$（遍历服务器列表选择权重最大的） | $O(n)$（遍历服务器列表选择最小连接数）[^2] | | **动态适应性** | 依赖预设权重，无法实时感知服务器负载变化 | 实时响应服务器负载变化（如CPU、连接数）[^2] | | **适用场景** | 短连接、服务器处理能力相近但权重不同的场景[^5] | 长连接、任务处理时间差异大的场景[^3] | | **平衡性** | 按权重分配，长期分布均匀但短期可能有倾斜 | 动态平衡，更贴近实际负载[^3] | --- #### 三、**优缺点总结** 1. **平滑加权轮询** - **优点**： - 权重分配平滑，避免传统轮询的突发集中问题。 - 算法简单，无需实时监控服务器状态。 - **缺点**： - 无法根据服务器实时负载调整（如CPU、内存占用）。 - 高权重服务器可能长期占用资源，导致低权重服务器饥饿。 2. **最小连接** - **优点**： - 动态感知负载，适合异构服务器集群。 - 避免单点过载，提升系统整体吞吐量。 - **缺点**： - 需要维护连接计数器，增加系统开销。 - 对短连接场景不敏感（连接数变化频繁）。 --- #### 四、**如何选择？** - **选平滑加权轮询**：当服务器性能差异固定且需按权重分配（如服务器配置比例3:2:1）[^5]。 - **选最小连接**：当服务器负载波动大或处理时间差异显著（如视频流处理、数据库长查询）。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值