首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

EasyNVR通道离线但视频流可正常播放是什么原因导致的?

一般视频通道接入EasyNVR后,视频广场就会清楚显示视频的快照和在线情况,快照默认一分钟更新一次,在线情况也是同步更新。 有EasyNVR的用户反馈在平台中,通道显示是离线状态,但是流可以正常播放。...经过多次观察后发现用户的流实际是不稳定的,经常性在线离线反复跳跃。...如果不在线就继续重连,修复测试后离线不会上线的问题解决了,但是在给用户测试时出现cpu升高的情况,而我们本地多次测试都没有这种情况发生。...接着查看了EasyNVR的线程,打印了线程里的状态,发现实际连接的流端口和用户填写的不一致,如下: 抓包分析后发现用户的流会出现重定向的情况: 根据以上我们确定是重定向的流消耗了cpu资源,在我们内部经过多次测试和讨论后...,猜测是ffmpeg针对这种重定向的流处理机制有问题,于是尝试升级了EasyStreamClient库里的ffmpeg版本,升级后经过多天测试发现cpu正常了,该问题也得到了解决。

36010

内存泄露排查之线程泄露

,接下来要做的就是确认是这个原因导致,以及定位到具体的代码块 如果没有具体的监控,一般就是看内存,cpu,heap状况,gc状况等,最终依然无法定位到代码块的可以dump 登录涉事机器 top,观察内存占用率...查看heap,gc状况 查看线程状况,可jstack线程,发现线程较多,也能定位到,但是为了方便,遂dump一份数据详细观察堆栈 cat /proc/{pid}/status (线程数竟然这么多) ?...根据现象和对应线程堆栈信息,能确定线程就是在这边溢出,客户端的shutDown方法关闭线程池失效,导致由于初始的线程都是NIO模式,没有被结束,所以线程一直积压增加,可修改为单例模式,限制系统使用一个线程池...也没有任何异常日志,但是这是导致线程泄露的主要原因 在本地测试shutdown方法可正常关闭,很是奇怪。...如果各位有知道具体的原因的,望指教

2.9K40
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    内存泄露排查之线程泄露

    (以静态变量的方式),如果单例对象持有外部对象的引用,那么这个外部对象将不能被jvm正常回收,导致内存泄露 其它第三方类 本例(线程泄露) 本例现象 内存占用率达80%+左右,并且持续上涨,最高点到94%...,接下来要做的就是确认是这个原因导致,以及定位到具体的代码块 如果没有具体的监控,一般就是看内存,cpu,heap状况,gc状况等,最终依然无法定位到代码块的可以dump 登录涉事机器 top,观察内存占用率...查看heap,gc状况 查看线程状况,可jstack线程,发现线程较多,也能定位到,但是为了方便,遂dump一份数据详细观察堆栈 cat /proc/{pid}/status (线程数竟然这么多) ?...根据现象和对应线程堆栈信息,能确定线程就是在这边溢出,客户端的shutDown方法关闭线程池失效,导致由于初始的线程都是NIO模式,没有被结束,所以线程一直积压增加,可修改为单例模式,限制系统使用一个线程池...也没有任何异常日志,但是这是导致线程泄露的主要原因 在本地测试shutdown方法可正常关闭,很是奇怪。

    2.4K10

    Angular2 脏检查过程

    这就是为什么变更检测路径是有向树而且不可以带有闭环的原因。这种结构让检测系统极其高效。更重要的是,它可以保证系统具备更强的可预测性,并且更加方便debug。 有多快?...假设我们的应用只使用可观察对象。出现以上情况的时候,Angular就会检查所有对象。 所以,第一趟检查完成之后的状态看起来就像这样: 比方说,这时候第一个可观察的todo触发了一个事件。...此功能并没有绑定到任何一个特定的库上面。把Angular切换到其它任何observable library都只需要修改几行代码而已。 可观察对象会导致级联更新吗?...可观察对象名声比较差,因为它们可能会导致级联更新。有使用过基于可观察模型的框架来构建大型应用经验的人都知道我在说什么。一个可观察对象发生更新可能会导致一大堆可观察对象触发更新,然后就这样一直级联下去。...最后,在检测过程中的某个不确定的地方,视图会被更新。这种系统非常难以debug。 如上面的例子所示,在Angular 2 里面使用可观察对象不会出现这种问题。

    2.7K80

    JVM和机器规格调优在有赞的实践

    ;导致第二类问题的原因有网络抖动、各种Provider响应慢的原因。...并且观察了Provider的P99和avg RT,发现在这个时间点的确出现了增高,这就能解释上游会调用超时的问题,基本确定是Provider响应慢导致的,排除了网络因素。...因为采用的是CMS垃圾回收机制,流量并没有太大的波动,并且从一分钟内出现5次Full GC,可以大致确定是产生了大对象,直接进入了老年代,才这么频繁的触发Full GC,产生大对象有很多情况导致的,比如...一旦堆空间不够大,G1将会更容易导致Full GC,因为相比CMS而言,可存放的对象空间更少,从而导致G1的表现劣于CMS。...第二个原因是堆很小的情况下,G1的预测模型优势就无法发挥出来,并且由于堆内存的过小,每个region也会很小,达到最小的1M时,可能会出现大量的Humongous 对象,而Humongous对象过多,会导致频繁的

    46910

    iOS APP运行时Crash自动修复系统

    )导致的crash,见下图 [image] 3.2.2 KVO crash 防护方案 通常一个对象的KVO关系图如下: [image] 一个被观察的对象(Observed Object)上有若干个观察者...如果观察者和keypath的数量一多,很容易理不清楚被观察对象整个KVO关系,导致被观察者在dealloc的时候,还残存着一些关系没有被注销。...由上可见多数由于KVO而导致的crash原因是由于被观察对象的KVO关系图混乱导致。那么如何来管理混乱的KVO关系呢。...2.被观察对象dealloc之前,可以通过delegate自动将与自己有关的KVO关系都注销掉,避免了KVO的被观察者dealloc时仍然注册着KVO导致的crash。...所以需要一个合适的zombie对象释放机制,确定zombie机制对内存的影响是有限度的。

    3.4K1713

    【软件测试】稳定性和可靠性测试在软件开发中的重要性

    可靠性测试可帮助 QA 团队检测故障原因、捕获故障时间指标并测量系统的压力水平。 找出在给定时间发生了多少故障,以及每个故障的平均寿命。 发现故障的知觉结构。...由于系统故障可能导致经济损失、整个行业的发展停滞并造成人员伤亡,因此 IT 专家必须有方法确定工具是否足够可靠以被大规模采用。...2.恢复测试 恢复测试意味着强制系统无法观察和分析恢复过程。恢复测试的目的是确定给定应用程序在崩溃或硬件故障后需要多长时间才能重新稳定。 在正常估计负载下的性能测试期间模拟系统故障。...通过查明和消除最常见和破坏性系统故障的原因,降低系统停机的几率。 检测主要系统缺陷——从系统内存(会话、数据结构等)中释放不正确的对象 稳定性和可靠性测试解决了哪些问题?...崩溃和挂起 — 稳定性和可靠性测试验证系统的性能一直到断点,识别停机和响应问题。这些测试旨在让开发人员深入了解哪些软件组件是导致崩溃的原因,并指导团队进行软件改进,直到产品准备好发布。

    2.3K40

    为什么相关性不等于因果性?终于有人讲明白了

    可实际上,家长只是想表达,前者增加了后者发生的可能性,不是必然会让后者发生。日常生活中人们已经习惯使用大量口语化的因果句式,可它们并不一定都有因果关系。...有人说喝啤酒会导致肚子变大,但我们不能证明喝酒是导致肥胖的原因,更有可能的是爱喝酒的人往往饮食不规律、不爱运动,导致肚子变大;公鸡打鸣与日出高度相关,但它显然不是日出的原因;医院的死亡率比其他地方都高,...医学上,人们用这种现象来确定药物疗效,比如让患者吃下某种药物或进行某种治疗,然后观察患者是否痊愈,如果痊愈就认为治疗是有效的。这属于传统临床医学。...大样本随机双盲试验是现今医学界公认的可以确定药物疗效的实用方法。它主张的原则是:为了确认某个变量对实验结果有什么影响,就做一组比照实验,只尝试改变这个单一变量,然后观察实验结果。...有时,实验中的相关变量很多,很难确定到底应该控制和不控制哪些变量,以至于最终控制了真正想要测量的变量。但不管怎样,大样本随机双盲试验仍然是一套可遵循的、有效的用于验证因果性的数据统计方法。

    5.5K40

    小文件数过多导致distcp迁移报错

    它把文件和目录的列表作为map任务的输入,每个任务会完成源列表中部分文件的拷贝 问题描述 使用distcp工具将老的hdfs集群上的文件夹迁移到新hdfs集群上,经常出现在map跑到一定阶段后报错"java.lang.OutOfMemoryError...,确定在3万左右的时候为线程数极限 8.png (4).修改服务器的pid_max值为50000,重新测试 (5)重新执行distcp操作,观察到线程数可突破到4万+还未报错 9.png 10....png 问题解决 1.通过分析确定排除集群内存不足问题 2.确定是由于服务器的/proc/sys/kernel/pid_max默认值为32768限制,在文件数量非常多的情况下导致线程数超过系统限制而报错...3.增大/proc/sys/kernel/pid_max的值,同时注意其他几个限制线程的参数 最后此次虽然通过调整线程数解决了这个问题,但是最终的原因还是因为客户的小文件数量过多导致,因为一个小文件就必须由一个...map来完成,所以当小文件过多时就会启动非常多的map任务,可通过har归档方式将小文件合并后再进行distcp迁移,可参考http://www.mamicode.com/info-detail-2381918

    2.9K60

    【Go实现】实践GoF的23种设计模式:观察者模式

    方案 1 须要轮询接口,轮询太频繁会导致资源浪费,间隔太长又会导致任务完成后 Service A 无法及时感知。显然,方案 2 更加高效,因此也被广泛应用。...从前文的观察者模式实现中,我们发现 Subject 持有 Observer 的引用,当状态变更时,Subject 直接调用 Observer 的更新处理方法完成通知。...Pull 模式有个缺点,如果当前无消息可处理,将导致 Observer/Subscriber 空轮询,可以采用类似 Kafka 的解决方案:让 Observer/Subscriber 阻塞一定时长,让出...观察者模式通过依赖接口达到松耦合;发布-订阅模式则通过 Broker 达到解耦目的。 支持广播通信。 可基于 topic 来达到指定消费某一类型消息的目的。...缺点 通知 Observer/Subscriber 的顺序是不确定的,应用程序不应该依赖通知顺序来保证业务逻辑的正确性。

    36700

    RocketMQ与Dubbo相爱相杀引起的FullGC

    所有的都启动完成之后, 借助JDK自带的jvisualvm.exe工具观察MQConsumer的堆栈信息....同时观察MQConsumer的控制台, 会有FullGC产生,而且很多次. 大体流程就是上面描述. 发现的表象是老年代一直在增长,伴随着发生了FullGC,那么原因是什么?...继续点击 发现数量最多的是MessageClientExt这个类对象.它是和消息有关....由于Dubbo接口调用超时,阻塞住了MQ消费消息的线程,而MQ生产者一直在生产消息,可消费消息的速度太慢(由于Dubbo调用超时间接导致),最终消息都被放在老年代堆空间中,引起频繁FullGC....RocketMQ和Dubbo, 导致FullGC的原因以及造成FullGC的地方还有很多,接下来的文章也会一一列举出来. 针对这篇文章,也会抽个时间录播一个视频演示给大家看.

    35510

    .NET 云原生架构师训练营(设计原则与模式)--学习笔记

    ) 可复用性 解耦、高内聚、低耦合、模块化、组件化 可测试性 单元测试友好 Mock 理解复杂系统 系统思维 什么是复杂系统 系统复杂的原因 软件系统的复杂性 控制复杂性 面向过程与面向算法 系统思维...面向过程风格是一种流程化的编程风格,通过拼接一组顺序执行的方法来操作数据完成一项功能 对象 对象是一个实体,这个实体具有明确定义的边界(Boundary)和标识(Identity),并且封装了状态(State...)和行为(Behavior) 对象具有明确定义的边界和标识 对象封装了状态和行为 类 类是一种抽象,它将相似的实体抽象成相同的概念,这种抽象过程强调相关特征而忽略其他特征 抽象 抽象(Abstraction...封装的作用是分离抽象的概念接口及其实现 抽象和封装是互补的概念:抽象关注的是对象可以观察到的行为,而封装关注这种行为的实现 抽象“帮助人们思考他们做什么”,而封装“让程序可以借助最少的工作进行可靠的修改...” 封装在不同的抽象之间提供了明确的边界,因此导致了清晰的关注点分离 要让抽象能工作,必须将实现封装起来 明智的封装让可能改变的设计决策局部化 绝大多数情况下,只有当这个抽象的创造者显示地暴露出实现,而且客户愿意接受由此带来的额外的复杂性时

    25900

    IO 密集型服务 性能优化实战记录

    reflect.Value 不是一个可复用的反射对象,每次都需要按照变量生成 reflect.Value 结构体,因此性能很差。...是一个可复用的对象,同一类型的 reflect.Type 是相等的,因此可按照类型对 reflect.Type 进行 cache 复用。...(高尾部延迟的响应时间) 导致服务的个别部分出现高尾部延迟的响应时间的变异性(耗时长尾的原因)可能由于许多原因而产生,包括: 共享的资源。...根据 Golang GC 原理分析可知,G 被招募去做辅助标记是因为该 G 分配堆内存太快导致,而 计算模块每分钟缓存失效机制会导致大量的下游访问,从而引入更多的对象分配,两者结合互相印证了为何在每分钟前...图进行观察 在 inuse_objects 指标下 cache 库占用最大; 在 alloc_objects 指标下 json 序列化占用最大; 但无法确定哪一个是真正使分配内存增大的因素,因此着手对这两点进行分开优化

    99010

    一次压缩引发堆外内存过高的教训

    通过top命令发现res使用比jstat命令显示的堆大小大许多(忘了保留现场了),此时怀疑是堆外内存泄漏导致的。为了确定是堆外泄漏而非堆内,分析GC日志文件。...由此确定,泄漏的堆外内存是可回收的,而非永久泄漏,且在堆内引用被回收后即可完成回收。 ?...问:目前需要解决的问题是找出堆外内存泄漏的原因。...具体使用流程可自行百度,这里不细讲。 首先打开堆文件 ? 进入后看到对分析结果中出现三个明显的错误,问题一跟问题二是由于引入了arthas导致的,直接跳过。 ?...java.lang.ref.Finalizer基本确定回收阶段出现问题,进入搜索待回收的对象。此时我们不是纠结有多少对象没有被回收,为什么没有回收。而是这些没有回收的对象是否由指向堆外内存。 ?

    1.6K61

    九次架构改进具身机器人,模拟镜像神经元

    对于一个对象,将其视觉观察附加到特定级别的第二个外在隐藏状态将导致后者对其笛卡尔位置进行编码。那么前面的所有级别应该如何解释呢?...对固定和先验确定的连续选项进行平均和比较会导致代理无法在不断变化的环境中正确操作。...在这种情况下,如果出现意外情况,它应该能够重新规划正确的行动顺序,而总是为隐藏原因产生先验确定的行为的高级信念将无法完成任务。...作为一个实际目标,我们决定对工具使用进行建模[100],这项任务不可避免地需要离散和连续框架,并且需要考虑两个额外的方面,即对象可供性和层次因果关系。...在简单的场景中,将要达到的目标视为某些隐藏状态的原因是一个合理的假设,并使代理能够在动态上下文中运行。但假设存在多个对象,智能体如何决定哪个对象将导致特定操作呢?

    11410

    意图、假设、行动、证据 Dynamic inference by model reduction

    除此之外,还有一个很大的问题是代理的假设集是先验确定的,因此只能用固定连续状态的平均值来解释观察结果。...同样,如果物体在第一个动作期间没有移动,那么任务就很容易;然而,在后一种情况下,代理会将旧对象的位置分配给相同的离散状态,从而导致任务失败。...直接计算后验 是不可行的,因为它涉及到不可访问的边际 的计算。变分方法涉及用可管理的分布(例如高斯分布)来近似后验: 其中参数 分别称为关于隐藏状态和隐藏原因的信念。...值得注意的是,这些政策不仅仅是像强化学习方案中那样的刺激-反应映射;相反,它们包含一系列动作。鉴于行动规划需要选择导致期望先验的政策,还必须考虑尚未观察到的未来结果。...因此,EFE 是通过对这些未观察到的结果进行调节来制定的,将它们视为隐藏状态: 这里,概率分布 p(o|C) 代表首选结果。最后两个术语分别称为认知(减少不确定性)和实用(寻求目标)术语。

    12410

    当小白遇到FullGC

    一开始偶尔会收到报警邮件,显示有些接口调用时间比较长,抽查了一些接口,发现大部分都是调用下游JSF时间比较长,导致响应比较慢,这时候就没太在意,接下来继续观察了几天,发现一个规律,大部分邮件都是每天10...,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目 4.1 Full GC触发条件 到这里需要确定一个问题...注意这不是确定“什么原因导致的FullGC?”,因为这个问题原因太多了,要一步一步排查。下面是查到的资料,分享到这里供参考。 1.Minor GC触发条件:当Eden区满时,触发Minor GC。...这时候需要确定的第二个问题是:“什么情况下对象会进入老年代?”...,导致一小时一次FullGC 解决方式: 修改逻辑代码防止频繁加载新类 在排查问题时尽可能先找直接原因,缩小排查跨度,不要一步就想知道根本原因,每个线索都要问个为什么,不正常的现象肯定是有原因的。

    29821

    Linux 内核裁剪框架初探

    然而,一个应用程序通常只需要一部分 OS 功能,众多的应用需求导致了Linux内核的膨胀。操作系统的内核膨胀同样导致了安全性隐患、启动时间变长和内存使用的增加。...Makefile 用于确定是否在编译后的内核中包含某些对象文件,例如, CONFIG_CACHEFILES 就是 Makefile 中的配置选项。...bool 意味着代码要么被静态编译成内核二进制文件,要么被排除在外,而 tristate 允许代码被编译成一个可载入核心模组,即一个可以在运行时加载的独立对象。...既然引导阶段对于生成可引导内核至关重要,使用 hypervisor 提供的跟踪特性来获得端到端的可观察性并生成稳定的内核。...对于基于 C 预处理器的模式 ,分析 C 源文件以提取预处理器指令,然后检查这些指令中的语句是否被执行。对于基于 Makefile 的模式 ,确定是否应该在对象文件的粒度上选择配置选项。

    2.3K30

    MobX 背后的基础原理

    我接受不可预测性的存在,挺正常的,对于 Flux 模式特别是 Redux 来说之所以流行的最重要的原因之一便是:它精确处理了规模变大时的可预测性问题,除此之外并无任何神奇之处。...计算值应该总是优于 reactions 原因有这么几个: 它们在概念上提供了很大的清晰度。计算值应该总是单纯的依据其他可观察的值表示。...基于这个原因,MobX 有一些不完善之处,比如不完全支持 可扩展对象的动态属性(Expando properties) 并且使用了 类数组元素(faux-arrays)。...可以轻易的在 MobX 问题追踪器中找出一些无意间将对象转为可观察对象引起的非预期行为的问题。...也就是说,NX 在读取期间即时生成可观察 proxy 的方式超级有趣。我还不太确定它是如何处理引用透明性的,但目前看上去做的非常聪明。借助读写 $row 避免 modifiers 是非常有趣的做法。

    1.6K10
    领券