nginx增加模块

作者: 日期: 2012 年 11 月 20 日 没有评论

有时候需要给nginx增加一些模块但是想避免重新编译安装，下面是几个关键点：

1，nginx -v 查看当前所用的参数和加载模块

2，nginx源码(注意版本)重新./configure 带上原来的参数并加入新的需要开放的模块

3，make但不make install，编译完成之后用源码./objs/nginx 替换原来的 /sbin/nginx 文件(注意备份旧版本)

写在10月17日

作者: 日期: 2012 年 10 月 24 日 没有评论

终于解决了load居高不下的问题

服务器内部依然要非常注意文件读取的大小问题，即使只是在内存内部，依然会有很大的开销。

误打误撞优化了很多其他的，终于出现了跳崖式的质变，一丝欣慰啊～

路依旧漫漫，任重而道远。

后羿压力测试小结

作者: 日期: 2012 年 06 月 01 日 没有评论

压力测试的几点心得吧：

1，业务逻辑的优化为主，好的业务代码逻辑能带来无与伦比的性能优化。

2，APC的性能提升比较显著，25%左右

3，大访问量下，当php成为性能瓶颈时，不要将ip库或者其他服务放在webserver上，会抢占php的cpu资源，反倒限制qps上限，实际测试将服务提出单独放在一台服务器上整体性能提升20%左右。

 

关于cookie的domain问题

作者: 日期: 2012 年 06 月 01 日 没有评论

今天对cookie在不同的domain下的表现进行了一下测试，下面记录一下保存特性和一些浏览器的行为区别。

首先重要的一条特性：未设置domain的cookie保存的区域是私密的，下级域名无法访问到上级域名程序设置的无domain参数cookie。

第二条特性：当附带domain参数的时候，cookie是分别存储的，会有多条保存在浏览器中，比如：

访问http://a.b.c.com/index.php

代码中

set cookieKey=>a : domain:a.b.c.com

set cookieKey=>b : domain:b.c.com

set cookieKey=>c : domain:c.com

set cookieKey=>local : domain:”

处理结果中浏览器里会设置4条cookieKey=>value的值，当取得$_COOKIE['cookieKey']的时候，只会返回第一个cookieKey的内容。

当修改其中某一个cookie的值的时候，比如

set cookieKey=>b2 : domain:b.c.com

那么只有原来cookieKey=b的值会被修改，值=b2

这时Chrome和FireFox的行为会产生差异，FF不会修改Cookie已有的次序，则为第一个建立的cookieKey=a的值作为第一个返回。Chrome虽然也会在$_COOKIE['cookieKey']中取到的值为a，不过修改了的b2会被移到最后一位。

换言之，如果不修改b的值，修改的值是第一个a=>a2那么取得$_COOKIE['cookieKey']的值的时候，在FF下是得到第一位的a2，在Chrome下则得到b，因为a2的值被移位到最后一位，b被替换成首位。

如果访问的是http://b.c.com/index.php，那么如果设置cookie到a.b.c.com是设置不上的。

其他浏览器未测验。

path的情况和domain一致，只不过控制区域不同。

mongos的内存泄露问题

作者: 日期: 2012 年 05 月 21 日 没有评论

运行了几个月的mongos突然在三台服务器上集体down掉，开始没有找到问题，只以为是误操作，一周后另外的几台服务器报警，load超高服务器无响应，排除卡死的php进程之后，发现kswapd0进程经常占用cpu，仔细一看仍然存活的mongos进程占用内存高达95%！马上重启mongos之后服务器恢复正常。

由于这几台服务器的访问量较大，后续观察了几天，mongos进程占用的内存量以每天0.8%的速度增长，验证了对内存泄露的猜测，由于整体升级风险太大，也没找到该问题已经在新版本修复的证据，故采用了定期在凌晨杀掉mongos并重启的解决方案。

写在纪念雷锋的日子

作者: 日期: 2012 年 03 月 05 日 没有评论

其实只是找不到标题，想到今天这个日子，顺便点评两句。

雷锋同志已经逝去多年了，如今被打成虚假模范，各种被吐槽调侃，好不热闹，不知当今种种，还有多少是可以相信的。雷锋是无辜的，也是可悲的，甚至他的死可能都是被安排的，来将他塑造成一个永远不会变质的楷模。

他的作用等同于宗教故事中的某个高尚的信者，是整个共产主义信仰中的一个小角色。一出好戏是需要很多角色的，但这种贴近信徒的角色能够更好的影响信徒，控制他们的情绪，灌输戏剧的意志。

再多不敢再说了。。。说说自己的事。

总结一下就是碌碌与躁动，因为一些小挫折而产生的莫名危机感造成一些行为的放纵与方向的迷失。

然而，目前来看也没有什么好的方法，行为和心态相对容易控制，方向却一直是个困扰的问题。时间越来越紧迫，我一直在走，不知道朝向哪里。

也许年初的灵感是对的，对技术的了解需要转化为对行业和领域的了解，到时候的路途可能会更宽，更向上。

模糊的构想应该转变成实际的计划，罗列到年度计划里去吧。

以后的风格需要变得更加主动了，一把年纪也没什么资本矜持了。

更勤，更快，低姿，高瞻——以自勉。

《下辈子，我做你的床单》

作者: 日期: 2012 年 02 月 15 日 没有评论

某篇小说中的小诗，蛮有意思

＊＊＊

《下辈子，我做你的床单》

你说，我想我们不会再见了
我说，这辈子而已

你说，你还记得我的处女膜么
我说，结缔组织跟爱情无关

你终究离开了我
或许你会找到一个傻逼、脑残、混蛋
又或许
你会找到一个比我还爱你的——

但我必须告诉你
你要找的是爱情
不是阳具
不是钻石
不是房子
不是电玩

这辈子，我没能好好爱你
下辈子，我决定——做你的——床单

我只希望
你仍旧习惯裸睡
12点之前回家
远离痛经
珍惜时间

我成为你的容器
承接你的眼泪、欢喜、委屈、体液和习惯

我终究是爱你的
爱你的世界
爱你的身体
爱你的气味
爱你的毛发
爱你卸妆之后的脸

你还记得我说的吧
爱一个人并不是很难
不过就是看着你
洗洗短裙、黑丝和吊带衫

然后安静的——
等你上床、读书、关灯、做梦、酣眠

生命比小鸡鸡短
除了我爱你
没有什么是不朽的
我只想
和你一起
扯着世界的蛋

所以
下辈子，让我做你的床单
直到——
大姨妈跟你说再见
直到——
玛雅人和世界说再见

莫名烦躁

作者: 日期: 2012 年 02 月 05 日 没有评论

很多事情，还是没法放到微博上去说，矫情。

最近貌似很充实的生活，为什么经历过后，是这么的空乏

也许是因为全部都是浮躁飘渺的事情吧，不落停，不着边际，不接地气

＊＊＊

已经意识到好久了，自己开始期待过安定的生活了

一个安定，踏实的方向和未来

期望的同时，却也犹犹豫豫患得患失的做着选择

回头看时，居然也有些不舍，对靠谱的和不靠谱的。太不像我

也许是人老了，需要承担的多了，对那有的没的的牵挂也多了，副作用。

＊＊＊

当心情走到死胡同的时候要怎么帮助自己走出来？

对于理科生来讲这不是个多么难的事情，一道难题也总有N种解法。

当然过程会有些苦闷。

最近和人讨论到宗教，听说好些人有时候会进入一种自我无法解脱的困境，这个时候，宗教和信仰能够帮她走出困境

那么宗教和信仰就是解决人心烦恼的一部百科书，列出所有烦恼，需要解时只要查查索引

真正内心强大的，是建立这些索引的人

其实，对待苦闷的最好方法就是对自己装逼，装到你自己都信了，你就康复了

＊＊＊

原来感情也是可以打包处理的

和一个人的感觉，感情，经历，统统放在一起，加以疏远，适度厌恶和宽容，便可以把他们隔离出自己的生活，不再受它们的影响和干扰

但当你希望找回它们时，你会发现它们全部都在那，一样不少

关于Mongodb的oplog

作者: 日期: 2012 年 01 月 19 日 没有评论

oplog是Replica set模式中的核心部分，通过它来同步不同服务器之间的数据，之前忽略了对它的配置而导致了一些小问题。

首先oplog的size是可以设置的，默认的大小是数据所在硬盘的5%大小。oplog大一点可以储存更多的操作日志，当SECONDARY当机时可以提供更多的恢复时间，但是要衡量机器内存的大小，最好留出足够的表空间之后，再分配合适的大小。

现在我们就遇到了一个比较尴尬的问题，PRIMARY服务器都是大内存的，但是硬盘是较小的高速硬盘；备机则是大容量低速硬盘+小内存，而且只采用了默认的oplog size设置，这就导致了备机的oplog表占用的大小远大于主机的oplog表，实际上起作用的只是主机上oplog的内容，却让备机的空闲内存数量长期为空，甚至出现了一些load升高的问题。

Mongodb的可选构架和安全配置

作者: 日期: 2012 年 01 月 16 日 没有评论

上一个项目使用了Mongodb，它的结构是十分灵活的，能够更方便的的建立高可用性和易扩展的数据仓库。

下面是mongodb的几种构架方式，逐一进行一下简要介绍。

第一种是简单的主从方式，这种方式下可以指定一个主库和多个副库，主库读写，副库做备份，当然也可以用作只读库。这种方式比较简单而且没有实现自动故障处理，不做细节介绍。

第二种是Replica方式，这也是一种类主从的方式，主库写，副库读，当初始化数据库连接时，需要指定多个（但不是全部）数据库节点。当主库出问题时，这种方式下可以自动从副库中选出更新时间最接近的一个库提升为主库，其他的作为副库，也可以通过优先级判断。当主库恢复的时候，可以将其加入Replica set，再将其提升为主库。

第三种是Sharding方式，sharding是指分片，将不同的数据部分放到不同的数据服务器上，同时每个片可以是单点，也可以是Replica set，这样就实现了高性能和安全。片也是可以后期加入，mongo将自动分配压力到不同分片，把新数据放到新的分片上但是不会移动老的数据，所以如果想要更好的分配各分片的压力，需要设定更合理的拆分键值和方式。

我们的服务由于数据条目数量巨大，又需要排除单点，保证可用性，故选用了Sharding+Replica set的方式。

//=======

下面简要说一下mongodb的安全验证：

单点的mongo可以设定各库的用户名密码，很简单不消说，当需要对Replica set和sharding方式增加用户验证就麻烦一些，现在版本（2.0.2）已经实现了这两个方式的用户验证，不过需要对每个点增加秘钥。

秘钥是一串6-1024位的base64编码方式的字符串，每一个介入的mongo服务（包括replice，shard，config和monogs）的配置中都需要包含这个key文件，之后可以在admin库中设置密码，当设置好密码之后，访问所有配置功能和已有用户的数据库就需要用户名密码验证之后才能通过了。

mongo的权限设置仍然稍微简单，比如并没有对某库的只读权限等的细分，希望以后的版本可以增加吧。