linux优化排错

Awstats日志分析工具
参考笔记本电脑F盘的awstats文档
配置环境
关闭selinux
配置防火墙，开启80端口
[root@Apache-Server~]#vi/etc/sysconfig/iptables
-AINPUT-mstate--stateNEW-mtcp-ptcp--dport80-jACCEPT[root@Apache-Server~]#/etc/init.d/iptablesrestart
安装Awstats
实用防火墙（Iptables）脚本分析
/350944/1338882
故障案例
HTTP状态码
/commons?type=5
200请求已成功，请求所希望的响应头或数据体将随此响应返回。
301被请求的资源已永久移动到新位置
403服务器已经理解请求，但是拒绝执行
404请求失败，请求所希望得到的资源未被在服务器上发现
500服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理
502服务器尝试执行请求时，从上游服务器接收到无效的响应
503由于临时的服务器维护或者过载，服务器当前无法处理请求


LinuxNote
175
File:“/”Size:1024
Blocks:2
IOBlock:1024
目录
Device:803h/2051d
Inode:2
Links:22Access:(0666/drw-rw-rw-)Uid:(
0/
root)
Gid:(
0/
root)
Access:2007-12-0122:28:48.000000000+0800Modify:2007-12-0122:28:34.000000000+0800Change:2007-12-0123:17:35.000000000+0800问题出来了，这里的权限是错误的，X权限的丢失造成的。[root@localhost~]#chmod755/修改后,问题消失。产生上述问题的方法：
第一种，chmod666/，可以导致。或者，
第二种，chmod700/lib/ld-xxxx.so，也可以导致su失败。有兴趣可以自己试一下。
/权限的丢失对于各种运行在自己用户身份上的daemon也存在同样的影响。
“Toomanyopenfiles”错误与解决方法
一、问题现象
这是一个基于Java的Web应用系统，在后台添加数据时提示无法添加，于是登录服务器查看tomcat日志，发现了如下异常信息：java.io.IOException:Toomanyopenfiles
通过这个错误，基本判断是系统可用的文件描述符不够了，由于tomcat服务是系统www用户启动的，于是用www用户登录系统，通过“ulimit-n”命令查看系统可以打开最大文件描述符的数量，输出如下：
[www@tomcatserver~]$ulimit-n65535
可以看到这个服务器设置的最大可打开的文件描述符已经是65535了，这么大的一个值应该够用了，

LinuxNote
176
但是为什么还是提示这么个错误呢？
二、解决思路
这个案例涉及到linux下ulimit命令的使用，这里简单介绍下ulimit的作用和使用技巧。ulimit主要是用来限制进程对资源的使用情况的，它支持各种类型的限制，常用的有：
内核文件的大小限制进程数据块的大小限制Shell进程创建文件大小限制可加锁内存大小限制常驻内存集的大小限制打开文件句柄数限制分配堆栈的最大大小限制
CPU占用时间限制用户最大可用的进程数限制Shell进程所能使用的最大虚拟内存限制ulimit

使用的基本格式为：ulimit[options][limit]
具体的options参数含义如下表所示：选项含义-a
显示当前系统所有的limit资源信息。
-H设置硬资源限制，一旦设置不能增加。-S设置软资源限制，设置后可以增加，但是不能超过硬资源设置。-c最大的core文件的大小，以blocks为单位。-f进程可以创建文件的最大值，以blocks为单位.-d
进程最大的数据段的大小，以Kbytes为单位。
-m最大内存大小，以Kbytes为单位。-n可以打开的最大文件描述符的数量。-s线程栈大小，以Kbytes为单位。-p管道缓冲区的大小，以Kbytes为单位。-u
用户最大可用的进程数。


LinuxNote
177
-v进程最大可用的虚拟内存，以Kbytes为单位。-t最大CPU占用时间，以秒为单位。-l
最大可加锁内存大小，以Kbytes为单位。
在使用ulimit时，有以下几种使用方法：（1）在用户环境变量中加入
如果用户使用的是bash，那么就可以在用户目录的环境变量文件.bashrc或者.bash_profile中加入“ulimit-u128”来限制用户最多可以使用128个进程。（2）在应用程序的启动脚本中加入
如果应用程序是tomcat，那么就可以在tomcat的启动脚本startup.sh脚本中加入“ulimit-n65535”来限制用户最多可以使用65535个文件描述符。（3）直接在shell命令终端执行ulimit命令
这种方法的资源限制仅仅在执行命令的终端生效，退出或者关闭终端后，设置失效，并且这个设置不影响其它shell终端。
有时候为了方便起见，也可以将用户资源的限制统一由一个文件来配置，这个文件就是/etc/security/limits.conf，该文件不但能对指定用户的资源进行限制，还能对指定组的资源进行限制。该文件的使用规则如下：
其中：
domain表示用户或者组的名字，还可以使用*作为通配符，表示任何用户或用户组。Type表示限制的类型，可以有两个值，soft和hard，分别表示软、硬资源限制。
item表示需要限定的资源名称，常用的有nofile、cpu、stack等。分别表示最大打开句柄数、占用的cpu时间、最大的堆栈大小。
value表示限制各种资源的具体数值。
除了limits.conf文件之外，还有一个/etc/security/limits.d目录，可以将资源限制创建一个文件放到这个目录中，默认系统会首先去读取这个目录下的所有文件，然后才去读取limits.conf文件。所有资源限制设置完成后，退出shell终端，再次登录shell终端后，ulimit设置即可自动生效。
三、解决问题



LinuxNote
178
致的，接下来检查下启动tomcat的www用户环境变量下是否添加了ulimit限制，检查发现，www用户下并无ulimit资源限制，于是继续检查tomcat启动脚本startup.sh文件中，是否添加了ulimit限制，检查发现也并无添加，最后考虑是

否将限制加到了limits.conf文件中，于是检查limits.conf文件，操作如下：
123[root@tomcatserver~]#cat/etc/security/limits.conf|grepwwwwwwsoftnofile65535wwwhardnofile65535
从输出可知，ulimit限制是加在了limits.conf文件中，既然限制已经加了，配置也没有错，为何还是报错呢，经过长时间思考，判断只有一种可能，那就是tomcat的启动时间早于ulimit资源限制的添加时间，于是首先查看下tomcat的启动时间，操作如下：123456789[root@tomcatserver~]#more/etc/issueCentOSrelease6.3(Final)Kernel\ronan\m
[root@tomcatserver~]#uptime
15:10:19up283days,5:37,4users,loadaverage:1.20,1.41,1.35[root@tomcatserver~]#pgrep–ftomcat4667
[root@tomcatserver~]#ps-eopid,lstart,etime|grep46674667SatJul609:33:39201377-05:26:02
从输出看，这台服务器已经有283天没有重启过了，而tomcat是在2013年7月6号9点多启动的，启动了近77天零五个半小时了，接着继续看看limits.conf文件的修改时间，操作如下图所示：
通过stat命令可以很清楚的看出，limits.conf文件最后的修改时间是2013-07-12，通过查问相关的Linux系统管理人员，他们基本确认就是在这个时候添加的ulimit资源限制，这样此案例的问题就很明确了。由于ulimit限制的添加时间晚于tomcat最后一次的启动时间，而在此期间内，tomcat



LinuxNote
179
服务一直未重启过，操作系统也一直未重启过，那么ulimit资源限制对于tomcat来说始终是不生效的，同时，由于此操作系统是Centos6.3，系统默认的最大可用句柄数是1024，那么java进程还是用的Linux默认的这个值，出现“Toomanyopenfiles”的错误，也是合乎情理的。问题清楚之后，解决问题的方法非常简单，重启tomcat服务即可。
“Argumentlisttoolong”错误与解决方法
作为一名运维人员来说，这个错误并不陌生，在执行rm、cp、mv等命令时，如果要操作的文件数很多，可能会使用通配符批量处理大量文件，这时就可能会出现“Argumentlisttoolong”这个问题了。1、错误现象
这是一台Mysql数据库服务器，在系统中运行了很多定时任务，今天通过crontab命令又添加了一个计划任务，退出时发生了如下报错：1#crontab-e
编辑完成后，保存退出，就出现下面如下图所示错误：
2、解决思路
根据上面报错的提示信息，基本判定是磁盘空间满了，那么首先从检查服务器的磁盘空间开始，根据报错提示应首先检查/tmp磁盘空间，然后应该是根分区的磁盘空间，最好是系统其它分区的磁盘空间。3、问题排查
通过df命令查看了这个服务器上所有磁盘分区的情况，/tmp分区空间还有很多，根分区也还有很大剩余空间，都不存在问题，最后发现是/var磁盘分区空间使用已经100%了，到这里已经定位了问题，是/var磁盘空间爆

满导致的，因为crontab会在保存时写文件信息到/var目录下，由于这个磁盘没有空间了，报错也是理所当然了。
4、解决问题
接着通过“du-sh”命令检查/var目录下所有文件或目录的大小，发现/var/spool/clientmqueue目录占用了/var整个分区大小的90%，那么/var/spool/clientmqueue目录下的文件都是怎么产生



LinuxNote
180
的呢，是否能删除？下面简单介绍下/var/spool/clientmqueue目录的文件是怎么生成的。可以打开/var/spool/clientmqueue目录下的一些文件看看，都是一些邮件信息，邮件内容大多是关于CronDaemon的，其实/var/spool/clientmqueue就是一个邮件暂存的目录，linux服务器在默认情况下会发一些邮件，比如当cron执行的程序有输出内容时，就会发送邮件信息到执行cron进程的用户，系统在发送邮件时，首先会把邮件拷贝到/var/spool/clientmqueue目录下，然后等待MTA程序(mailtransferagent)来处理，而MTA主要的功能是把这个目录中的邮件转移到/var/spool/mqueue目录下，然后再通过sendmail服务发送到真正的目的地。于是检查了这个服务器的sendmail服务，发现没有开启，这样/var/spool/clientmqueue目录非常大的原因就找到了：没有发送邮件的客户端服务，所有邮件就都堆积在这个目录下了。
在确认完这些内容都没用后，切换到/var/spool/clientmqueue目录下，执行rm命令删除所有的文件时，出现了错误：
12[root@localhostclientmqueue]#rm*/bin/rm:argumentlisttoolong此时出现了本文开头我们谈到的问题。
当Linux下试图传递太多参数给一个系统命令时，就会出现”Argumentlisttoolong”错误。这个是Linux系统一直以来都有的限制。查看这个限制可以通过命令“getconfARG_MAX”来实现，如下图所示：
这是Centos6版本的一个最大值，而在Centos5.x中，这个值相对较小，如下图所示：
所以这个问题更多时候是发生在linux低版本中。
知道了产生问题的原因，解决方法就很多了，这里提供四种解决此问题的方法，分别介绍如下：


LinuxNote
181
（1）手动把命令行参数分成较小的部分例如：12rm[a-n]*-rfrm[o-z]*


LinuxNote
184
通过输出可知，NAS的系统盘是/dev/sda，仅划分了/dev/sda1和/dev/sda2两个系统分区，而数据磁盘是经过做RAID5完成的，在系统上的设备标识分别是/dev/sdb1和/dev/sdc1，由于单用户默认没有挂载任何NAS磁盘，这里尝试手动挂载NAS的系统盘，执行如下命令：[root@NASserver~]#mount/dev/sda2/mnt[root@NASserver~]#mount/dev/sda1/opt
这里的/mnt、/opt是随意挂载的目录，也可以挂载到其他空目录下，挂载完成，分别进入这连个目录看看内容有什么，如下图所示：
通过这两个内容的查看，初步判断，/dev/sda2分区应该是Linux的根分区，而/dev/sda1应该是/bo

ot分区。现在分区已经挂载上去了，再次执行df命令看看挂载情况，如下图所示：
到这里为止，发现问题了。/dev/sda2磁盘分区已经没有可用的磁盘空间了，而这个分区刚好是NAS系统的根分区，根分区没有空间了，那么系统启动肯定就出问题了。



LinuxNote
185
下面再把思路转到前面介绍的案例中，由于系统cups服务在启动的时候会写启动日志到根分区，而根分区因为没有空间了，所以也就无法写日志了，由此导致的结果就是cups服务无法启动，这就解释了此案例中NAS系统每次启动到cups服务就停止的原因。四解决问题
由于NAS系统只有根分区和/boot分区，所以系统产生的相关日志都会存储在根分区中，现在根分区满了，首先可以清理的就是/var目录下的系统相关日志文件，通常可以清理的目录有/var/log，执行如下命令查看/var/log日志目录占据磁盘空间大小：[root@NASserver~]#du-sh/var/log50.1G
/var/log
通过命令输出发现/var/log目录占据了根分区仅70%的空间，清理这个目录下的日志文件即可释放大部分根分区空间，清理完毕，重启NAS系统，发现系统cups服务能正常启动了，NAS服务也启动正常了。
已删除空间但是没释放
运维的监控系统发来通知，报告一台服务器空间满了，登陆服务器查看，根分区确实没有空间了，如下图所示：
这里首先说明一下服务器的一些删除策略，由于Linux没有回收站功能，我们的线上服务器所有要删除的文件都会首先移动到系统/tmp目录下，然后定期清除/tmp目录下的数据。这个策略本身没有问题，但是通过检查发现这台服务器的系统分区中并没有单独划分/tmp分区，这样/tmp下的数据其实是占用了根分区的空间。既然找到了问题，那么删除/tmp目录下一些大数据即可，执行如下命令，检查/tmp下最大的三个数据文件，如下图所示：[root@localhost~]#du-s/tmp/*|sort-nr|head-369206016/tmp/access_log36/tmp/hsperfdata_root36/tmp/hsperfdata_mapred


LinuxNote
186
通过命令输出发现在/tmp目录下有个66G大小的文件access_log，这个文件应该是apache产生的访问日志文件，从日志大小来看，应该是很久没有清理apache日志文件了，基本判定是这个文件导致的根空间爆满，在确认此文件可以删除后，执行如下删除操作：[root@localhost~]#rm/tmp/access_log接着查看系统根分区空间是否释放，如下图所示：
从输出可以看到，根分区空间仍然没有释放，这是怎么回事？2、解决思路
一般说来不会出现删除文件后空间不释放的情况，但是也存在例外，比如文件被进程锁定，或者有进程一直在向这个文件写数据等等，要理解这个问题，就需要知道Linux下文件的存储机制和存储结构。
一个文件在

文件系统中的存放分为两个部分：数据部分和指针部分，指针位于文件系统的meta-data中，数据被删除后，这个指针就从meta-data中清除了，而数据部分存储在磁盘中，数据对应的指针从meta-data中清除后，文件数据部分占用的空间就可以被覆盖并写入新的内容，之所以出现删除access_log文件后，空间还没释放，就是因为httpd进程还在一直向这个文件写入内容，导致虽然删除了access_log文件，但文件对应的指针部分由于进程锁定，并未从meta-data中清除，而由于指针并未被删除，那么系统内核就认为文件并未被删除，因此通过df命令查询空间并未释放也就不足为奇了。3、问题排查
既然有了解决问题的思路，那么接下来看看是否有进程一直在向acess.log文件中写数据，这里需要用到Linux下的lsof命令，通过这个命令可以获取一个已经被删除但仍然被应用程序占用的文件列表，命令执行如下图所示：
从输出结果可以看到，/tmp/acess.log文件被进程httpd锁定，而httpd进程还一直向这个文件写



LinuxNote
187
入日志数据，从第七列可知，这个日志文件大小仅70G，而系统根分区总大小才100G，由此可知，这个文件就是导致系统根分区空间耗尽的罪魁祸首，在最后一列的“deleted”状态，说明这个日志文件已经被删除，但由于进程还在一直向此文件写入数据，空间并未释放。4、解决问题



到这里问题就基本排查清楚了，解决这一类问题的方法有很多种，最简单的方法是关闭或者重启httpd进程，当然也可以重启操作系统，不过这并不是最好的方法，对待这种进程不停对文件写日志的操作，要释放文件占用的磁盘空间，最好的方法是在线清空这个文件，可以通过如下命令完成：[root@localhost~]#echo"">/tmp/acess.log
通过这种方法，磁盘空间不但可以马上释放，也可保障进程继续向文件写入日志，这种方法经常用于在线清理Apache、Tomcat、Nginx等Web服务产生的日志文件。
网站访问速度慢
开启慢查询日志
进数据库showfullprocesslist分析发现大量查询语句在等待执行。。。。解决方法：
先判断有没有索引，并且在流量低的时候创建索引，优化查询
MySQL数据库负载高
问题：Load值达到20-30用户登录后再查询
一般是爬虫分析web日志封掉pv大的ip配置读写分离
加mencache缓存服务器
Fstab修改错误导致系统无法启动修复
Mount–o–rw,remount再修改/etc/fstab

LinuxNote
188
隐藏文件夹方法
隐藏文件简单一法：attrib+s+a+h+rD:/aaa
如此即可将该D盘下的aaa文件隐藏，此时访问需要记得该文件的绝对路径方可如需取消：
attrib-s-a-h-rD:/aaa
linux的过程中，难免会误删除一些文件
/11925

94/342540
服务器阻止SSH暴力破解最有效的方法
/1192594/406202
Linux远程开机
/1192594/319348
用SHELL脚本精准清除Squid缓存
此脚本是在张宴的缓存清理脚本上做了修改的，主要是增加if选项，并根据$1参数类型来选择性的列出缓存文件所在地址（因为$1并不固定，有时是特定的jpg类型，有时是域名）目前在自己的Squid缓存服务器上应用，感觉采集缓存网址基本上没什么误差了，欢迎大家试用，争取将此脚本做到更加完美（此脚本在Centos5.4x86_64，Squid2.7下通过）脚本内容如下：#!/bin/sh
squidcache_path="/usr/local/squid/var/cache"squidclient_path="/usr/local/squid/bin/squidclient"
if[["$1"=~swf|png|jpg|ico|gif|css|js|htm|html|shtml]];then
grep-a-r.$1$squidcache_path/*|strings|grep"http:"|awk-F'http:''{print"http:"$2;}'|awk-F\''{print$1}'>cache.txtelse




LinuxNote
189
grep-a-r$1$squidcache_path/*|strings|grep"http:"|awk-F'http:''{print"http:"$2;}'|awk-F\''{print$1}'>cache.txtfi
whilereadLINEdo
$squidclient_path-h122.70.148.51-p80-mPURGE$LINEdone作业
注释以下文件：
-rw-r--r--.1rootroot234412月921:07httpd-default.conf#了解-rw-r--r--.1rootroot378912月921:07httpd-mpm.conf#重点-rw-r--r--.1rootroot150712月921:07httpd-vhosts.conf#重点尝试搭建tomcat和resin条件语句1：
Awk‘BEGIN{FS=”:”;}$7~“nologin”{print$1}’/etc/passwd等价于：BEGIN{FS=”:”}{
If($0!~/nologin/){print$1}}
awk'{x++}END{printx}'/etc/services
*************分割线******************