<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>臭皮匠 &#187; linux</title>
	<atom:link href="http://guogoul.com/category/linux/feed/" rel="self" type="application/rss+xml" />
	<link>http://guogoul.com</link>
	<description></description>
	<lastBuildDate>Fri, 29 Oct 2010 00:24:37 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>担心部署分布式 Memcached 导致问题</title>
		<link>http://guogoul.com/2010/10/27/memcached-danger/</link>
		<comments>http://guogoul.com/2010/10/27/memcached-danger/#comments</comments>
		<pubDate>Wed, 27 Oct 2010 12:09:08 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[memcached]]></category>
		<category><![CDATA[php]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=264</guid>
		<description><![CDATA[Memcached在很多时候都是作为数据库前端cache使用的,大大降低数据库压力，使系统执行效率提升.
memcached虽然称为“分布式”缓存服务器，但服务器端并没有“分布式”功能,memcached的分布式，则是完全由客户端程序库实现的.
客户端实现分布是memcached分布式的一个特点.这个特点提供了开发者,最大的自由度,但也容易导致问题的的发生.
以Php::Memcache为例子:

$memcache = new Memcache;
$memcache-&#62;addServer(&#8217;192.168.123.4&#8242;, 11211);
$memcache-&#62;addServer(&#8217;192.168.123.6&#8242;, 11211);
$memcache-&#62;addServer(&#8217;192.168.123.7&#8242;, 11211);
$memcache-&#62;set(&#8221;justfortest2&#8243;,7);
情况1.   192.168.123.6 服务器不太稳定,当192.168.123.6请求失败的时候 .memcache可能会去请求192.168.123.7.  这样会导致数据可能cache在多个服务器中,数据的不一致问题就会产生.
情况2.  如果在写代码过程中addserver的顺序出错,或者增加,或者减少server.那么数据分布情况就会改变. 由于php::memcache中的分布式算法是基于服务器数量以及添加的顺序的.  当然频道增加server,或者 减少server是很少存,但是addserver的顺序就不太好约束了.  为了保证数据一致性,服务器的增加与减少最好是重启一下所有缓存.
建议:
1. 尽量把缓存放到单机上面,
2. 在压力大的情况下为了缓解网络连接压力,或者增加缓存空间大小.做了分布式缓存.这样就得做好机器的监控.检查机器的稳定情况,保证缓存服务器的正常工作
参考:  http://gihyo.jp/dev/feature/01/memcached/0004
]]></description>
		<wfw:commentRss>http://guogoul.com/2010/10/27/memcached-danger/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>oom-killer 的发现 与 swap分区搭建</title>
		<link>http://guogoul.com/2010/04/28/oom-killer-swap/</link>
		<comments>http://guogoul.com/2010/04/28/oom-killer-swap/#comments</comments>
		<pubDate>Wed, 28 Apr 2010 08:07:38 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[技术]]></category>
		<category><![CDATA[awstats]]></category>
		<category><![CDATA[cacti]]></category>
		<category><![CDATA[crontab]]></category>
		<category><![CDATA[nagios]]></category>
		<category><![CDATA[swap]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=257</guid>
		<description><![CDATA[很不幸机器最近1周一台跑了3年多的机器挂了两次.为了过好5/1决定好好检查一下情况,不幸的是到目前为止还是没有确认最终的因素.
1.检查案发时间:通过cacti的记录,发现机器发生不幸发生在0点到2点之间.这个时间段是后台定时任务运行的高发期.
2.判断一:夜间机器后台任务太过集中,机器load太高,机器年久老化导致机器不堪重负
3.措施: 排查所有crontab中的任务,注释了其中有可以有计算压力太大的任务.把nagios的load报警设到5以下.
4.结果: 不幸在第二次发生.
5.查询日志: 发现在案发时间的日志中记录有关 oom-killer (out of memory)的记录.难道是这个做怪?有关oom请移步http://www.dbanotes.net/database/linux_outofmemory_oom_killer.html.  看了一下本机的内存.发现没有swap分区(当年装机的同事为了提高工作效率) . 再次观察cacti中的内存趋势.内存第天基本没有free.  细看一下crotab中的任务.发现每天2点左右确实有一个吃内存的awstats有跑着.
6.措施: 添加swap别让oom-killer 工作了.
7.添加SWAP:
7.1:   设置swap路径及大小:    dd if=/dev/zero of=/var/swap bs=1024 count=8192000  (内存4G,swap习惯设为其2倍)
7.2:  设置交换文件:  mkswap /var/swap
7.3: 启用交换分区: swapon /var/swap
7.4: 开机自挂:    在/etc/fstab中加上这一行  /var/swap swap swap defaults 0 0
8: 先到这儿吧,让他跑几天,查看日志看看问题解决情况,祝自己好运,能睡个好觉
]]></description>
		<wfw:commentRss>http://guogoul.com/2010/04/28/oom-killer-swap/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>转载 snmp 重要的OID 备忘</title>
		<link>http://guogoul.com/2010/01/21/snmp-oid/</link>
		<comments>http://guogoul.com/2010/01/21/snmp-oid/#comments</comments>
		<pubDate>Thu, 21 Jan 2010 08:33:13 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[技术]]></category>
		<category><![CDATA[snmp]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=238</guid>
		<description><![CDATA[转载自：
1. http://www.sysadmin.md/most-useful-snmp-oids.html
2. http://blog.chinaunix.net/u2/70049/showart_1136607.html
CPU
Percentages of user CPU time (ssCpuUser)
.1.3.6.1.4.1.2021.11.9
Percentages of system CPU time (ssCpuSystem)
.1.3.6.1.4.1.2021.11.10
Percentages of idle CPU time (ssCpuIdle)
.1.3.6.1.4.1.2021.11.11
Load
1 minute Load (laLoad.1)
.1.3.6.1.4.1.2021.10.1.3.1
5 minute Load (laLoad.2)
.1.3.6.1.4.1.2021.10.1.3.2
15 minute Load (laLoad.3)
.1.3.6.1.4.1.2021.10.1.3.3

Memory
Total Swap Size configured for the host (memTotalSwap)
.1.3.6.1.4.1.2021.4.3
Available Swap Space on the host (memAvailSwap)
.1.3.6.1.4.1.2021.4.4
Total Real/Physical Memory Size on the host (memTotalReal)
.1.3.6.1.4.1.2021.4.5
Available Real/Physical Memory Space on the host (memAvailReal)
.1.3.6.1.4.1.2021.4.6
Total RAM [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2010/01/21/snmp-oid/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>APC cause problems</title>
		<link>http://guogoul.com/2010/01/05/apc_problems/</link>
		<comments>http://guogoul.com/2010/01/05/apc_problems/#comments</comments>
		<pubDate>Tue, 05 Jan 2010 04:24:24 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[Web开发]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[apc]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=235</guid>
		<description><![CDATA[看技术文档的时候很多作者的警告明知很重要，但经常被我们当作耳边风。不是我们有意把它们忘记，只是很多事情只是经历过之后才能铭记在心。
============================================
    APC will probably be 20-30% faster, but if you are writing to it frequently it can cause problems. The APC cache is best for things that change very rarely. And by very rarely I mean days, not hours or minutes.
    Because of the way APC does an anonymous [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2010/01/05/apc_problems/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>lsof:list open file</title>
		<link>http://guogoul.com/2009/11/04/lsoflist-open-file/</link>
		<comments>http://guogoul.com/2009/11/04/lsoflist-open-file/#comments</comments>
		<pubDate>Wed, 04 Nov 2009 15:29:39 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[tools]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=226</guid>
		<description><![CDATA[lsof的参数很多，不过搞来搞去无非是根据什么条件找出被进程打开的文件句柄。条件有根据文件名，文件夹，进程名，端口号，gid,fd等，太丰富了。当你用到的时候再查手册也来得及。
本人用这个解决的最头痛的问题是：一次由于磁盘空间占用较高了，于随手删除了几个大文件，然后用df查看文件系统使用情况，发现一直没有变。搞了半天找不出个所以然来，了解这个命令之后查询了一下这个系统中所有被打开的文件，发现原来那几个大文件被某个程序使用着呢。关闭那个进程后df结果正常。
]]></description>
		<wfw:commentRss>http://guogoul.com/2009/11/04/lsoflist-open-file/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>dd用于磁盘读写性能测试</title>
		<link>http://guogoul.com/2009/11/04/dd/</link>
		<comments>http://guogoul.com/2009/11/04/dd/#comments</comments>
		<pubDate>Wed, 04 Nov 2009 15:02:26 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[tools]]></category>
		<category><![CDATA[dd]]></category>
		<category><![CDATA[disk]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=224</guid>
		<description><![CDATA[dd是一个linux下的文件复制和转换程序。除非告诉dd命运去进行某种转换操作，否则它只是进行从输入文件到输出文件的复制工作。不过现在dd更多的用来进行磁盘性能的测试，而不是原始用于copy的意图。
/dev/null：回收站、无底洞. 你可以输入任何东西它不会吃撑着（这种能力吃自助比较合适）
/dev/zero：用于产生字符，会产生无尽的0字符
以下转换自网络(http://www.xclinux.cn/?p=777):不知是否原创，copy过来自己备忘！
1.测试磁盘写能力
time dd if=/dev/zero of=/test.dbf bs=8k count=300000
因为/dev/zero是一个伪设备，它只产生空字符流，对它不会产生IO，所以，IO都会集中在of文件中，of文件只用于写，所以这个命令相当于测试磁盘的写能力。
2.测试磁盘读能力
time dd if=/dev/sdb1 of=/dev/null bs=8k
因为/dev/sdb1是一个物理分区，对它的读取会产生IO，/dev/null是伪设备，相当于黑洞，of到该设备不会产生IO，所以，这个命令的IO只发生在/dev/sdb1上，也相当于测试磁盘的读能力。
3. 测试同时读写能力
time dd if=/dev/sdb1 of=/test1.dbf bs=8k
这个命令下，一个是物理分区，一个是实际的文件，对它们的读写都会产生IO（对/dev/sdb1是读，对/test1.dbf是写），假设他们都在一个磁盘中，这个命令就相当于测试磁盘的同时读写能力。
]]></description>
		<wfw:commentRss>http://guogoul.com/2009/11/04/dd/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>lvs+keepalived 实现负载均衡及快速故障转移</title>
		<link>http://guogoul.com/2009/09/12/lvs_keepalived/</link>
		<comments>http://guogoul.com/2009/09/12/lvs_keepalived/#comments</comments>
		<pubDate>Sat, 12 Sep 2009 15:01:23 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[tools]]></category>

		<guid isPermaLink="false">http://john.renren.in/?p=114</guid>
		<description><![CDATA[负载均衡主要有两种方式：硬件均衡器，软件均衡。前者是靠钱解决问题的，性能绝对优于后者，这次还是继续上回的穷人话题。如何利用省钱的方案简单的解决负载均衡以及故障转移。先上一个机器部署的示意图。

LVS:  linux virtual server
lvs就是国产的优秀开源的项目之一，最简单的理解就是建立一个虚拟IP的服务器，然后通过这个虚拟机器把前端的请求转发到后面的真实服务器上实现负载分配。对于老的linux版本需要给系统打上ipvs的补丁，对于新的linux系统已内置了ipvs模块。

 lsmod &#124;grep ip_vs   #查看是否已加载ipvs模块
 sudo modprobe ip_vs  #加载ip_vs模块

为了方便进行ipvs管理，还需要安装ipvsadm

sudo apt-get install ipvsadm

关于lvs工作模式的介绍这里有篇IBM的文档对lvs的三种模式的原理，说得十分的详细。
keepalived： 实现机器的心跳检查以及机器的故障转移。
1. 当真实生产机器出现故障的时候，会自动把出问题的机器从集群中删除，当出问题的机器恢复正常的时候，也会自动把机器自动添加到集群中来。这样就可以很平滑很方便维护线上的生产机器。
2. 从图中可以看出，如果没有备份虚机(192.168.1.200)的话。在192.168.1.100机器上还是出现了单点问题。keepalived会在192.168.1.100故障的情况下，把VIP切到192.168.1.200.这其中用到了vrrp协议。注： 开防火墙的朋友得把这两台机器的vrrp端口打开。不然keepalived无法实现主备机器的切换。
上配置文件喽！
192.168.123.100与192.168.123.200
软件：
1.ip_vs
2.ipvsadmin
3.keepalived

/etc/keepalived/keepalived.conf

global_defs {
        notification_email {
                test@gmail.com
       [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2009/09/12/lvs_keepalived/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>nagios+libfetion+midpssh 网络监控报警解决一条龙</title>
		<link>http://guogoul.com/2009/09/11/nagioslibfetionmidpssh/</link>
		<comments>http://guogoul.com/2009/09/11/nagioslibfetionmidpssh/#comments</comments>
		<pubDate>Fri, 11 Sep 2009 15:35:13 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[tools]]></category>
		<category><![CDATA[技术]]></category>

		<guid isPermaLink="false">http://john.renren.in/?p=115</guid>
		<description><![CDATA[nagios: 一款出色的网络数据监控报警工具  http://nagios.org
libfetion:  移动飞信的非官方lib    http://www.libfetion.cn/
midpssh:  移动端的ssh客户端 http://www.xk72.com/midpssh/
当然以上三者的结合，就是要解决服务器问题最快发现，最快通知，最快解决的方案。
在没有搭建这个报警平台之前，每天都在担心中度过，对所有机器的健康状态基本没谱，现在轻松了很多,一些机器都很长时间没登录上去过问了。下面分享一下经验，供所有像我一样的穷网管借鉴，的确只是一条穷人的经验。
一.搭建nagios：
关于nagios的安装，可以上网搜索一大把，这里就不在详细介绍。基本上有两种安装方式：
1。 用apt-get安装现成的软件包。 哈哈简单吧
2.   源码安装，参考资料最好的是官方说明文档,详细的出你的意料 
和cacti一样，nagios在安装的时候就存在一些基本的监控脚本供使用，如果需要一些其它监控脚本可以自己扩展，或者下载一些现成的扩展。呵呵，这个网站提供的扩展够你爽  。
基本配置文件路径:
/usr/local/nagios/etc/nagios.cfg
在nagios.cfg中把很多监控对象都的子配置文件都存放到了 /usr/local/nagios/etc/objects 目录中
nagios提供了监控信息的web与wap展示以及设置。也就是说大部分的工作都可以在web前台完成。
apache的部分配置：


#  SSLRequireSSL
   Options ExecCGI
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2009/09/11/nagioslibfetionmidpssh/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>snmpd又囧了我一把</title>
		<link>http://guogoul.com/2009/09/06/snmpd_loos/</link>
		<comments>http://guogoul.com/2009/09/06/snmpd_loos/#comments</comments>
		<pubDate>Sat, 05 Sep 2009 16:10:54 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[snmp]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=206</guid>
		<description><![CDATA[昨天机器硬盘问题，导致整机挂掉，真是让我郁闷，还好数据都是可恢复的。
最让我不爽的是却是snmpd，用snmpwalk检查localhost的信息一点问题都没有，可是其它机器snmpwalk这台机器的时候，死活超时。我原先以为是机器iptables设置的问题（这里面还有故事，哈哈）,结果发现snmpd端口是开着的。万分不爽，求助朋友，在朋友的提醒之下发现原来snmpd默认安装只监听本机的127.0.0.1端口。于是改之，重启，一切正常

netstat -natup &#124; grep 161 #检查snmp的监听情况
sudo vi /etc/default/snmpd  #打开配置文件

#SNMPDOPTS='-Ls.d -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid #去看后面的IP
sudo /etc/init.d/snmpd restart

iptables插曲： 我再次把自己的关在了机器 外面（远程访问不了了）。
第一次，修改了ssh的端口，但是iptables没有打开相应ssh端口。结果运程访问不了了。
这一次：直接iptables -F INPUT 结果远程连接直接断了。
注：禁用firewall:
sudo iptables -P INPUT ACCEPT
sudo iptables -F INPUT
]]></description>
		<wfw:commentRss>http://guogoul.com/2009/09/06/snmpd_loos/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>首次参与beta技术沙龙</title>
		<link>http://guogoul.com/2009/08/23/blogbeta_snmp/</link>
		<comments>http://guogoul.com/2009/08/23/blogbeta_snmp/#comments</comments>
		<pubDate>Sun, 23 Aug 2009 14:18:20 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[技巧]]></category>
		<category><![CDATA[snmp]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=197</guid>
		<description><![CDATA[    前两天在“TL”上看到这次沙龙的讨论话题.由于对服务的监控这个议题比较感兴趣，工作中也时常会用到，所以今天去围观学习一下。今天参加的朋友比想像中的要少，不过朋友的交流比预期的好.此次聚会上还见到了一个没见过面的老朋友。感谢霍大哥的分享。


       此次活动的主要议题是如何用snmp来对网络服务器的监控，不过老霍的ppt到目前为止还没有分享出来。


       此次沙龙中提到的服务器监控方案我觉得很有想像力，问题解决的也很完美。不过个人感觉会存在以下几点问题：
1. snmp协议相对软件开发人员来说都比较陌生。这种个性化的监控体系可能存在不易长期维护的危险（相对于cacti+net_snmp来讲）

2. 树型的网络拓扑，导致子节点的信息依赖与于父节点，如果父节点挂掉，子节点的信息就无从获取。
3. 服务与机器的信息是被动的被收集，感觉没有机器主动post相关的信息到信息数据中心好。因为信息数据中心定期去取信息，可能存在定期内完不成任务导致死循环，而节点主动post信息给信息数据中心肯定不会存在这个问题，除非同时并发很多的请求。按目前的沙龙中提到的案例5s中收到几百个post应该不会是个问题。

感觉 beta 技术沙龙的所有与会者的分享。
更新： blogbeta已把视频和ppt放出了
]]></description>
		<wfw:commentRss>http://guogoul.com/2009/08/23/blogbeta_snmp/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

