linux问题定位

 CPU 内核CPU调度器功能和性能

线程的状态分析主要是分析线程的时间用在什么地方，而线程状态的分类一般分为：
a. on-CPU：执行中，执行中的时间通常又分为用户态时间user和系统态时间sys。
b. off-CPU：等待下一轮上CPU，或者等待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。

 分析工具

uptime  平均负载   当前时间、系统运行了多久时间、当前登录的用户有多少，以及前 1、5 和 15 分钟系统的平均负载。

vmstat 包括系统范围的cpu负载   些信息都存在/proc/stat 

mpstat 查看所有cpu核信息

# mpstat 2 5 每两秒更新一次，一共更新5次      CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle

top  监控每个进程的cpu用量

sar -u  查看cpu信息

pidstat 查看每个进程cpu用量分解       pidstat命令输出进程的CPU占用率，该命令会持续输出，并且不会覆盖之前的数据，可以方便观察系统动态

# pidstat 2 10   以2秒为采样周期，输出10次cpu使用统计信息

perf    cpu剖析和跟踪 性能计数分析

uptime,vmstat,mpstat,top,pidstat只能查询到cpu及负载的的使用情况。
perf可以跟着到进程内部具体函数耗时情况，并且可以指定内核函数进行统计，指哪打哪  perf是一款综合性分析工具，大到系统全局性性能，再小到进程线程级别，甚至到函数及汇编级别

Perf是一个包含22种子工具的工具集，以下是最常用的5种：

perf-list  Perf-list用来查看perf所支持的性能事件，有软件的也有硬件的

perf-stat  用于分析指定程序的性能概况  # perf stat ls

perf-top

perf-record

收集采样信息，并将其记录在数据文件中。

随后可以通过其它工具(perf-report)对数据文件进行分析，结果类似于perf-top的

perf-report

 

内存 

free,vmstat,top,pidstat,pmap只能统计内存信息以及进程的内存使用情况

valgrind可以分析内存泄漏问题

dtrace动态跟踪。需要对内核函数有很深入的了解，通过D语言编写脚本完成跟踪。

 

磁盘IO

iostat

iotop

pidstat

perf

pidstat -d 1 -p pid
//查看系统IO的请求，比如可以在发现系统IO异常时，可以使用该命令进行调查，就能指定到底是什么原因导致的IO异常

网络

ping 通过icmp封包 来测试整个网络状况

traceroute  检测发出去的数据包  从发出主机到接收主机经过的网关数量

netstat  检测本机各端口连接状况  ip tcp udp  icmp相关协议统计数据

ss  获取socket统计信息

sar -n DEV 网卡流量信息统计

sar -n SOCK   查询网络 tcp udp状态信息。

 

ss -t -a
//显示sockets摘要信息
ss -s
//显示所有udp sockets
ss -u -a
//tcp,etcp状态
sar -n TCP,ETCP 1
//查看网络IO
sar -n DEV 1
//抓包以包为单位进行输出
tcpdump -i eth1 host 192.168.1.1 and port 80
//抓包以流为单位显示数据内容
tcpflow -cp host 192.168.1.1

 

提示报错 Linux error : No space left on device

# df –h

通过‘ls -i’命令可以查看文件名对应的inode号

如果要查看这个文件更详细的inode信息，可以通过stat命令来实现

# stat install.log

解决问题

# find /var/spool/clientmqueue/ -name “*” –exec rm –rf {} \;

 

可以通过下面的命令查看某个磁盘分区inode的总数

# dumpe2fs –h /dev/sda3 |grep ‘Inode count’

 

文件已经删除，但是空间没有释放的原因

由于linux没有回收站功能，所以线上服务器上所有要删除的文件都会先移到系统/tmp目录下，然后定期清除/tmp目录下的数据。

统分区中并没有单独划分/tmp分区，这样/tmp下的数据其实占用根分区的空间，既然找到了问题，那么删除/tmp目录下一些占用空间较大的数据文件即可。

# du –sh /tmp/* | sort –nr |head -3

# rm /tmp/access_Iog  access_log，这个文件应该是apache产生的访问日志文件

 

从输出来看，根分区空间仍然没有释放，这是怎么回事

一般来说不会出现删除文件后空间不释放的情况，但是也存在例外，比如文件进程锁定，或者有进程一直在向这个文件写数据，要理解这个问题，就需要知道linux下文件的存储机制和存储结构。

一个文件在文件系统中存放分为两个部分：数据部分和指针部分，指针位于文件系统的meta-data中，在将数据删除后，这个指针就从meta-data中清除了，而数据部分存储在磁盘中。在将数据对应的指针从meta-data中清除后，文件数据部分占用的空间就可以被覆盖并写入新的内容，之所以出现删除access_log文件后，空间还没有释放，就是因为httpd进程还在一直向这个文件写入内容，导致虽然删除了access_Ilog文件，但是由于进程锁定，文件对应的指针部分并未从meta-data中清除，而由于指针并未删除，系统内核就认为文件并未被删除，因此通过df命令查询空间并未释放。

问题排查：

既然有了解决思路，那么接下来看看是否有进程一直在向access_log文件中写入数据，这里需要用到linux下的losf命令，通过这个命令可以获取一个仍然被应用程序占用的已删除文件列表

# lsof |grep delete

从输出可以看出，/tmp/access_log文件被进程httpd锁定，而httpd进程还一直向这个文件写入日志数据

解决问题：

到这里问题就基本排查清楚了，解决这一类问题的方法有很多，最简单的方法就是关闭或者重启httpd进程，当然重启操作系统也可以。不过这些并不是最好的办法，对待这种进程不停对文件写日志的操作，要释放文件占用的磁盘空间，最好的方法是在线清空这个文件，具体可以通过如下命令完成:

# echo “ ” >/tmp/access_log

这种方法经常用于在线清理apache /tomcat/nginx等web服务产生的日志文件。

 

too many open files”错误与解决方法

这是一个基于java的web应用系统，在后台添加数据时提示无法添加，于是登陆服务器查看tomcat日志，发现如下异常信息，java.io.IOException: Too many open files

通过这个报错信息，基本判断是系统可以用的文件描述符不够了，由于tomcat服务室系统www用户启动的，于是以www用户登陆系统，通过ulimit –n 命令查看系统可以打开最大文件描述符的数量

$ ulimit –n

65535

ulimit命令的使用

在使用ulimit时，有以下几种使用方法：

1、 在用户环境变量中加入

如果用户使用的是bash，那么可以在用户目录的环境变量文件.bashrc或者.bash_profile中加入“ulimit –u128”来限制用户最多可以使用128个进程

2、 在应用程序的启动脚本中加入

如果应用程序是tomcat，那么可以再tomcat的启动脚本startup.sh中加入‘ulimit –n 65535’来限制用户最多可以使用65535个文件描述符

3、 直接在shell命令终端执行ulimit命令

这种方法的资源限制仅仅在执行命令的终端生效，在退出或者和关闭终端后，设置失效，并且这个设置不影响其他shell终端

既然ulimit设置没有问题，那么一定是设置没有生效导致的，接下来检查下启动tomcat的www用户环境变量是否添加ulimit限制

继续检查tomcat启动脚本startup.sh文件是否添加了ulimit限制，检查后发现也没有添加。最后考虑是否将限制加到了limits.conf文件中，于是检查limits.conf文件，操作如下

# cat /etc/security/limits.conf |grep www

www soft nofile 65535

www hard nofile 65535

检查后发现，www用户并无ulimit限制

从输出可知，ulimit限制加在limits.conf文件中，既然限制已经添加了，配置也没有什么错，为何还会报错，经过思考，判断只有一种可能，那就是tomcat的启动时间早于ulimit资源限制的添加时间，于是首先查看下tomcat启动时间，操作如下

# uptime

Up 283 days

# pgrep –f tomcat

4667

# ps –eo pid,lstart,etime|grep 4667

4667 Sat Jul 6 09;33:39 2013 77-05:26:02

# stat /etc/security/limits.conf

通过stat命令清除的看到，limits.conf文件最后的修改时间是2013年7月12，晚于tomcat启动时间，清楚问题后，解决问题的方法很简单，重启一下tomcat就可以了。

 

 

（Apache常见错误故障案例）”no space left on device “错误与解决方法

看看httpd进程是否存在及httpd端口是否正常启动

# ps –ef |grep httpd|grep –v “grep” |wc –l

0

# netstat –nultp |grep 80

# /usr/local/apache2/bin/apachectl start

# ps –ef |grpe httpd |grep –v “grep” |wc –l

0

这个操作首先查看了服务器上的httpd进程，发现并没有HTTP进程运行，同时httpd对应的端口80也并没有启动，于是重启Apache，在启动Apache的过程中并没有报错，启动完成后发现仍然HTTP进程没有运行，由此看来，应该是Apache内部出现了问题

解决思路：

在判断Apache问题后，首先要看的就是Apache的启动日志，在查看Apache的error日志后，发现了一个可疑输出，内容为：

No space left on device : mod_rewrite: could not create rewrite_log_lock configuration failed

看到这个错误提示，感觉应该是磁盘空间耗尽导致，于是赶紧查看系统系统所有磁盘分区，结果发现所有磁盘分区都还有很多可用空间，

linux对磁盘空间的占用分为三个部分:物理磁盘、inode节点磁盘空间和信号量磁盘空间。通过检查服务器的物理磁盘空间，发现仍有很多剩余，因此排除物理空间的问题，接着通过”df -i”命令查看系统可用的inode节点，发现每个分区可以用的inode还有很多，这样inode节点问题也被排除了，那么应该是信号量磁盘空间耗尽导致的。

 

信号量是一种锁机制，用于协调进程之间互斥的访问临界资源，以确保某种共享资源不被多个进程同时访问。Linux系统的信号量是用于进程间通信的。它有两种标准实现，分别是POSIX及System v ，现在大多数linux系统都实现了这两种标准，这两种标准都可用于进行线程间的通信，只是系统调用方式略有不同。

System v 信号量通过系统调用semget来创建，通过linux命令ipcs即可显示进程间通信用的system v 类型信号量及共享内存。

Posix 信号量可用于线程和进程间通信，并可分为有名和无名两种，也可以理解为是否保存在磁盘上。

解决问题：

# cat /proc/sys/kernel/sem

# ipcs –s |grep daemon

Daemon是启动Apache进程的用户，默认是daemon，也可能是nobody用户，根据实际环境而定。解决信号量耗尽的方法很简单，通过ipcrm命令清除即可，最简单方法是执行如下命令组合：

# ipcs –s |grep nobody |perl –e ‘while (<STDIN>) { @a=split(/\s+/);print `ipcrmsem $a[1]` }’

 

linux系统无法启动的解决方法

1） 文件系统破坏，一般是linux的根分区文件系统遭到破坏 系统突然掉电或者非法关机引起的

Checking root filesystem

/dev/sda6 contains a file system with errors, check forced

An error occurred during the file system check

解决此问题的方法是采用fsck命令，进行强制修复。

# umount /dev/sda6

# fsck.ext3 –y /dev/sda6

当某些服务不能访问的时候，一定要检查是否被linux本机防火墙iptables屏蔽了，可以通过iptables –L –n 命令检查iptables的配置策略。

# iptables –L –n

# iptables –A INPUT –i eth0 –p tcp --dport 80 –j ACCEPT

# iptables –A OUTPUT –p tcp --sport 80 –m state –state ESTABLISHED –j ACCEPT

 

.Tcpdump-网络包分析器
Tcpdump是最广泛使用的网络包分析器或者包监控程序之一，它用于捕捉或者过滤网络上指定接口上接收或者传输的TCP/IP包。