一、插件简介captcha-killer要解决的问题是让burp能用上各种验证码识别技术！注意：插件目前针对的图片型验证码，其他类型目前不支持。captcha-killer本身无法识别验证码，它专注于对各种验证码识别接口的调用二、下载地址：burp2020前使用：https://github.com/c0ny1/captcha-killer/tree/0.1.2burp2020后的版本使用：https://github.com/Ta0ing/captcha-killer-java8换到burp2020后，burp2020只能运行在java8环境下，因为原工具Base64编码是使⽤JDK⾥sun
一、插件简介captcha-killer要解决的问题是让burp能用上各种验证码识别技术！注意：插件目前针对的图片型验证码，其他类型目前不支持。captcha-killer本身无法识别验证码，它专注于对各种验证码识别接口的调用二、下载地址：burp2020前使用：https://github.com/c0ny1/captcha-killer/tree/0.1.2burp2020后的版本使用：https://github.com/Ta0ing/captcha-killer-java8换到burp2020后，burp2020只能运行在java8环境下，因为原工具Base64编码是使⽤JDK⾥sun
原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，非公众号转载保留此声明。上个月，我们一个java服务上线后，偶尔会发生内存OOM(OutOfMemory)问题，但由于OOM导致服务不响应请求，健康检查多次不通过，最后部署平台kill了java进程，这导致定位这次OOM问题也变得困难起来。最终，在多次review代码后发现，是SQL意外地查出大量数据导致的，如下：and`outer_id`=#{outerId}and`order_type`=#{orderType}...select*fromorder查询逻辑类似上面的示例，在Service层有个根据outer_id的查询方法，然
原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，非公众号转载保留此声明。上个月，我们一个java服务上线后，偶尔会发生内存OOM(OutOfMemory)问题，但由于OOM导致服务不响应请求，健康检查多次不通过，最后部署平台kill了java进程，这导致定位这次OOM问题也变得困难起来。最终，在多次review代码后发现，是SQL意外地查出大量数据导致的，如下：and`outer_id`=#{outerId}and`order_type`=#{orderType}...select*fromorder查询逻辑类似上面的示例，在Service层有个根据outer_id的查询方法，然
背景公司的主打产品是一款跨平台的App，我的部门负责为它提供底层的sdk用于数据传输，我负责的是Adnroid端的sdk开发。sdk并不直接加载在App主进程，而是隔离在一个单独进程中，然后两个进程通过tcp连接进行通信的，这样做的目的是减少因sdk的崩溃带来的主进程crash，为用户带来更好的体验。如上图所示，sdk主要实现于service.so中被Work进程加载，kernel.so通过jni嵌入在App主进程，前者作为侦听端，后者是连接端。不过这样做有一个问题，当侦听端口被占用时，两个进程就无法建立通信了，导致数据无法传输。为了解决这个问题，打算用本地socket(unixdomains
背景公司的主打产品是一款跨平台的App，我的部门负责为它提供底层的sdk用于数据传输，我负责的是Adnroid端的sdk开发。sdk并不直接加载在App主进程，而是隔离在一个单独进程中，然后两个进程通过tcp连接进行通信的，这样做的目的是减少因sdk的崩溃带来的主进程crash，为用户带来更好的体验。如上图所示，sdk主要实现于service.so中被Work进程加载，kernel.so通过jni嵌入在App主进程，前者作为侦听端，后者是连接端。不过这样做有一个问题，当侦听端口被占用时，两个进程就无法建立通信了，导致数据无法传输。为了解决这个问题，打算用本地socket(unixdomains
前言Pod因内存不足消失，可能由2种不同的故障导致，其中对故障2的复现、监控比较繁琐、耗时、棘手；先对Podoom相关故障进行了梳理；故障1：Pod自身内存不足Pod中的运行进程占用空间超出了Pod设置的Limit限制，导致该Pod中进程被Pod内的OS内核Kill掉；此时Pod的Status为OOMKilled，Pod的OOMKilled状态可以借助Prometheus进行监控；apiVersion:v1kind:Podmetadata:name:memory-demonamespace:mem-examplespec:containers:-name:memory-demo-ctrimag
前言Pod因内存不足消失，可能由2种不同的故障导致，其中对故障2的复现、监控比较繁琐、耗时、棘手；先对Podoom相关故障进行了梳理；故障1：Pod自身内存不足Pod中的运行进程占用空间超出了Pod设置的Limit限制，导致该Pod中进程被Pod内的OS内核Kill掉；此时Pod的Status为OOMKilled，Pod的OOMKilled状态可以借助Prometheus进行监控；apiVersion:v1kind:Podmetadata:name:memory-demonamespace:mem-examplespec:containers:-name:memory-demo-ctrimag
问题产生：作者最近在搭建Hadoop+Hive集群时，将NameNode、DataNode、Rm全部部署到一台物理机上，查询量较大时连接挂掉。问题定位：使用JPS命令查看Metastore服务正常运行，hive2--Runjar挂掉。重启之后，过段时间又会挂掉。Linux内核有个机制叫OOMkiller(OutOfMemorykiller)，该机制会监控那些占用内存过大，尤其是瞬间占用内存很快的进程，然后防止内存耗尽而自动把该进程杀掉。内核检测到系统内存不足、挑选并杀掉某个进程的过程可以参考内核源代码linux/mm/oom_kill.c，当系统内存不足的时候，out_of_memory()被
问题产生：作者最近在搭建Hadoop+Hive集群时，将NameNode、DataNode、Rm全部部署到一台物理机上，查询量较大时连接挂掉。问题定位：使用JPS命令查看Metastore服务正常运行，hive2--Runjar挂掉。重启之后，过段时间又会挂掉。Linux内核有个机制叫OOMkiller(OutOfMemorykiller)，该机制会监控那些占用内存过大，尤其是瞬间占用内存很快的进程，然后防止内存耗尽而自动把该进程杀掉。内核检测到系统内存不足、挑选并杀掉某个进程的过程可以参考内核源代码linux/mm/oom_kill.c，当系统内存不足的时候，out_of_memory()被
