学习
实践
活动
专区
工具
TVP
写文章
  • 广告
    关闭

    上云精选

    2核2G云服务器 每月9.33元起,个人开发者专属3年机 低至2.3折

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

    Bug之路-串包Bug

    Bug之路-串包Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。 串包Bug现场 前置故障Redis超时 由于某个系统大量的hget、hset操作将Redis拖垮,通过监控发现Redis的CPU和IO有大量的尖刺,CPU示意图下图所示: ? Bug复盘 此次Bug是由Redis本身Server负载太高超时引起的。Bug的现象是通过Jedis去取对应的Key值,得不到预期的结果,简而言之包乱了,串包了。 缩小Bug范围 首先:Redis是全球久经考验的系统,这样的串包不应该是Redis的问题。 第二:Redis刷新了key后Bug依然存在,而业务系统重启了之后Okay。 Bug推理 笔者意识到,之所以串包可能是由于jedisClient里面可能有残余的数据,导致读取的时候读取到此数据,从而造成串包的现象。

    53410

    Bug之路-串包Bug

    笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑。 串包Bug现场 前置故障Redis超时 由于某个系统大量的hget、hset操作将Redis拖垮,通过监控发现Redis的CPU和IO有大量的尖刺,CPU示意图下图所示: CPU达到了100%,导致很多 Bug复盘 此次Bug是由Redis本身Server负载太高超时引起的。Bug的现象是通过Jedis去取对应的Key值,得不到预期的结果,简而言之包乱了,串包了。 缩小Bug范围 首先:Redis是全球久经考验的系统,这样的串包不应该是Redis的问题。 第二:Redis刷新了key后Bug依然存在,而业务系统重启了之后Okay。 Bug推理 笔者意识到,之所以串包可能是由于jedisClient里面可能有残余的数据,导致读取的时候读取到此数据,从而造成串包的现象。

    22510

    Bug之路-Druid的Bug

    Bug之路-Druid的Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。 前言 此Bug是Druid低版本的Bug,此Bug至少在1.0.12版本就已经修复。 Sharding Proxy的Bug 于是此问题又萦绕在笔者心头,在又一番不下于上述过程的努力之后,发现一个月之前上线的新版本的Sharding Proxy的内存泄露Bug导致频繁GC(并定位内存泄露点 与此类似,如果DB负载过高的话,笔者推测也会触发Druid的Bug。 终于这次的连环Bug算是填完了。 总结 追查Bug,日志和源码是最重要的两个部分。最源头的日志信息量最大,同时要对任何不同寻常的现象都加以分析并推测,最后结合源码,才能最终找出Bug

    58450

    Bug之路-TCP粘包Bug

    Bug之路-TCP粘包Bug 前言 关于TCP流 TCP是流的概念,解释如下 TCP窗口的大小取决于当前的网络状况、对端的缓冲大小等等因素, TCP将这些都从底层屏蔽。 TCP粘包Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的BugBug现场 出Bug的系统是做与外部系统进行对接之用。这两者并不通过http协议进行交互,而是在通过TCP协议之上封装一层自己的报文进行通讯。如下图示: ? 此后一切正常,交易量也回归正常,仿佛刚才的Bug从来没有发生过。在此之前,此系统已经稳定运行了好几个月,从来没出现过错误。 但是,这事不能就这么过去了,下次又出这种Bug怎么办,继续重启么? 事实上,在笔者解决各种Bug的过程中,经常通过猜想等手段定位出Bug的原因。但是从现场取证,通过证据去解释发生的现象,通过演绎去说服同事,并对同事提出的种种问题做出合理的解释才是最困难的。

    47320

    回归BUG

    当软件一直处于发现BUG和解决BUG的循环中时,为什么我们需要执行回归用例?我们需要定期执行回归测试。我们这样做的原因是发现回归缺陷。 当发现由于修补程序而触发其他功能BUG时,这些BUG称为回归BUG。例如,假设登录页面有一些BUG,开发人员已修复它。现在,登录页面可以正常工作,但是注册页面正在引起一些验证或其他之前不存在的BUG。 由于登录页面上的修复,可能导致了新BUG,这是一个回归中发现的BUG,很容易被错过。 回归BUG很难处理 回归BUG通常是不可避免的,需要在发布软件之前对其进行修复。 「时间复杂性」:截止日期临近时,回归BUG可能会带来很大挑战。开发人员很少有时间来修复新检测到的BUG,他们往往急于修复测试同学刚刚提出BUG而不会关注可能导致的回归BUG。 处理回归BUG 有几种方法可以帮助测试团队有效地处理回归BUG。 代码审查 不仅开发,甚至测试脚本都需要定期检查代码。检查测试用例,以确保它们足以验证组件的每个模块。

    1.1K30

    管理工具】常见免费MySQL管理工具汇总

    但笔者一直在寻找一款满意的MySQL管理工具,并且要是开源或免费,因此诞生了本文,笔者为本文起名为:10个最好的免费MySQL管理工具,但是编者认为世上之物,没有最好,只有更好。 不过笔者介绍的几款免费的MySQL管理工具还是很好的,希望这些工具能帮助开发人员和MySQL数据库维护人员简化工作,提高效率。 四、SQLyog SQLyog是一个全面的MySQL数据库管理工具(/‘GUI’/'Frontend‘)。 它的社区版(Community Edition)是具有GPL许可的免费开源软件。 >支持MySQL视图 >它使用多窗口功能,能够立即支持多个数据库或表格 八、SQL Buddy SQL Buddy是一个强大的轻量级Ajax数据库管理工具。 十、Navicat Lite MySQL Admin Tool Navicat是一款快速、可靠的数据库管理工具,很受大家的欢迎。

    2K30

    管理工具

    本次分享不会包含使用方式,如感兴趣可以自行查看 #简介 前端的包管理工具相信大家一定不会陌生,因为每天都需要跟他打交道,新项目或者刚拉下来的前端项目都需要去 install 依赖进行包的依赖安装,大家最熟悉的应该就是 #包管理工具的功能 处理和编写元数据 批量安装或更新所有依赖项 添加、更新和删除依赖项 运行脚本 发布软件包 进行安全审查 #简史 第一个发布的软件包管理器是 npm ,早在 2010 年就已经存在了。 它确立了如今包管理的核心,在前端包管理工具相当于是一种标准了。 如今 npm 已经存在 12 年了,为什么还有其他替代品? 在举个 我们在 yarn 的包管理工具下,引入一个 react 使用的包 object-assign。 一直使用至今的 1.22.x 版本 所以我在看到有人用 npm 的时候就忍不住一直在推荐 Yarn 作为包管理工具,每次接手或者新开发的项目也是。。。

    24220

    关注

    腾讯云开发者公众号
    10元无门槛代金券
    洞察腾讯核心技术
    剖析业界实践案例
    腾讯云开发者公众号二维码

    相关产品

    • 代码托管

      代码托管

      CODING 代码托管是为开发者打造的云端便捷代码管理工具,旨在为更多的开发者带去便捷、高效的开发体验,全面支持 Git/SVN 代码托管,包括代码评审,分支管理,超大仓库。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券