挑战不可能的任务Linux运维故障锦集 211页.pdf-资料库

machen_smiling-10125565-4744300845223938749.pdf-第1页.png

第1页 / 共211页

machen_smiling-10125565-4744300845223938749.pdf-第2页.png

第2页 / 共211页

machen_smiling-10125565-4744300845223938749.pdf-第3页.png

第3页 / 共211页

machen_smiling-10125565-4744300845223938749.pdf-第4页.png

第4页 / 共211页

machen_smiling-10125565-4744300845223938749.pdf-第5页.png

第5页 / 共211页

machen_smiling-10125565-4744300845223938749.pdf-第6页.png

第6页 / 共211页

machen_smiling-10125565-4744300845223938749.pdf-第7页.png

第7页 / 共211页

machen_smiling-10125565-4744300845223938749.pdf-第8页.png

第8页 / 共211页

资源由 www.eimhe.com 美河学习在线收集分享网卡 IO 超载 ........................................................................................ 3 Centos 出现丢包问题解决办法 ip_conntrack ............................. 7 关于 DEL 网卡驱动的一次故障 ...................................................... 11 一个由于时间问题引发的血案 ....................................................... 18 ead from remote host X.X.X.X: Connection reset by peer 解决办法 ................................................................................................. 20 php-cgi 占用 cpu100%的一次排障之旅 .................................... 21 警惕 raid 卡拖慢你服务器的读写性能 ......................................... 25 yum 停留在 Running Transaction Test 不动的解决办法 ...... 26 都是 php_admin_value open_basedir 惹的祸 ........................ 27 记录一次攻击事件(redis 未授权漏洞利用直接登录服务器)v . 29 经验之谈：nginx php 502 bad gateway 解决方法 ............... 43 如何防止 Linux 命令行下 MySQL 登录密码泄露？ ............ 46 命令行登录防止 MySQL 密码泄露的几个小妙招。 ....... 46 如何利用命令进行实现对文件的授予额外的访问权限 .............. 50 NGINX 反向代理导致大文件下载失败 ......................................... 53 记一次流量异常处理 ........................................................................ 55 LINUX 运维实战案例之文件已删除但空间不释放问题的分析与解决办法 ............................................................................................. 64 CentOS6.4 系统启动失败故障排查 An error occurred during the file sytem check ................................................................... 103 记一次错误卸载软件包导致 Linux 系统崩溃的修复解决过程

资源由 www.eimhe.com 美河学习在线收集分享 ........................................................................................................... 114 1. Kernel panic - not syncing: Attempted to kill init! 115 2. 系统启动加载条完成后，一直 hang 住不动 ................ 116 2.1 将系统 DVD 安装镜像加载到光驱 .......................... 116 2.2 安装缺失的软件包 ...................................................... 117 3. An error occurred during the file system check .... 120 /etc/fstab 文件出错,无法进入 Linux 系统 ............................... 123 Centos6.6 系统 fstab 故障及 root 用户密码恢复案例 ......... 125 Linux 之在 CentOS 上一次艰难的木马查杀过程 .................... 139 阿里云 CentOS 木马查杀--/lib/udev/udev ........................... 175 一、背景 .................................................................................... 175 二、排查 .................................................................................... 176 三、重启 .................................................................................... 178 1、chkconfig --list .......................................................... 179 2、vi /etc/rc.local ............................................................ 179 四、定位 .................................................................................... 179 1、/etc/crontab ............................................................... 179 2、/etc/cron.hourly/cron.sh ........................................ 180 3、/etc/cron.hourly/kill.sh ........................................... 180 五、解决 .................................................................................... 181 六、回头再想想 ........................................................................ 182

资源由 www.eimhe.com 美河学习在线收集分享网卡 IO 超载案例描述：服务器 A 和 B 同是属于一个 VIP 的 Real Server，C、D、E、F、 G 等数十台服务器和 A、B 同属于一个 IDC，同一个网段。 A、B 提供后端存储服务，C、D、E、F、G 等做 web 前端环境：硬件： A、B 配置相同，其后分别外接一套存储 C、D、E、F、G 等配置也一样 OS: CentOS 4.3 32bit 网络环境： A、B、C、D 的内网同属于一个交换机 E、F、G 等的内网同属于一个交换机但 A、B、C、D、E、F、G 的内网都同属于一个网段现象描述： 1：在从 A 服务器上同步文件时发现在 C、D、E、F、G 等机器上的下载速度是不同的，有些机器可以达到几十 Mb，有些只有几十 Kb，同一网段的而且还都是走的内网，这差别也太大了。 2：从 C、D、E、F、G 测试发现到 A 服务器的延时很大大约在 10ms 左右，而到 B 服务则是正常的，在 0.2-0.4ms 左右。

资源由 www.eimhe.com 美河学习在线收集分享 3：初步检查 A 和 B 的负载以及 IO 以及连接数，均为发现异常。 4：C、E、F、G 等的负载和 IO 也未发现异常。问题： 1：导致到 A 延时较大以及下载速度差别较大的原因到底是什么呢？ 2：如何去进一步查找分析原因、并解决问题？ 3：如果您遇到这样的问题，改从何着手分析呢？欢迎大家发表自己的分析思路，此案例的答案稍后公布。。。。。 ----------------------------- update @ 2010-04-06 ---------------------------------- 答案已经公布请大家翻看帖子查找吧. 附：故障时内网网卡流量分析，看看能否看出什么问题么？

资源由 www.eimhe.com 美河学习在线收集分享

资源由 www.eimhe.com 美河学习在线收集分享 -------------------------------update @ 2010-04-07 ----------------------------------- 再次更新下当时的分析处理过程... 下面是我们起初分析处理的过程： 1: 检查这几台服务器所属的交换机，是否有限制？是否交换机过载？经检查交换机未发现异常，所涉及到的端口都没有错误包记录，也没有 Qos 类的限制，只是这几台服务器属于一个 B 段，然后我们就思考是否是服务器上的路由导致的问题，随后检查路由也无异常网络的原因大致排除掉了，只能再次寻找原因。 2：正当我们纳闷的时候发现延时恢复正常了，下载速度也恢复正常了，随后切回服务，很快故障现象有出现了。怀疑是网口问题或是网线问题，随后把更换了 B 和 A 的网口做了调换问题依然，排除了交换机网口出问题的可能。 3：继续排查这次定位到了网线上，随后更换了 A 的内网网线，问题依然。又排除掉了网线的可能。 4：A 网卡没有丢包、没有报错，为何 B 机器没有这样的现象呢，难道.... 随后把 A、B 的内网做了互换，发现 A 恢复正常，其他服务器到 B 的延时开始变大，上述想象再次出现在服务器 B 上。随后检查负载均衡的配置没有发现异常。。。。再次没有了头绪

资源由 www.eimhe.com 美河学习在线收集分享 5：到此为止把其他一切外在的因素都排除了，剩下的只有再次排除 A 本身了。把之前做的变更全部还原，从新切回服务测试。。。。这次我们对 A 和 B 同时做了流量的分析，终于发现了问题。。。。。通过内网的流量分析我们发现此时网卡已经达到了千兆网卡的 IO 峰值，从而形成了网络 IO 瓶颈。从而导致上述现象，只是我们在分析的时候未考虑到网卡的 IO 极限。。。。从而在分析问题的时候走了很多弯路。不知道大家有没有遇到过类似的网卡 IO 达到极限的问题。总结一下： 1：要尽可能多的了解每个产品线的架构、以及其临时的调整。 2：回滚。但一个故障出现时，我们可以先去试着回滚到正常情况，然后再试着去分析问题。 3：要尽可能先从自身寻找原因。包括服务、磁盘、存储、还有网卡 IO。通常的思考很难一下定位到网卡 IO 超载的，这也是个人以为此故障经典的地方，希望和大家一起分享。 Centos 出现丢包问题解决办法 ip_conntrack 环境介绍：

资源由 www.eimhe.com 美河学习在线收集分享系统: CENTOS 5.5 64 bit 软件：nginx+mysql+php+NFS 故障排查：早上突然收到 nagios 服务器 check_icmp 的报警，报警显示一台网站服务器的内网网络有问题。因为那台服务器挂载了内网的 NFS，因此内网的网络就采用 nagios 的 check_icmp 来做监控。赶紧登录服务器进行排查。首先使用 ping 内网 IP 的方式查看内网的连通性，ping 的过程中出现丢包现象，信息如下: 64 bytes from 10.1.1.1: icmp_seq=34 ttl=255 time=0.928 ms 64 bytes from 10.1.1.1: icmp_seq=35 ttl=255 time=1.01 ms ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted 显示 ping 不被允许，奇怪，防火墙上明明开通了 icmp 的协议。有问题先看日志，日志文件一般会有所记录， tail – f /var/log/messages，发现大量的如下内容： Sep 13 09:11:21 dowload_server1 kernel: printk: 261 messages suppressed. Sep 13 09:11:21 dowload_server1 kernel: ip_conntrack: table full, dropping packet 发现是当前会话数已经满了，因此出现丢包现象。这里对

资料库

挑战不可能的任务Linux运维故障锦集 211页.pdf

相关推荐

操作系统

热门标签

最新资料