事故过程 周二下午得到消息, 希望帮忙分析dump文件. 告知dump大小为42G大小. 一般机器没这么大的内存进行处理. 建议现场上传到百度云盘, 然后我这边进行下载. 时间进度为: 11.57创建的dump 现场打包压缩, 拉取上传百度云盘. 速度大概只有500KB/S. 压缩后文件6G, 时间
事故情况 最近同事反馈, 一个文件更新后出现了文件部分不可读的情况 具体现象为: 前端功能打开白屏 后端文件 前面93行不显示, notepad++打开都是 NULL 黑框. 然后重新覆盖文件, 有概率成功, 有概率失败. 遇到问题之后进行了紧急处理. 但是一开始的路线不太正确. 所以本次想总结一下
入职多年，面对生产环境，尽管都是小心翼翼，慎之又慎，还是难免捅出篓子。轻则满头大汗，面红耳赤。重则系统停摆，损失资金。每一个生产事故的背后，都是宝贵的经验和教训，都是项目成员的血泪史。为了更好地防范和遏制今后的各类事故，特开此专题，长期更新和记录大大小小的各类事故。有些是亲身经历，有些是经人耳传口授
这篇文章，聊聊一个大家经常使用的编程模式 ：Mybatis +「where 1 = 1 」。 笔者人生第一次重大的线上事故 ，就是和使用了类似的编程模式 相关，所以印象极其深刻。 这几天在调试一段业务代码时，又遇到类似的问题，所以笔者觉得非常要必要和大家絮叨絮叨。 1 OOM 事故 笔者曾服务一家电
文章首发于公众号：BiggerBoy 原文链接 一个Redis生产事故的复盘，整理这篇文章分享给大家。本期文章分析Redis中的bigkey相关问题，主要从以下几个点入手： 文章目录 什么是bigkey？bigkey的危害bigkey的产生如何发现bigkey实际生产的操作方式 如何优化bigkey
https://blog.csdn.net/ibigboy/article/details/124216874 文章首发于公众号：BiggerBoy 原文链接 一个Redis生产事故的复盘，整理这篇文章分享给大家。本期文章分析Redis中的bigkey相关问题，主要从以下几个点入手： 文章目录 什么
有句话叫每一起严重事故的背后，必然有 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患。 而我最近更是碰到了 3 起比较严重的线上事故，都是大意惹的祸。 一、数据库锁死 第一起事故发生在凌晨 4 点到 6 点，我们有个数据库被锁死了，无法更新和写入。 当天早上 5 点客服打电话给我，
https://www.cnblogs.com/charlieroro/p/17074808.html 译自：Using Prometheus to Avoid Disasters with Kubernetes CPU Limits 本文将介绍Kubernetes的resource limits是
使用prometheus来避免Kubernetes CPU Limits造成的事故 译自：Using Prometheus to Avoid Disasters with Kubernetes CPU Limits 本文将介绍Kubernetes的resource limits是如何工作的、使用哪些
煤矿安全大模型————矿途智护者 使用煤矿历史事故案例，事故处理报告、安全规程规章制度、技术文档、煤矿从业人员入职考试题库等数据，微调internlm2模型实现针对煤矿事故和煤矿安全知识的智能问答。 本项目简介： 近年来，国家对煤矿安全生产的重视程度不断提升。为了确保煤矿作业的安全，提高从业人员的安
应用场景 C端用户提交工单、工单创建完成之后、会发布一条工单创建完成的消息事件(异步消息)、MQ消费者收到消息之后、会通知各处理器处理该消息、各处理器处理完后都会发布一条将该工单写入搜索引擎的消息、最终该工单出现在搜索引擎、被工单处理人检索和处理。 事故异常体现 1、异常体现 从工单的流转记录发现、
为了保证系统稳定性，预防潜在慢SQL导致应急事故，发起慢SQL常态化备战专项，下文主要描述专项的实践及落地情况。
针对现如今高并发场景的业务系统，“并发问题” 终归是必不可少的一类（占比接近10%），每次出现问题和事故后，需要耗费大量人力成本排查分析并修复。那如果能在事前尽可能避免岂不是很香？
一：背景 1. 讲故事 今天本来想写一篇 非托管泄露 的生产事故分析，但想着昨天就上了一篇非托管文章，连着写也没什么意思，换个口味吧，刚好前些天有位朋友也找到我，说他们的拍摄监控软件卡死了，让我帮忙分析下为什么会卡死，听到这种软件，让我不禁想起了前些天 在程序员桌子上安装监控 的新闻，参考如下： 我
因所负责的系统使用的spring框架版本5.1.5.RELEASE在线上出过一个偶发的小事故，最后定位为spring-context中的一个bug导致的。
大报文问题，在京东物流内较少出现，但每次出现往往是大事故，甚至导致上下游多个系统故障。大报文的背后，是不同商家业务体量不同，特别是B端业务的采购及销售出库单，一些头部商家对京东系统支持业务复杂度及容量能力的要求越来越高。因此我们有必要把这个问题重视起来，从组织上根本上解决。
一：背景 1. 讲故事 停了一个月没有更新文章了，主要是忙于写 C#内功修炼系列的PPT，现在基本上接近尾声，可以回头继续更新这段时间分析dump的一些事故报告，有朋友微信上找到我，说他们的系统出现了大量的http超时，程序不响应处理了，让我帮忙看下怎么回事，dump也抓到了。 二：WinDbg分析
https://juejin.cn/post/7132263894801711117 前言 大家好，我是捡田螺的小男孩。 日常开发中，为了更好管理线程资源，减少创建线程和销毁线程的资源损耗，我们会使用线程池来执行一些异步任务。但是线程池使用不当，就可能会引发生产事故。今天田螺哥跟大家聊聊线程池的10
一：背景 1. 讲故事 中秋国庆长假结束，哈哈，在老家拍了很多的短视频，有兴趣的可以上B站观看：https://space.bilibili.com/409524162 ，今天继续给大家分享各种奇奇怪怪的.NET生产事故，希望能帮助大家在未来的编程之路上少踩坑。 话不多说，这篇看一个.NET程序集泄
一：背景 1.讲故事 前段时间有位朋友加微信，说他的程序直接 CPU=100%，每次只能手工介入重启，让我帮忙看下到底怎么回事，哈哈，这种CPU打满的事故，程序员压力会非常大, 我让朋友在 CPU 高的时候抓 2 个 dump 下来，然后发给我分析。 二：WinDbg 分析 1. CPU 真的被打满
