摘要：
科比：“你知道凌晨4点的洛杉矶是什么样子吗？”
IT男：”哦，那个点我还在加班“
科比：“。。。哦，那没事了“
这个段子反应了国内程序员们说不出的苦逼，我也正是因为昨天在公司看到了凌晨4点的景象，所以今天才能在家腾出时间来整理些平时没空整理的东西，也算是在不清醒的状态下胡诌一下吧 阅读全文
摘要：
内核将物理内存划分为一个个 4K or 8K 大小的小块（物理页），而这一个个小块就对应着这个page结构，它是内核管理内存的最小单元
上面的结构体只贴出了部分数据域，其注释内核也写得很清楚了
需要说得是，这个page结构描述的是某片物理页，而不是它包含的数据
不管是内核还是我们用户空间，分配内存时，底层都逃不掉这一个个的page，所以这个page可以作为：
1. 页缓存使用（mapping域指向address_space对象）
这个东西主要是用来对磁盘数据进行缓存，我们平时监控服务器时，经常会用top/free看到cached参数，这个参数其实就是页缓存（page cache），一般如果这个值很大，就说明内核缓冲了许多文件，读IO就会较小
2. 作为私有数据（由private域指向）
可以是作为块冲区中所用，也可以用作swap，当是空闲的page时，那么会被伙伴系统使用。
3. 作为进程页表中的映射
映射到进程页表后，我们用户空间的mall 阅读全文
摘要：
常公司的开发环境都会布置在内网，然后会有公共的服务器让大家在上面进行开发，测试，所以经常会有ssh连接服务器，或者本地mysql client连接服务器的需求，我个人经历过的公司经常会发生ssh/mysql连接公共服务器非常慢的现象，这是由于ssh服务和mysql服务默认都会在登录时进行DNS反向解析的过程，而内网通常我们没有配备DNS服务，那么这时就只能等这些服务自己超时，然后才能允许我们的登录通过，解决方案也很简单，只要关闭相应服务的解析就行了。 阅读全文
摘要：
昨天和某人聊到算命，我借此发表了一下自己对这方面的看法（虽然我才说了几句对方就睡了过去），我自己之前一向是对这些东西嗤之以鼻的，但今年经过一些思考，对这方面的态度有了一些改变，不过从本质上来讲我仍然是一个无神论者，只是自己用数学和计算机方面的知识去理解命运这回事。
我们好似每天身边都在发生或是经历一些不可预知的事情，有时候我们常会陷于纠结某个决定的时刻，这些抉择时刻或对自己的未来很重要，也或者轻描淡写，但有时候两种不同的抉择确实会影响到人的一生，但倘若我们的这些“抉择时刻”，以及最终的抉择都是必然的呢（也就是大多数江湖术士口中的“定数”）？很多从事互联网工作的朋友包括我，也许都不信这一套，不过如果从某些科学的角度去解读，发觉倒也不全无道理。 阅读全文
摘要：
在上家公司曾写过这样一个服务，用户通过我的应用（以下简称fri_svr）索取自己的好友信息，而fri_svr需要向第三方平台（如：人人，Facebook）通过http协议批量请求用户数据，由于用户数据可能很大（几k几十k的级别），所以整个req/rep的过程通常会很慢，平均大概会在 1s – 10s 之间，这样当瞬时请求量到一定级别后，就会造成fri_svr的内存暴涨且响应不了前端的请求，原因在于fri_svr会对前端的每个请求hash到（根据user_id）专门用于http请求的线程队列中（也即是one thread per queue模型），当前端向fri_svr的请求速率大于平台响应fri_svr的，那么就会造成fri_svr中队列的积攒，内存的暴涨，且无法在超时时间内响应前端请求。 阅读全文
摘要：
几个月一直懒得没动笔写写博客，最近开始动笔写点什么，今天就趁着加班出版本，横下心决定把上次烂尾的文章给收了（上篇：http://www.cppthinker.com/linux/224/context_switch_1/）。
接上篇，我们已经通过分析内核代码看到pthread_cond_signal和pthread_cond_wait会发生CS（Context Switch），本篇我将从实际测试数据出发，来看CS究竟会对我们的应用程序产生怎样的影响。
一般我们可以通过工具vmstat, dstat, pidstat来观察CS的切换情况。
vmstat, dstat只能观察整个系统的切换情况，而pidstat可以更精确地观察某个进程的上下文切换情况。 阅读全文
摘要：
对于服务器的优化，很多人都有自己的经验和见解，但就我观察，有两点常常会被人忽视 – 上下文切换 和 Cache Line同步 问题，人们往往都会习惯性地把视线集中在尽力减少内存拷贝，减少IO次数这样的问题上，不可否认它们一样重要，但一个高性能服务器需要更细致地去考察这些问题，这个问题我将分成两篇文章来写：
1）从一些我们常用的用户空间函数，到linux内核代码的跟踪，来看一个上下文切换是如何产生的
2）从实际数据来看它对我们程序的影响 阅读全文
摘要：
每个网络库都会有自己的连接管理策略，而我在设计chaos的初期，就制定了几条规则，这里我就针对每一点进行分析，及当初的考虑。 阅读全文
摘要：
基本原理 -
在chaos开篇介绍（http://www.cppthinker.com/chaos/57/chaos_1）中已经提到，task service作为chaos库的核心，主要承担着三个重则：
1. 网络I/O
2. 超时事件
3. 异步消息处理
简单来讲，可以认为一个task service中包含一个epollfd，一个定时事件管理器，一个等待被处理的异步消息队列 阅读全文
摘要：
对于buffer的设计，chaos和其他网络库的做法稍有不同，就拿libevent-stable-1.4.13（以下所提到libevent处皆为该版本）来说，它采用一种能够自动扩张的buffer，基本策略如下：
1. 当缓冲区不够存放新数据时，它会先在内部做marshal，看看是否能够腾挪出足够的空间
2. 假如没有满足，那么对buffer进行expand, 大小为原来的两倍，扩张之后该buffer就不会缩小 阅读全文