查看3306端口被什么程序占用
[root@DB13 ~]# lsof -i :
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
mysqld mysql 10u IPv4 TCP *:mysql (LISTEN)
mysqld mysql 111u IPv4 TCP 10.1.1.13:mysql->apache2: (ESTABLISHED)
mysqld mysql 161u IPv4 TCP 10.1.1.13:mysql->apache2: (ESTABLISHED)
mysqld mysql 228u IPv4 TCP 10.1.1.13:mysq
查看3306端口是被哪个服务使用着
[root@DB13 ~]# netstat -tunlp | grep :
tcp 0.0.0.0: 0.0.0.0:* LISTEN /mysqld
[root@DB13 ~]#
查看3306端口的是否已在使用中，可验证使用该端口的服务是否已正常运行
[root@DB13 ~]# netstat -an | grep :
tcp 0.0.0.0: 0.0.0.0:* LISTEN
tcp 10.1.1.13: 10.1.1.7: TIME_WAIT
tcp 10.1.1.13: 10.1.1.7: TIME_WAIT
tcp 10.1.1.13: 10.1.1.7: TIME_WAIT
tcp 10.1.1.13: 10.1.1.7: TIME_WAIT
tcp 10.1.1.13: 10.1.1.7: TIME_WAIT
tcp 10.1.1.13: 10.1.1.7: TIME_WAIT
tcp 10.1.1.13: 10.1.1.7: ESTABLISHED
tcp 10.1.1.13: 10.1.1.7: TIME_WAIT
tcp 10.1.1.13: 10.1.1.7: ESTABLISHED
tcp 10.1.1.13: 10.1.1.7: TIME_WAIT
系统连接状态篇：
.查看TCP连接状态
netstat -nat |awk '{print $6}'|sort|uniq -c|sort -rn
netstat -n | awk '/^tcp/ {++S[$NF]};END {for(a in S) print a, S[a]}' 或
netstat -n | awk '/^tcp/ {++state[$NF]}; END {for(key in state) print key,"\t",state[key]}'
netstat -n | awk '/^tcp/ {++arr[$NF]};END {for(k in arr) print k,"\t",arr[k]}'
netstat -n |awk '/^tcp/ {print $NF}'|sort|uniq -c|sort -rn
netstat -ant | awk '{print $NF}' | grep -v '[a-z]' | sort | uniq -c
.查找请求数请20个IP（常用于查找攻来源）：
netstat -anlp|grep |grep tcp|awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|sort -nr|head -n20
netstat -ant |awk '/:80/{split($5,ip,":");++A[ip[1]]}END{for(i in A) print A[i],i}' |sort -rn|head -n20
.用tcpdump嗅探80端口的访问看看谁最高
tcpdump -i eth0 -tnn dst port -c | awk -F"." '{print $1″."$2″."$3″."$4}' | sort | uniq -c | sort -nr |head -
.查找较多time_wait连接
netstat -n|grep TIME_WAIT|awk '{print $5}'|sort|uniq -c|sort -rn|head -n20
.找查较多的SYN连接
netstat -an | grep SYN | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c | sort -nr | more
.根据端口列进程
netstat -ntlp | grep | awk '{print $7}' | cut -d/ -f1
网站日志分析篇1（Apache）：
.获得访问前10位的ip地址
cat access.log|awk '{print $1}'|sort|uniq -c|sort -nr|head -
cat access.log|awk '{counts[$(11)]+=1}; END {for(url in counts) print counts[url], url}'
.访问次数最多的文件或页面,取前20
cat access.log|awk '{print $11}'|sort|uniq -c|sort -nr|head -
.列出传输最大的几个exe文件（分析下载站的时候常用）
cat access.log |awk '($7~/\.exe/){print $10 " " $1 " " $4 " " $7}'|sort -nr|head -
.列出输出大于200000byte(约200kb)的exe文件以及对应文件发生次数
cat access.log |awk '($10 > 200000 && $7~/\.exe/){print $7}'|sort -n|uniq -c|sort -nr|head -
.如果日志最后一列记录的是页面文件传输时间，则有列出到客户端最耗时的页面
cat access.log |awk '($7~/\.php/){print $NF " " $1 " " $4 " " $7}'|sort -nr|head -
.列出最最耗时的页面(超过60秒的)的以及对应页面发生次数
cat access.log |awk '($NF > 60 && $7~/\.php/){print $7}'|sort -n|uniq -c|sort -nr|head -
.列出传输时间超过 秒的文件
cat access.log |awk '($NF > 30){print $7}'|sort -n|uniq -c|sort -nr|head -
.统计网站流量（G)
cat access.log |awk '{sum+=$10} END {print sum/1024/1024/1024}'
.统计404的连接
awk '($9 ~/404/)' access.log | awk '{print $9,$7}' | sort
. 统计http status.
cat access.log |awk '{counts[$(9)]+=1}; END {for(code in counts) print code, counts[code]}'
cat access.log |awk '{print $9}'|sort|uniq -c|sort -rn
.蜘蛛分析查看是哪些蜘蛛在抓取内容。
/usr/sbin/tcpdump -i eth0 -l -s -w - dst port | strings | grep -i user-agent | grep -i -E 'bot|crawler|slurp|spider'
网站日分析2(Squid篇）
按域统计流量
zcat squid_access.log.tar.gz| awk '{print $10,$7}' |awk 'BEGIN{FS="[ /]"}{trfc[$4]+=$1}END{for(domain in trfc){printf "%s\t%d\n",domain,trfc[domain]}}'
效率更高的perl版本请到此下载:http://docs.linuxtone.org/soft/tools/tr.pl
数据库篇
.查看数据库执行的sql
/usr/sbin/tcpdump -i eth0 -s -l -w - dst port | strings | egrep -i 'SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER|CALL'
系统Debug分析篇 .调试命令
strace -p pid
.跟踪指定进程的PID
gdb -p pid
/root/mysql_backup.sh
# everyday : AM execute database backup
* * * /root/mysql_backup.sh
以下是自动自动备份shell，只保留最新5天
#!/bin/sh
# mysql_backup.sh: backup mysql databases and keep newest days backup.
#
# db_user is mysql username
# db_passwd is mysql password
# db_host is mysql host
# —————————–
db_user="root"
db_passwd="zhoz.com"
db_host="localhost"
# the directory for story your backup file.
backup_dir="/home/zhozdbbackup"
# date format for backup file (dd-mm-yyyy)
time="$(date +"%d-%m-%Y")"
# mysql, mysqldump and some other bin's path
MYSQL="/usr/bin/mysql"
MYSQLDUMP="/usr/bin/mysqldump"
MKDIR="/bin/mkdir"
RM="/bin/rm"
MV="/bin/mv"
GZIP="/bin/gzip"
# check the directory for store backup is writeable
test ! -w $backup_dir && echo "Error: $backup_dir is un-writeable." && exit
# the directory for story the newest backup
test ! -d "$backup_dir/backup.0/" && $MKDIR "$backup_dir/backup.0/"
# get all databases
all_db="$($MYSQL -u $db_user -h $db_host -p$db_passwd -Bse 'show databases')"
for db in $all_db
do
$MYSQLDUMP -u $db_user -h $db_host -p$db_passwd $db | $GZIP - > "$backup_dir/backup.0/$time.$db.gz"
done
# delete the oldest backup
test -d "$backup_dir/backup.5/" && $RM -rf "$backup_dir/backup.5"
# rotate backup directory
for int in
do
if(test -d "$backup_dir"/backup."$int")
then
next_int=`expr $int + `
$MV "$backup_dir"/backup."$int" "$backup_dir"/backup."$next_int"
fi
done
exit ;
MYSQL配制
一个变更即使重启了MySQL也没起作用？请确定你使用了正确的配置文件。请确定你把配置放在了正确的区域内(所有这篇文章提到的配置都属于 [mysqld])
服务器在改动一个配置后启不来了：请确定你使用了正确的单位。例如，innodb_buffer_pool_size的单位是MB而max_connection是没有单位的。
不要在一个配置文件里出现重复的配置项。如果你想追踪改动，请使用版本控制。
不要用天真的计算方法，例如”现在我的服务器的内存是之前的2倍，所以我得把所有数值都改成之前的2倍“。
基本配置
你需要经常察看以下3个配置项。不然，可能很快就会出问题。
innodb_buffer_pool_size:这是你安装完InnoDB后第一个应该设置的选项。缓冲池是数据和索引缓存的地方：这个值越大越好，这能保证你在大多数的读取操作时使用的是内存而不是硬盘。典型的值是5-6GB(8GB内存)，-25GB(32GB内存)，-120GB(128GB内存)。
innodb_log_file_size：这是redo日志的大小。redo日志被用于确保写操作快速而可靠并且在崩溃时恢复。一直到MySQL 5.1，它都难于调整，因为一方面你想让它更大来提高性能，另一方面你想让它更小来使得崩溃后更快恢复。幸运的是从MySQL .5之后，崩溃恢复的性能的到了很大提升，这样你就可以同时拥有较高的写入性能和崩溃恢复性能了。一直到MySQL 5.5，redo日志的总尺寸被限定在4GB(默认可以有2个log文件)。这在MySQL .6里被提高。
一开始就把innodb_log_file_size设置成512M(这样有1GB的redo日志)会使你有充裕的写操作空间。如果你知道你的应用程序需要频繁的写入数据并且你使用的时MySQL 5.6，你可以一开始就把它这是成4G。
max_connections:如果你经常看到‘Too many connections’错误，是因为max_connections的值太低了。这非常常见因为应用程序没有正确的关闭数据库连接，你需要比默认的151连接数更大的值。max_connection值被设高了(例如1000或更高)之后一个主要缺陷是当服务器运行1000个或更高的活动事务时会变的没有响应。在应用程序里使用连接池或者在MySQL里使用进程池有助于解决这一问题。
InnoDB配置
从MySQL .5版本开始，InnoDB就是默认的存储引擎并且它比任何其他存储引擎的使用都要多得多。那也是为什么它需要小心配置的原因。
innodb_file_per_table：这项设置告知InnoDB是否需要将所有表的数据和索引存放在共享表空间里（innodb_file_per_table = OFF） 或者为每张表的数据单独放在一个.ibd文件（innodb_file_per_table = ON）。每张表一个文件允许你在drop、truncate或者rebuild表时回收磁盘空间。这对于一些高级特性也是有必要的，比如数据压缩。但是它不会带来任何性能收益。你不想让每张表一个文件的主要场景是：有非常多的表（比如10k+）。
MySQL .6中，这个属性默认值是ON，因此大部分情况下你什么都不需要做。对于之前的版本你必需在加载数据之前将这个属性设置为ON，因为它只对新创建的表有影响。
innodb_flush_log_at_trx_commit：默认值为1，表示InnoDB完全支持ACID特性。当你的主要关注点是数据安全的时候这个值是最合适的，比如在一个主节点上。但是对于磁盘（读写）速度较慢的系统，它会带来很巨大的开销，因为每次将改变flush到redo日志都需要额外的fsyncs。将它的值设置为2会导致不太可靠（reliable）因为提交的事务仅仅每秒才flush一次到redo日志，但对于一些场景是可以接受的，比如对于主节点的备份节点这个值是可以接受的。如果值为0速度就更快了，但在系统崩溃时可能丢失一些数据：只适用于备份节点。
innodb_flush_method: 这项配置决定了数据和日志写入硬盘的方式。一般来说，如果你有硬件RAID控制器，并且其独立缓存采用write-back机制，并有着电池断电保护，那么应该设置配置为O_DIRECT；否则，大多数情况下应将其设为fdatasync（默认值）。sysbench是一个可以帮助你决定这个选项的好工具。
innodb_log_buffer_size: 这项配置决定了为尚未执行的事务分配的缓存。其默认值（1MB）一般来说已经够用了，但是如果你的事务中包含有二进制大对象或者大文本字段的话，这点缓存很快就会被填满并触发额外的I/O操作。看看Innodb_log_waits状态变量，如果它不是0，增加innodb_log_buffer_size。
其他设置
query_cache_size: query cache（查询缓存）是一个众所周知的瓶颈，甚至在并发并不多的时候也是如此。 最佳选项是将其从一开始就停用，设置query_cache_size = （现在MySQL .6的默认值）并利用其他方法加速查询：优化索引、增加拷贝分散负载或者启用额外的缓存（比如memcache或redis）。如果你已经为你的应用启用了query cache并且还没有发现任何问题，query cache可能对你有用。这是如果你想停用它，那就得小心了。
log_bin：如果你想让数据库服务器充当主节点的备份节点，那么开启二进制日志是必须的。如果这么做了之后，还别忘了设置server_id为一个唯一的值。就算只有一个服务器，如果你想做基于时间点的数据恢复，这（开启二进制日志）也是很有用的：从你最近的备份中恢复（全量备份），并应用二进制日志中的修改（增量备份）。二进制日志一旦创建就将永久保存。所以如果你不想让磁盘空间耗尽，你可以用 PURGE BINARY LOGS 来清除旧文件，或者设置 expire_logs_days 来指定过多少天日志将被自动清除。
记录二进制日志不是没有开销的，所以如果你在一个非主节点的复制节点上不需要它的话，那么建议关闭这个选项。
skip_name_resolve：当客户端连接数据库服务器时，服务器会进行主机名解析，并且当DNS很慢时，建立连接也会很慢。因此建议在启动服务器时关闭skip_name_resolve选项而不进行DNS查找。唯一的局限是之后GRANT语句中只能使用IP地址了，因此在添加这项设置到一个已有系统中必须格外小心。
linux/uninx恢复删除的文件
当Linux计算机受到入侵时，常见的情况是日志文件被删除，以掩盖攻击者的踪迹。管理错误也可能导致意外删除重要的文件，比如在清理旧日志时，意外地删除了数据库的活动事务日志。有时可以通过lsof来恢复这些文件。
当进程打开了某个文件时，只要该进程保持,打开该文件，即使将其删除，它依然存在于磁盘中。这意味着，进程并不知道文件已经被删除，它仍然可以向打开该文件时提供给它的文件描述符进行读取和写入。除了该进程之外，这个文件是不可见的，因为已经删除了其相应的目录索引节点。
在/proc 目录下，其中包含了反映内核和进程树的各种文件。/proc目录挂载的是在内存中所映射的一块区域，所以这些文件和目录并不存在于磁盘中，因此当我们对这些文件进行读取和写入时，实际上是在从内存中获取相关信息。大多数与lsof 相关的信息都存储于以进程的PID 命名的目录中，即/proc/ 中包含的是PID 为1234 的进程的信息。每个进程目录中存在着各种文件，它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他系统信息。lsof 程序使用该信息和其他关于内核内部状态的信息来产生其输出。所以lsof 可以显示进程的文件描述符和相关的文件名等信息。也就是我们通过访问进程的文件描述符可以找到该文件的相关信息。
当系统中的某个文件被意外地删除了，只要这个时候系统中还有进程正在访问该文件，那么我们就可以通过lsof从/proc目录下恢复该文件的内容。 假如由于误操作将/var/log/messages文件删除掉了，那么这时要将/var/log/messages文件恢复的方法如下：
首先使用lsof来查看当前是否有进程打开/var/logmessages文件，如下：
[root@station90 yum.repos.d]# lsof | grep /var/log/messages
syslogd root 1w REG , /var/log/messages (deleted)
从上面的信息可以看到PID （syslogd）打开文件的文件描述符为 。同时还可以看到/var/log/messages已经标记被删除了。因此我们可以在/proc//fd/ （fd下的每个以数字命名的文件表示进程对应的文件描述符）中查看相应的信息，如下：
[root@station90 fd]# pwd
/proc//fd
[root@station90 fd]# cat | head -n
Jan :: station90 syslogd 1.4.: restart.
Jan :: station90 syslogd 1.4.: restart.
Jan :: station90 kernel: klogd 1.4., log source = /proc/kmsg started.
Jan :: station90 kernel: Linux version 2.6.-.el5 (mockbuild@x86-.build.bos.redhat.com) (gcc version 4.1. (Red Hat 4.1.-)) # SMP Tue Aug :: EDT
Jan :: station90 kernel: Command line: ro root=LABEL=/ rhgb quiet
从上面的信息可以看出，查看/proc//fd/ 就可以得到所要恢复的数据。如果可以通过文件描述符查看相应的数据，那么就可以使用 I/O 重定向将其复制到文件中，如:
cat /proc//fd/ > /var/log/messages
在恢复之前，及时touch了/var/log/messages文件也是没有问题的
对于许多应用程序，尤其是日志文件和数据库，这种恢复删除文件的方法非常有用。
查看并杀死僵尸进程
昨天服务器到期，之前的服务器由于空间小，不能满足现在的服务要求，就新购买了一个服务器，目前正在调试安装中！
在调试过程中，发现系统中有很多僵尸进程，现在就是找出这些僵尸进程，并将其杀死。
用top查看系统中的僵尸进程情况
查看僵尸进程
再看看这些僵尸是什么程序来的
ps -A -o stat,ppid,pid,cmd | grep -e '^[Zz]'
因为状态为 z或者Z 的进程为僵尸进程，所以我们使用grep抓取stat状态为zZ进程
运行结果参考如下
查看僵尸进程是什么
这里一共出现了6个僵死进程，我们需要把它们一个个都干掉，执行下面的命令
kill -
这样处理的速度有点慢，直接来个快速干掉所有僵尸进程的命令
ps -A -o stat,ppid,pid,cmd | grep -e '^[Zz]' | awk '{print $2}' | xargs kill -
再查看，僵尸进程没有了！
