简谈docker容器监控

新年快乐,新年快乐,新年快乐

libco stackoverflow

几个月前突然想看下协程相关的东西,于是下了demo跑了起来,测试代码如下

关于一次heap corruption问题定位

最近在研究libco,打算把这用到新模块看能不能提升开发效率,改造访问mysql的模块真的是简单封装下就可以了。不过libco没有协程池之类的东西,这个协程管理起来比较麻烦,所以需要自己写个协程池节省下资源。调研的时候是libco + hredis-vip sync api,写起来真的无脑,但是一个协程要分配一个redisClusterContext, 一个redisClusterContext 最少也有一条连接,1000并发就至少要1000个连接,这种写法意外的可怕,而且对比了hiredis async的api,发现sync模式的api带来的开销也非常大,零散的read write请求会消耗client和server大量的cpu。所以尝试了合并多个请求到一个连接上面,这个改动一举多得,于是啃了hiredis vip的源码,尝试开始改动,中间过程省略….

couchbase 埋坑(2)

为什么是2呢,因为以前写过一篇couchbase 相关的坑了,而且其实遇到了好多乱七八糟的坑了,有精力写出来的话,还有 3和4

python生成cpu火焰图

使用火焰图定位cpu性能问题是一种实用的手段,可以简单的从火焰图中看出性能的瓶颈点,cpu火焰图有on cpu off cpu 两种模式。前些日子发现有个python的性能问题需要分析,于是搜到profiler_online这个开源项目生成on cpu火焰图

uwsgi django Ice.py reload segmentation fault

zeroc ice是一个rpc框架,广泛应用于我们后台服务,在uwsgi+django使用icepy(ice python是在ice c++的基础上封装了一层供python使用,代码是v3.6.3)的时候遇到了下面这个问题

apache httpclient 多线程重置导致内存泄漏

2017-01-03 我旁边的同事突然问我说怎么机器上账户切换不了了,提示Resource temporarily unavailable,条件反射是不是连接泄漏了(某干过这事 害怕~),ss -s了下 几百个连接而已 正常的不行,然后top了下,发现服务进程吃了19g的内存,估计就是内存泄漏了,导致连切换账户的资源都没有,于是问老大要了root 权限,想dump下堆栈和内存的,结果死活连不上jvm,无奈只能杀了进程重启了.

记一次超时事故

前几日下午,突然收到很多超时的反馈,查了下开发者反馈的一些请求,基本都是在毫秒级处理完成的,但是开发者反馈是超时很严重的,于是首先怀疑网络问题,但是反馈的开发者上面ping到服务器的延迟都非常小,稳定且没有丢包。

[uwsgi代码小札] async.c源码阅读

async.c是uwsgi提供的异步io的模块,相关的文档 uwsgi async doc虽然花了不少时间看,但是涉及的细节过多,所以也只是简单过了下整个流程,注释了一些自己的见解
greenlet之类的框架也只是粗略过了下,所以关于和协程交互的那块就还没有详细的注释

Pika SelectConnection的定时器

网络请求中,定时器一般用于超时操作的处理,由于各种定时器的实现思路都非常类似 所以由SelectConnection的代码为例子讲下定时器的实现思路。SelectConnection是pika 异步的长连接实现,适配了select, epoll, kqueue or poll等接口,由于原理都差不多,以下选择epoll的实现来讲