查看3306端口被什么程序占用 [[email protected] ~]# lsof -i :3306 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME mysqld 6153 mysql 10u IPv4 13751 TCP *:mysql (LISTEN) mysqld 6153 mysql 111u IPv4 13816917 TCP 10.1.1.13:mysql->apache2:4832 (ESTABLISHED) mysqld 6153 mysql 161u IPv4 13816822 TCP 10.1.1.13:mysql->apache2:4620 (ESTABLISHED) mysqld 6153 mysql 228u IPv4 13817771 TCP 10.1.1.13:mysq 查看3306端口是被哪个服务使用着 [[email protected] ~]# netstat -tunlp | grep :3306 tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 6153/mysqld [[email protected] ~]# 查看3306端口的是否已在使用中,可验证使用该端口的服务是否已正常运行 [[email protected] ~]# netstat -an | grep :3306 tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN tcp 0 0 10.1.1.13:3306 10.1.1.7:9486 TIME_WAIT tcp 0 0 10.1.1.13:3306 10.1.1.7:8459 TIME_WAIT tcp 0 0 10.1.1.13:3306 10.1.1.7:9510 TIME_WAIT tcp 0 0 10.1.1.13:3306 10.1.1.7:7968 TIME_WAIT tcp 0 0 10.1.1.13:3306 10.1.1.7:8773 TIME_WAIT tcp 0 0 10.1.1.13:3306 10.1.1.7:10817 TIME_WAIT tcp 0 293 10.1.1.13:3306 10.1.1.7:11103 ESTABLISHED tcp 0 0 10.1.1.13:3306 10.1.1.7:9561 TIME_WAIT tcp 0 52 10.1.1.13:3306 10.1.1.7:11104 ESTABLISHED tcp 0 0 10.1.1.13:3306 10.1.1.7:9568 TIME_WAIT
系统连接状态篇: 1.查看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 2.查找请求数请20个IP(常用于查找攻来源): netstat -anlp|grep 80|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 3.用tcpdump嗅探80端口的访问看看谁最高 tcpdump -i eth0 -tnn dst port 80 -c 1000 | awk -F"." ‘{print $1″."$2″."$3″."$4}‘ | sort | uniq -c | sort -nr |head -20 4.查找较多time_wait连接 netstat -n|grep TIME_WAIT|awk ‘{print $5}‘|sort|uniq -c|sort -rn|head -n20 5.找查较多的SYN连接 netstat -an | grep SYN | awk ‘{print $5}‘ | awk -F: ‘{print $1}‘ | sort | uniq -c | sort -nr | more 6.根据端口列进程 netstat -ntlp | grep 80 | awk ‘{print $7}‘ | cut -d/ -f1 网站日志分析篇1(Apache): 1.获得访问前10位的ip地址 cat access.log|awk ‘{print $1}‘|sort|uniq -c|sort -nr|head -10 cat access.log|awk ‘{counts[$(11)]+=1}; END {for(url in counts) print counts[url], url}‘ 2.访问次数最多的文件或页面,取前20 cat access.log|awk ‘{print $11}‘|sort|uniq -c|sort -nr|head -20 3.列出传输最大的几个exe文件(分析下载站的时候常用) cat access.log |awk ‘($7~/\.exe/){print $10 " " $1 " " $4 " " $7}‘|sort -nr|head -20 4.列出输出大于200000byte(约200kb)的exe文件以及对应文件发生次数 cat access.log |awk ‘($10 > 200000 && $7~/\.exe/){print $7}‘|sort -n|uniq -c|sort -nr|head -100 5.如果日志最后一列记录的是页面文件传输时间,则有列出到客户端最耗时的页面 cat access.log |awk ‘($7~/\.php/){print $NF " " $1 " " $4 " " $7}‘|sort -nr|head -100 6.列出最最耗时的页面(超过60秒的)的以及对应页面发生次数 cat access.log |awk ‘($NF > 60 && $7~/\.php/){print $7}‘|sort -n|uniq -c|sort -nr|head -100 7.列出传输时间超过 30 秒的文件 cat access.log |awk ‘($NF > 30){print $7}‘|sort -n|uniq -c|sort -nr|head -20 8.统计网站流量(G) cat access.log |awk ‘{sum+=$10} END {print sum/1024/1024/1024}‘ 9.统计404的连接 awk ‘($9 ~/404/)‘ access.log | awk ‘{print $9,$7}‘ | sort 10. 统计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 10.蜘蛛分析查看是哪些蜘蛛在抓取内容。 /usr/sbin/tcpdump -i eth0 -l -s 0 -w - dst port 80 | 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 数据库篇 1.查看数据库执行的sql /usr/sbin/tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings | egrep -i ‘SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER|CALL‘ 系统Debug分析篇 1.调试命令 strace -p pid 2.跟踪指定进程的PID gdb -p pid
/root/mysql_backup.sh # everyday 3:00 AM execute database backup 3 0 * * * /root/mysql_backup.sh 以下是自动自动备份shell,只保留最新5天 #!/bin/sh # mysql_backup.sh: backup mysql databases and keep newest 5 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 0 # 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 -9 > "$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 4 3 2 1 0 do if(test -d "$backup_dir"/backup."$int") then next_int=`expr $int + 1` $MV "$backup_dir"/backup."$int" "$backup_dir"/backup."$next_int" fi done exit 0;
MYSQL配制 一个变更即使重启了MySQL也没起作用?请确定你使用了正确的配置文件。请确定你把配置放在了正确的区域内(所有这篇文章提到的配置都属于 [mysqld]) 服务器在改动一个配置后启不来了:请确定你使用了正确的单位。例如,innodb_buffer_pool_size的单位是MB而max_connection是没有单位的。 不要在一个配置文件里出现重复的配置项。如果你想追踪改动,请使用版本控制。 不要用天真的计算方法,例如”现在我的服务器的内存是之前的2倍,所以我得把所有数值都改成之前的2倍“。 基本配置 你需要经常察看以下3个配置项。不然,可能很快就会出问题。 innodb_buffer_pool_size:这是你安装完InnoDB后第一个应该设置的选项。缓冲池是数据和索引缓存的地方:这个值越大越好,这能保证你在大多数的读取操作时使用的是内存而不是硬盘。典型的值是5-6GB(8GB内存),20-25GB(32GB内存),100-120GB(128GB内存)。 innodb_log_file_size:这是redo日志的大小。redo日志被用于确保写操作快速而可靠并且在崩溃时恢复。一直到MySQL 5.1,它都难于调整,因为一方面你想让它更大来提高性能,另一方面你想让它更小来使得崩溃后更快恢复。幸运的是从MySQL 5.5之后,崩溃恢复的性能的到了很大提升,这样你就可以同时拥有较高的写入性能和崩溃恢复性能了。一直到MySQL 5.5,redo日志的总尺寸被限定在4GB(默认可以有2个log文件)。这在MySQL 5.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.5版本开始,InnoDB就是默认的存储引擎并且它比任何其他存储引擎的使用都要多得多。那也是为什么它需要小心配置的原因。 innodb_file_per_table:这项设置告知InnoDB是否需要将所有表的数据和索引存放在共享表空间里(innodb_file_per_table = OFF) 或者为每张表的数据单独放在一个.ibd文件(innodb_file_per_table = ON)。每张表一个文件允许你在drop、truncate或者rebuild表时回收磁盘空间。这对于一些高级特性也是有必要的,比如数据压缩。但是它不会带来任何性能收益。你不想让每张表一个文件的主要场景是:有非常多的表(比如10k+)。MySQL 5.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 = 0(现在MySQL 5.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/1234 中包含的是PID 为1234 的进程的信息。每个进程目录中存在着各种文件,它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他系统信息。lsof 程序使用该信息和其他关于内核内部状态的信息来产生其输出。所以lsof 可以显示进程的文件描述符和相关的文件名等信息。也就是我们通过访问进程的文件描述符可以找到该文件的相关信息。 当系统中的某个文件被意外地删除了,只要这个时候系统中还有进程正在访问该文件,那么我们就可以通过lsof从/proc目录下恢复该文件的内容。 假如由于误操作将/var/log/messages文件删除掉了,那么这时要将/var/log/messages文件恢复的方法如下: 首先使用lsof来查看当前是否有进程打开/var/logmessages文件,如下: [[email protected] yum.repos.d]# lsof | grep /var/log/messages syslogd 2699 root 1w REG 8,2 480817 330592 /var/log/messages (deleted) 从上面的信息可以看到PID 2699(syslogd)打开文件的文件描述符为 1。同时还可以看到/var/log/messages已经标记被删除了。因此我们可以在/proc/2699/fd/1 (fd下的每个以数字命名的文件表示进程对应的文件描述符)中查看相应的信息,如下: [[email protected] fd]# pwd /proc/2699/fd [[email protected] fd]# cat 1 | head -n 5 Jan 13 08:59:02 station90 syslogd 1.4.1: restart. Jan 13 10:44:22 station90 syslogd 1.4.1: restart. Jan 13 10:44:22 station90 kernel: klogd 1.4.1, log source = /proc/kmsg started. Jan 13 10:44:22 station90 kernel: Linux version 2.6.18-164.el5 ([email protected]003.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Tue Aug 18 15:51:48 EDT 2009 Jan 13 10:44:22 station90 kernel: Command line: ro root=LABEL=/ rhgb quiet 从上面的信息可以看出,查看/proc/2699/fd/1 就可以得到所要恢复的数据。如果可以通过文件描述符查看相应的数据,那么就可以使用 I/O 重定向将其复制到文件中,如: cat /proc/2699/fd/1 > /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 -9 16092 这样处理的速度有点慢,直接来个快速干掉所有僵尸进程的命令 ps -A -o stat,ppid,pid,cmd | grep -e ‘^[Zz]‘ | awk ‘{print $2}‘ | xargs kill -9 再查看,僵尸进程没有了!
时间: 2024-10-13 02:26:45