[转] 工程师追查线上问题(或运维)常用的shell命令

标签: 工程师 线上 问题 | 发表时间:2015-01-15 18:03 | 作者:ww111
出处:http://www.iteye.com

 

shell本身是非常强大的,而工程师在追查线上问题时,如何能够更加快速更加有效的定位问题,用好shell非常关键。下面是我总结的几个在追查问题时常用的shell命令。大家可以参考下。大家有好的命令,也可以在这之上完善。

1、日志分析类:

(1)

cut -d ‘’ -f4 wap_log |sort |uniq -c

 

比如cpu idle急剧下降,要看一下当前的流量如何,是否是由于流量突增引起。可以使用该命令:

其中wap_log是日志名,4 是时间那一列,简单介绍下这个shell命令。

这是一行实例日志行:

218.203.63.190 – - [09/Feb/2012:12:15:03 +0800] “GET /view/102795.html HTTP/1.1″ 200 4557 “-” “MAUI WAP Browser” “jid=XKYGPzLXwG!70061790;$path=/” 76

在这个shell命令中,cut先根据空格分隔符对日志行进行分割,然后取第4个field,也就是时间,取到时间后,对时间进行排序,排序后,再去重,计数。这样就可以输出每个时间段的日志浏览量。

下面是改shell的输出实例:

18 [09/Feb/2012:12:54:51

14 [09/Feb/2012:12:54:52

11 [09/Feb/2012:12:54:53

10 [09/Feb/2012:12:54:54

12 [09/Feb/2012:12:54:55

15 [09/Feb/2012:12:54:56

11 [09/Feb/2012:12:54:57

第一列是个数,第二列是时间,当然,也可以针对于这个在后面再用awk任意发挥,比如找出浏览量大于x的时间段,等等。这样就可以清楚的看到,每个时间点的请求数,从而判定是否是请求数过大导致。

 

(2)

cat access_log |awk 'BEGIN{sum=0;count=0;}{sum+=$NF;count++;}END{printf("sum=%d,count=%d,avg=%f\n",sum,count, sum/count)}'

access_log为日志名,用awk切割后,$NF为最后一个域,就是耗时域,所以这条命令的作用就是计算平均耗时。

下面是该shell的实例输出:

sum=3121224,count=96000,avg=32.512750

2、性能分析类:

(1)

ps aux | sort –n –k 5 | tail

得到耗内存最大的10个进程。

ps aux 就不用解释了,后面sort,-n代表按照数字大小进行排序,-k代表排序的key  6 代表第6列,第6列就是占用内存大小列。

下面是输出:

**     11800  0.0  0.0 261652 49316 ?      S     2011   3:32 **.

**     11801  0.0  0.0 261652 49316 ?      S     2011   3:33 **.

**    11802  0.0  0.0 261652 49316 ?      S     2011   3:33 **.

**    11803  0.0  0.0 261652 49316 ?      S     2011   3:33 **.

**     11804  0.0  0.0 261652 49316 ?      S     2011   3:33 **.

**    11805  0.0  0.0 261652 49316 ?      S     2011   3:32 **.

**     25511  0.0  0.0 261652 49316 ?      S     2011   1:15 **.

**    25512  0.0  0.0 261652 49316 ?      S     2011   0:00 **.

**     28391  1.4  0.5 547488 369664 ?     Ssl  Jan16 501:58 **

(**为用户名和进程名,已隐藏。)

(2)

ps aux | sort –n –k 4 | tail

同理,这是得到cpu消耗最大的10个进程

(3)

lsof

当然lsof不属于性能分析类,但是该命令又经常会用到:

 

lsof filename

显示开启filename这个文件的进程名

 

lsof –i:8099

查看开启8099端口的进程

(4)

netstat

查找端口的进程名除了用lsof外,也可以用netstat,

直接netstat –nlp | grep port即可

 

不过一般只有root权限才可以用lsof,普通用户的话,可以使用/usr/sbin/lsof 不过一般没有太多有价值的信息。

3、其他类:

(1)rsync命令

rsync命令一般用来和线上机同步代码,那他和scp有什么不同呢? 一个是rsync命令可以方便的exclude,scp无法方便的exclude.另外,有一个很重要的不同是,rsync可以保持软链,但scp不能保持软链。就是说,scp在执行过程中,不会识别软链,而是直接当做普通文件夹来处理。另外,比较重要的是,rsync为增量同步,scp为全量

一般同步命令如下:

rsync -av –bwlimit=2000 –progress –exlude=”log” 源地址  目标地址

-av这个参数大家可以到网上搜下,这里就不再详解了,av这个参数,如果没有特殊需求,就把这个参数带上。

–bwlimit是限速,单位是kb

–progress代表是显示同步进度

–exclude代表,不同步的文件夹,这个文件夹是基于源地址的,也就是说比如exclude写的是log,源地址写的是/home/xx/ 那么,不同步的文件夹就是/home/xx/log。

 

好,对于shell命令,我就先写这么多,大家也可以基于这些命令自由发挥,拼接出更有价值的命令。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [工程师 线上 问题] 推荐:

HBase工程师线上工作经验总结----HBase常见问题及分析

- - 互联网 - ITeye博客
阅读本文可以带着下面问题:. 1.HBase遇到问题,可以从几方面解决问题. 2.HBase个别请求为什么很慢. 3.客户端读写请求为什么大量出错. 4.大量服务端exception,一般原因是什么. 6.Hbase数据写进去,为什么会没有了,可能的原因是什么. regionserver发生abort,遇到最多是什么情况.

[转] 工程师追查线上问题(或运维)常用的shell命令

- - 操作系统 - ITeye博客
shell本身是非常强大的,而工程师在追查线上问题时,如何能够更加快速更加有效的定位问题,用好shell非常关键. 下面是我总结的几个在追查问题时常用的shell命令. 大家有好的命令,也可以在这之上完善. 比如cpu idle急剧下降,要看一下当前的流量如何,是否是由于流量突增引起. 其中wap_log是日志名,4 是时间那一列,简单介绍下这个shell命令.

前端工程师面试问题列表

- - 博客 - 伯乐在线
前言:@ darcyclarke 在 GitHub 上分享了一个 repo,其中包括了不少前端面试问题,可用于检验潜在的候选人. 绝不推荐在单个候选人身上用上所用的问题(那样会花费好几个小时滴). 从这个列表选择一些,应该能从候选人身上,检测出你所需要的技能. 请记住,下面的很多问题都是开放式的,无标准答案,并能引发有趣的讨论.

Uber工程师对真实世界并发问题的研究

- - 鸟窝
我们知道,Go是Uber公司的主打编程语言. 他们对Uber的2100个不同的微服务,4600万行Go代码的分析,发现了超过2000个的有数据竞争的bug, 修复了其中的1000多个,剩余的正在分析修复中. 谈起真实世界中的Go并发Bug,其实2019年我们华人学者的 Understanding Real-World Concurrency Bugs in Go论文可以说是开山之作,首次全面系统地分析了几个流行的大型Go项目的并发bug.

想成为Google工程师?先回答这15个面试问题

- - 搜索引擎技术博客
挑战: 这是一个相当开放性的问题,设计初衷是看看工程师是否会定义参数. 是:那么你得摆手起家开发出一套基本运算来. 否则的话:那就简单了,只需将数字套进去即可,因为大部分语言均支持数学运算. 挑战: 这类问题是Google面试问题的一个共同趋势:找出解决问题的有效办法. 合并两条链表是一般会在链表之间发生“冲突”(因为它们各自有特定的次序,而你的合并会把次序搞乱).

线上性能问题初步排查方法

- - 并发编程网 - ifeve.com
有时候有很多问题只有在线上或者预发环境才能发现,而线上又不能Debug,所以线上问题定位就只能看日志,系统状态和Dump线程,本文只是简单的介绍一些常用的工具,帮助定位线上问题. 1: 首先使用TOP命令查看每个进程的情况,显示如下:. 我们的程序是Java应用,所以只需要关注COMMAND是Java的性能数据,COMMAND表示启动当前进程的命令,在Java进程这一行里可以看到CPU利用率是300%,不用担心,这个是当前机器所有核加在一起的CPU利用率.

线上存储服务崩溃问题分析记录

- - codedump
上周我们的存储服务在某个线上项目频繁出现崩溃,花了几天的时间来查找解决该问题. 由于问题在线上发生,较难重现,首先想到的是能不能加上更多的信息,在问题出现时提供更多的解决思路. 首先,我们的代码里,在捕获到进程退出的信号比如SIGABRT、SIGSEGV、SIGILL等信号时,会打印出主线程的堆栈,用于帮助我们发现问题.

一次线上问题排查所引发的思考

- - crossoverJie's Blog
之前或多或少分享过一些 内存模型、 对象创建之类的内容,其实大部分人看完都是懵懵懂懂,也不知道这些的实际意义. 直到有一天你会碰到线上奇奇怪怪的问题,如:. 线程执行一个任务迟迟没有返回,应用假死. 接口响应缓慢,甚至请求超时. 这类问题并不像一个空指针、数组越界这样明显好查,这时就需要刚才提到的内存模型、对象创建、线程等相关知识结合在一起来排查问题了.

不改一行代码定位线上性能问题

- - crossoverJie's Blog
最近时运不佳,几乎天天被线上问题骚扰. 前几天刚解决了一个 HashSet 的并发问题,周六又来了一个性能问题. 我们提供出去的一个 OpenAPI 反应时快时慢,快的时候几十毫秒,慢的时候几秒钟才响应. 由于这种也不是业务问题,不能直接定位. 所以尝试在测试环境复现,但遗憾的测试环境贼快. 中途有抱着侥幸心里让运维查看了 Nginx 里 OpenAPI 的响应时间,想把锅扔给网络.

线上服务请求慢问题排查

- - 掘金后端
收到测试的消息,项目页面打开很慢. 查看线上JVM监控平台,发现每分钟由于GC暂停的时间 30~50s. jstat -gccause pid time,发现老年代的占比一直在99%左右,并且发生full gc之后,变化很小. 然后,查看线上gc日志,发现老年代的空间在full gc 前后基本无变化.