寻找属于勒色的勒色! 生活、游记、见闻、上海、摄影、计算机、互联网、关注特奥......

2006-10-26

今天整整忙了一天

今天早上一到公司就接到用户电话,QHYD的邮件系统出问题了。我远程登录,发现已经连不上服务器了。派人到现场看发现在终端上也登录不上去了。提示"no shell",我估计是操作系统出了问题,很有可能是文件系统损坏。本来这个系统是安装了VERITAS HA的,可是由于licence的问题没有进行切换。由于局方那边派人也没有恢复成功,只好由我们这里远程手工在另外一台机器上起服务了。
本来只要把Oracle和共享存储挂过来就没问题了,可以直接起服务的。但是却因为挂存储的时候的一点疏忽耽误了很多时间。
挂存储有两个挂载点,这两个挂载点千万不要重复挂载。否则就会发生有些数据找不到的情况。
今天那块1.1T的盘就找不到了,那里有所有用户的数据文件,真让我出了一身冷汗。后来,自己研究发现是挂载存储的是挂的不对,本来应该却1.1T数据的挂载点挂载到别的数据,我以为这些数据丢失了呢,好紧张啊!后来,重新挂载就正常了。

也算今天长了点经验;

另外,我以后需要注意的就是:要更加仔细的看日志,因为有好多问题在日志里面都有反映,不要粗略的看,要尽量的再仔细点,这样对排查问题很关键!

2006-10-23

已经完全不适应挤地铁的日子

我上班一直都是乘坐地铁的,已经将近四年了,标准的地铁族!上海的地铁在早上一直都是很拥挤的,从7点钟开始一直持续到8点45分以后才会缓解。

以前公司9点中上班,我每天都在8点钟挤地铁,这时候基本上是最拥挤的时候。几年下来,我可以说是总结了一套行之有效的挤地铁的方法,例如:上班在那个车门人相对较少;那个车门下车方便换乘;那种车型空调好;如何一手看报一手吃早点,不用拉扶手也不会在车厢失去平衡;如何冲进即将关闭的车门;换乘时如何计算是跑过去还是慢悠悠的走过去就会正好有一班二号线的列车驶来;哪个地方会有一个也是每天乘坐地铁上班的漂亮MM等等;

但是,自从换了工作以后,我就告别的挤地铁的日子了!因为现在我们公司没有考勤,我可以10点钟上班,哈哈!我每天乘坐9点钟空荡荡的地铁,不慌不忙的赶到公司。乘坐这种没有人挤的地铁真是太爽了。

这种日子过了已经半年了,也许我已经适应了这样的上班方式。就在大前天,因为有事,我早起了一回乘坐8点钟的地铁,这时我才发现我已经完全不适应这种生活了!我发现我已经根本没有办法挤进车厢,在以前,比这样更拥挤的车厢我也挤上去过。我尝试了几次,都没有挤上去。我只好在地铁的长椅上看报到8点30时才悠哉悠哉的走上那宽松的地铁,哈哈,只要接受这别“淘汰”的事实,我已经完全不适应这种挤地铁的生活了。可能是我已经不在是9点上班的那些人了,同样是挤地铁,但是动力完全不同了。他们挤不上去就要迟到,于是便非要挤上不可,而我现在已经不用担心这个了。

也许在我下份工作仍然需要九点钟上班的时候,我才会再次变成当年的我,冲在挤地铁人流中!

2006-10-18

MRTG监控脚本

这几天没有更新Blog是因为给一个项目安装MRTG的监控系统。MRTG监控想必大家很收悉了,不过这次安装还是学到一些新东西,拿来跟大家分享一下。
监控网络流量的就不再叙述了,因为这时MRTG的看家本领,大多数人都会,这里说一下监控CPU利用率或者SMTP Queue等等;

要监控这些东西就要先写个脚本,然后让MRTG去读脚本产生的数据,然后以图形的方式呈现出来就可以了。
下面是我写的一些脚本:
监控CPU利用率:

代码

#!/bin/bash
cputmp=`/usr/bin/sar -u 1 4 | tail -1`
cpuusr=`echo $cputmp | awk '{print $2}'`
cpusys=`echo $cputmp | awk '{print $3}'`
UPtime=`uptime |awk -F, '{print $1}'`
echo $cpuusr
echo $cpusys
echo $UPtime
echo `hostname`

这个脚本执行执行结果如下:
代码

2
1
73 day(s) 17:09

表示用户占用2%,系统占用1%,系统已经连续运行了73天17小时零9分。
然后就是让MRTG去读取这些数据,现在写一个MRTG的cfg文件:
代码

WorkDir:/var/www/html/mrtg/
Options[cpu]:gauge, nopercent, growright
Language:chinese
EnableIPv6: no
Target[cpu]:`/var/script/cpu_util.sh`
MaxBytes[cpu]: 100
YLegend[cpu]: CPU loading (%)
ShortLegend[cpu]: %
LegendO[cpu]: CPU Used;
LegendI[cpu]: CPU Sys;
Title[cpu]: Utilization Analysis for CPU -- mail2
PageTop[cpu]:

Utilization Analysis for CPU -- mail2



解释一下上面的一些参数:
WorkDir----生成MRTG页面文件的地方;
gauge----MRTG生成的图片上带有标尺;
nopercent----计算百分比;
growright----图形向右增长;
Language:chinese----页面显示中文,这个地方可以填写其它语言支持;
EnableIPv6----是否支持IPv6;
Target----告诉MRTG去执行那个脚本;
MaxBytes----最大字节数,这里我们监控CPU利用率的百分比,所以最大我们填100,如果监控其它参数要视情况而定;
YLegend----纵坐标(Y轴)单位和参数;
ShortLegend----单位;等页面生成以后你就可以看到这些东西出现的位置,不满意的话可以再进行修改;
LegendO,LegendI----MRTG监控的两个读数分别代表的什么;
Title----这个图片的标题;
PageTop----这个html页面的标题;

然后就是去mrgt去执行这个配置文件生成监控页面;
代码

/usr/local/mrtg/bin/mrtg /usr/local/mrtg/cfg/cpu_until.cfg

这条命令要执行3次以上,直到没有报错;

然后再写进crontab:
代码

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/mrtg/bin/mrtg /usr/local/mrtg/cfg/cpu_until.cfg


这样这个cpu利用率的监控就做好了,5分钟就刷新一次。

一下是监控其它参数的一些脚本,希望对大家有帮助;
HTTP连接数:
代码

#!/bin/bash
HTTP_CONN=`netstat -an|grep ESTABLISHED|awk '$1~/\.80$/ {print $0}'|wc -l`
UPtime=`uptime |awk -F, '{print $1 $2}' | awk '{print $3 " " $4 " " $5}'`
echo $HTTP_CONN
echo $HTTP_CONN
echo $UPtime
echo `hostname`


SMTP连接数、POP连接数只需要修改上面脚本把80更换成25和110即可;
代码

SMTP_CONN=`netstat -an|grep ESTABLISHED|awk '$1~/\.25$/ {print $0}'|wc -l`
POP_CONN=`netstat -an|grep ESTABLISHED|awk '$1~/\.110$/ {print $0}'|wc -l`


内存使用率:
代码

#!/bin/bash
MEM_U=`sar -r 1 5|tail -1|awk '{print $4}'`
UPtime=`uptime |awk '{print $2 " " $3 " " $4 " " $5}'`
echo $MEM_U
echo $MEM_U
echo $UPtime
echo `hostname`


以 上脚本在不同操作系统上可能需要进行小的修改;我都是在solaris9上测试过了,监控内存这个脚本操作系统不同,内存总量不同脚本就不同, solaris显示的是内存空余的数量,所以要用总内存减去空余的才是内存使用的情况;所以这个内存脚本我帖上来的是在linux上跑的一个脚本。脚本的 原理都一样;

2006-10-12

终于领略了微软工程师的实力

这次JSYD存储故障的处理,终于让我领略的微软工程师的实力,果然名不虚传。

我做为邮件系统方面技术人员,从上海赶到JSYD机房现场已经是晚上6点钟,到现场查看,是HP的磁盘阵列出了故障,经过HP的技术人员分析,认为是NAS的机头的Windows2003系统的问题。

微软亚洲技术支持中心的工程师也是从上海赶来,于晚上7点赶到JSYD机房。到了以后便开始了他"神秘"的工作。之所以称之为是"神秘"的工作,原因很很简单,微软的操作系统是不公布源代码的,所以他的操作和他查看的资料都让我们感觉云里雾里,不知道他在干什么。

现在这样的天气,再加上机房里强力空调的风力,都让我们感觉有些"寒冷"了。我们过一段时间都要到外面"暖和暖和",可是那微软工程师坐那地方2个多小时了,愣是没动地方!这次的故障应该算是比较重大了,JS全省的邮件系统瘫痪,将近300万用户的系统。我这里都已经做好了存储不能恢复准备重新做邮件系统的准备了。不过这位微软工程师挺沉稳,丝毫没有乱了阵脚。一行一行的分析日志,分析故障原因。这点就非常值得我学习,有时候我在处理大的故障的时候容易慌乱,这时候反而更容易犯错。

12点时候,这位工程师终于有了动静了。他说要打个补丁来解决这个问题。我和机房的技术人员都笑了,原因很简单,打补丁是微软一贯作风啊,哈哈。那就打吧,希望打了就能解决。

补丁打好了,重启2003。自检过后出现了大家都非常意外但有非常收悉的画面----蓝屏!意外是因为没想到这个工程师几个小时的结果竟然是个蓝屏,熟悉是因为蓝屏是微软的系统中经常出现的现象。这回可不太好,补丁打了还不如不打,打前还能正常启动2003,现在连2003也启动不了了。

不过这时这位工程师仍然没有慌乱,他在认真的分析这那些我从来都没有看过的蓝屏代码。

我们这边更加坚定的开始准备临时存储和邮件系统。

1小时后,微软工程师发现问题原因了。

原因是因为刚才打的补丁和HP的NAS有冲突,这个补丁比HP的NAS出来的晚。要先升级HP的NAS,然后在打补丁!

于是又进入安全模式,卸载刚才的补丁,升级HP的NAS,然后再打补丁。

重启后一切正常了!这个消息对在场所有人来说都是一个非常大的喜讯!

我立即在邮件服务器上挂载存储,重新启动邮件系统,经过测试可以正常工作了!

这次我对微软这位工程师处理问题表现出来的自信和认真的态度表示由衷的敬佩!面对任何问题都能坐怀不乱,静下心来慢慢分析,最终找到处理方法。

2006-10-11

文盲如何使用手机通讯录?

前一段时间帮一个朋友租房子,和房东签合同的时候才发现原来房东是个文盲。

他只认识数字,汉字一点也不认识,和他签合同是个比较令我头疼的问题,老是认为我欺骗他,好在有中介在。

合同终于签好,难免有些事情,房东还是会联系我,我给他留了手机号。

后来房东,几次联系我,我能在电话里面听出来,刚接通的时候,他总是试探性的说"喂"几声。我知道是房东打来的,我就和主动说他的名字,然后再说我的名字,这时他才会和我开始说正题。

但是他还从来没有打错过,至少每次联系我都没有错过,没有发生过找别人时打到我这里来。

开始也没有注意,后来我就在想,他是如何用手机来记录这么多人的电话号码的呢?不会写字,也不会拼音。

房东手机还是诺基亚倾城系列那款,型号我不记得了。这手机也算还可以了,他使用手机的频率也还是挺高的,我和他见面的时候,找他的电话挺多的。

难道他能把那些冰冷的数字和脑海中的每张面孔对应起来?还是有什么其它方法?

据我所知,诺基亚手机目前还没有推出适合文盲用的机型吧?

难道照片通讯簿?每个电话号码对应一个人的照片?一个一个翻照片,翻到想要找的照片,然后拨号?

诺基亚倾城系列好像没有这个功能吧?

难道是语音拨号?

但目前语音拨号据说识别率不是很高,他难道能忍受这样的错误率。电话费估计也不允许吧?!

耐人琢磨的一个问题啊!大家有没有谁知道什么方法比较好?欢迎拍砖!哈哈!

最感动的一幕

十一期间同学结婚,我全程当劳力。从拉嫁妆到半夜贴喜字,从典礼开始到结束真是累的跟驴一样,但也不亦乐乎!
在典礼我负责拍照,抓住了很多精彩的一瞬。但是最令我遗憾的是那最感人的一幕却因为我的沉浸而错过了。
典礼上司仪请新郎父亲上台来,然后给新郎说应该向父亲表达多年来的养育之恩,给父亲一个深情的拥抱吧。
新郎紧紧的抱着父亲,父亲脸上流露着欣慰的笑容……这一幕,我拍下了。
可是最感人是拥抱以后新郎那泛红的眼圈以及强忍着的泪水……
当时我也沉浸在这感人的一幕,以至于错误了这个瞬间。
后来我问了新郎,他说:“哎...感觉哪一刻才发现,我爸真的老了很多,心里酸的狠......”
其实我也有同感,记得姐姐结婚的时候,我也曾在这感人的瞬间泛红眼圈,也让自己强忍这不让眼泪流出。
毕竟七尺男儿,当众人面落泪不好意思。但是现在我想明白了,对父母的爱,应该勇敢的表达,也许我们平时可能对父母的爱的表达太少了。
婚宴上遇到了很多久违了的同学,大家又互留联系方式相互敬酒,仿佛又回到了那无忧无虑的学生时代!

free hit counter