问题简述 说白了,Java根据指定分隔符分割字符串,忽略在引号(单引号和双引号)里面的分隔符; oom压测的时候,正则匹配"(?=(?:[^\"]*\"[^\"]*\")*[^\"]*$)(?=(?:[^']*'[^']*')*[^']*$)" 挂掉了,栈溢出了. 压测使用了200k的sql字符串,也就是200*1024Byte的字符串,单层时间复杂度就有2*10^5,不说时间的问题,正则匹配的迭代量太大,往往2*10^5中首次就可以匹

解Bug之路-记一次中间件导致的慢SQL排查过程 前言 最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章. Bug现场 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段.而且经过线上压测的检验,单台每秒能够执行1.7W条sql.但线上情况还是有出乎我们意料的情况.有一个业务线反映,每天有几条sql有长达十几秒的超时.而且sql是主键更新或主键查询,更奇怪的是出现超时的是不同的sql,似

Android中解决图像解码导致的OOM问题 原文链接:http://blog.csdn.net/zjl5211314/article/details/7042017

背景 公司的主打产品是一款跨平台的 App,我的部门负责为它提供底层的 sdk 用于数据传输,我负责的是 Adnroid 端的 sdk 开发. sdk 并不直接加载在 App 主进程,而是隔离在一个单独进程中,然后两个进程通过 tcp 连接进行通信的,这样做的目的是减少因 sdk 的崩溃带来的主进程 crash,为用户带来更好的体验. 如上图所示,sdk 主要实现于 service.so 中被 Work 进程加载,kernel.so 通过 jni 嵌入在 App 主进程,前者作为侦听端,后者是连

背景 长话短说,我们部门一个同事找到我,说他的spark 2.3 structured streaming程序频繁报OOM,从来没有坚持过超过三四天的,叫帮看一下. 这种事情一般我是不愿意看的,因为大部分情况下spark oom就那么几种可能: 数据量拉太大,executor内存爆了: shuffle过程中数据量太大,shuffle数太少,内存又爆了: 闲着蛋疼调用collect之类的方法,把数据往dirver上一聚合,driver内存爆了 闲着蛋疼又调用了一下persist还把结果存内存,还是

背景:我司作为某运营商公司的技术咨询公司,发现有第三方开发公司在使用HBase 1.1.2 (HDP 2.4.2.258版本)一段时间使用正常后,从某一天开始报OOM,从而导致RegionServer宕机. 故障排查步骤 查看 regionserver的log和stdout.由于是突然宕机,log没有任何error信息,stdout 因为自动拉起以及默认启动脚本是重定向覆盖,所以被洗掉了:而oom dump当时还没开启,无任何明显提示信息. regionserver的log中尽管没有发现erro

本文介绍的是Java里一个内建的概念,Finalizer.你可能对它对数家珍,但也可能从未听闻过,这得看你有没有花时间完整地看过一遍java.lang.Object类了.在java.lang.Object里面就有一个finalize()的方法.这个方法的实现是空的,不过一旦实现了这个方法,就会触发JVM的内部行为,威力和危险并存. 如果JVM发现某个类实现了finalize()方法的话,那么见证奇迹的时刻到了.我们先来创建一个实现了这个非凡的finalize()方法的类,然后看下这种情况下JVM

接前一篇,电脑换了新的,系统是64bit的win8系统,先安装了SQLServer2012,再安装VS2010旗舰版,Stop!为什么还是2010?因为2010太经典了,以至于公司的项目还在用它写项目,而我是直接从公司那拉过来的项目文件(含所有相关文件的Solution解决方案).因为解决方案就是用2010创建的,因此直接用2010加载解决方案几乎没有问题,为了保证工作稳定,所以一定要装VS2010啊!但是问题来了,我心目中最爱的VS2013啊,什么时候能用上呢?这就涉及到了项目版本移植,接下来

去年(2014年)公司决定服务框架改用Finagle(后续文章详细介绍),but 公司业务系统大部分是C#写的,然后 finagle只提供了 scala/java 的Client 于是 只能自己动手丰衣足食了,项目中使用了 zookpeerClient+ThriftClient 然后自己封装了 client loadBlance 部分 和 failover 部分. 使用场景:web服务器 (window iis 挂载 mvc4的网站,mvc4中使用封装的Client)访问 finagle服务器(

yarn就先不介绍了,这次排坑经历还是有收获的,从日志到堆栈信息再到源码,很有意思,下面听我说 问题描述: 集群一台NodeManager的cpu负载飙高. 进程还在但是看日志已经不再向ResourceManager发送心跳,不断重复下文2的动作. 心跳停止一段时间后会重连上RM但是cpu仍然很高,再过一段时间心跳再停,一直循环. NodeManager的日志解析 1.NM的localizing过程 localizing:container开始从hdfs下载resource,hdfs文件的状态从

现在项目里需要实现一个功能如下: A.exe把B.exe复制到临时目录,然后A.exe退出,B.exe负责把A.exe所在的整个目录删除. 实现: A.exe用CreateProcess创建B.exe时,把所在目录作为命令行参数传递到B.exe.然后B.exe中对这个目录进行递归删除. A.exe创建进程的代码.大概如下 if( !::CreateProcessW( nullptr, // No module name (use command line) pathTmp.m_strPath.G

解决方法:将string 通过copy函数复制到某个char[] 1. string res =“xxx”; char arr[100]; int len = res.copy(arr, 100); arr[len] = '\0'; //一定要加结束符 sendData = arr;

一.问题描述: 我用rtrim()函数去除右侧多余的"."号,去除之后,发现乱码. 二.出现原因: 当右侧没有分号,要去除的字符串的十六进制又刚刚好以81结尾,就导致81被去除,从而显示乱码. 三.解决方案: 在使用rtrim()之前使用strpos()检查是否存在".",如果存在再调用rtrim() 具体参考文章: https://www.php.cn/php-weizijiaocheng-380613.html

一.问题现象 20180201:15:06:25:028653 gpinitsystem:sdw1-2:gpadmin-[INFO]:---------------------------------------- 20180201:15:06:25:028653 gpinitsystem:sdw1-2:gpadmin-[INFO]:-Greenplum Primary Segment Configuration 20180201:15:06:25:028653 gpinitsystem:sdw

号外 最近因为换工作的原因,我的博客和Github没有像之前那样频繁的更新了.一方面原因是投递简历和准备面试,由于之前的基础没有很扎实,需要把平时的知识点都整理一遍.这个时间段持续了20多天的样子,因为今年的互联网市场遇冷,简历反馈率都不是很好. ​ 我一共投递了菜鸟网络,天猫超市,有赞,大搜车和涂鸦智能等公司,都收到了面试邀请.菜鸟网络和涂鸦智能投递的职位方向都是我比较感兴趣的IOT,有赞投递的是风控和大搜车的新零售职位,后两个都是我之前的没有接触过的领域.最后由于各方面的考虑(没面试成功和对

出处:  https://mp.weixin.qq.com/s/8j8YTcr2qhVActLGzOqe7Q  https://blog.csdn.net/h2604396739/article/details/91441248 先分析一道面试题 JVM 堆内存溢出后,其他线程是否可继续工作? 答:这道题其实很有难度,涉及的知识点有jvm内存分配.作用域.gc等,不是简单的是与否的问题. 由于题目中给出的OOM,java中OOM又分很多类型:比如:堆溢出(“java.lang.OutOfMemo

问题发现告警数据库出现复制中断,延迟超过100秒 问题排查复制信息检查,通过’show slave status\G’命令可以查看复制线程详细的工作状态,对于判断复制中断的原因有一些指导性意义.当时的关键信息如下 Slave_IO_State: Waiting for master to send event Slave_IO_Running: Yes Slave_SQL_Running: No Last_Errno: 1594 Last_Error: Relay log read failur

nmap扫描端口导致线上大量Java服务FullGC甚至OOM 最近公司遇到了一次诡异的线上FullGC保障,多个服务几乎所有的实例集中报FullGC,个别实例甚至出现了OOM,直接被docker杀掉. 观察报警服务的log,均有大量的此log *TNonblockingServer [ERROR] Read a frame size of ****, which is bigger than the maximum allowable buffer size for ALL connectio

转自  http://blog.csdn.net/bigdatahappy/article/details/41726389 转这个目的,是因为该贴子中调优思路不错,值得学习 搜索推荐有一个job,1000多个map,200个reduce,运行到最后只剩一个reduce(10.39.6.130上)的时候,出现以下异常,导致job失败: 2014-12-04 15:49:04,297 INFO [main] org.apache.hadoop.mapred.Merger: Down to the 

在网上看了部分Android中OOM的问题,现在根据理解,做一下笔记. Android OOM 产生的几种原因 1. 程序中使用了太多自己创建的Bitmap. 这种情况通常是最好解决的. 因为你明白你在哪里使用了这些Bitmap, 在什么时候就不需要了. 大部分情况是因为重复创建bitmap, 而不使用的bitmap没有被及时释放, 导致了 oom. 所以在不使用的时候要将bitmap对象回收bitmap.recycle(), 并将bitmap对象置为null. 还有就是当你一次性使用过多bit

我们的项目往往会载入图片.有时,承担太多,再装图片,它导致了非常小的程序卡,而在铅oom从而导致异常app再见,今天翻译google官方网站,它已经做了很好的图像处理汇总,由于Google我们已经给解决方案,这是非常必要的研究,译的地址为:http://developer.android.com/training/displaying-bitmaps/index.html 图片有各种形状和大小,但在大多数情况下,这些图片都会大于我们程序所须要的大小. 比方说系统图片库里展示的图片大都是用手机摄像