下列贴士帮助你更快速更轻松地为Linux中的硬件排查故障。许多不同的因素可能导致Linux硬件出现问题；在你开始尝试诊断之前，了解最常见的问题以及最有可能找到原因的环节是明智之举。
Linux 服务器 在许多不同类型的基础架构中运行关键任务型业务应用程序，包括物理机、虚拟机、私有云、公共云和混合云。对于Linux系统管理员来说，了解如何管理Linux硬件基础架构很重要，包括与网络和存储有关的软件定义功能、Linux容器和Linux服务器上的多个工具。
排查并解决Linux上与硬件有关的问题可能需要一些时间。连经验丰富的系统管理员有时也要花几小时来解决莫名其妙的软硬件问题。
下列贴士帮助你更快速更轻松地为Linux中的硬件排查故障。许多不同的因素可能导致Linux硬件出现问题;在你开始尝试诊断之前，了解最常见的问题以及最有可能找到原因的环节是明智之举。
1.快速诊断设备、模块和驱动程序
故障排查的第一步通常是显示Linux服务器上安装的硬件列表。你可以使用ls命令获取硬件的详细信息，比如lspci、lsblk、lscpu和lsscsi。比如说，这是lsblk命令的输出结果：
NAMEMAJ:MINRMSIZEROTYPEMOUNTPOINTxvda202:0050G0disk├─xvda1202:101M0part└─xvda2202:2050G0part/xvdb202:16020G0disk└─xvdb1202:17020G0part如果ls命令没有显示任何错误，使用初始化进程(比如systemd)查看Linux服务器的运行状况。systemd是启动用户空间、控制多个系统进程的最流行的初始化进程。比如说，这是systemctl status命令的输出结果：
●bastion.f347.internalState:runningJobs:0queuedFailed:0unitsSince:Wed2018-11-2801:29:05UTC;2daysagoCGroup:/├─1/usr/lib/systemd/systemd--Switched-root--system--deserialize21├─kubepods.slice│├─kubepods-pod3881728a_f2af_11e8_af77_06af52f87498.slice││├─docker-88b27385f4bae77bba834fbd60a61d19026bae13d18eb147783ae27819c34967.scope│││└─23860/opt/bridge/bin/bridge--public-dir=/opt/bridge/static--config=/var/console-config/console-c││└─docker-a4433f0d523c7e5bc772ee4db1861e4fa56c4e63a2d48f6bc831458c2ce9fd2d.scope││└─23639/usr/bin/poddmesg让你可以搞清楚内核的最新信息中的错误和警示内容。比如说，这是dmesg | more命令的输出结果：
....[1539.027419]IPv6:ADDRCONF(NETDEV_UP):eth0:linkisnotready[1539.042726]IPv6:ADDRCONF(NETDEV_UP):veth61f37018:linkisnotready[1539.048706]IPv6:ADDRCONF(NETDEV_CHANGE):veth61f37018:linkbecomesready[1539.055034]IPv6:ADDRCONF(NETDEV_CHANGE):eth0:linkbecomesready[1539.098550]deviceveth61f37018enteredpromiscuousmode[1541.450207]deviceveth61f37018leftpromiscuousmode[1542.493266]SELinux:mountinvalid.Samesuperblock,differentsecuritysettings(devmqueue,mqueue)[9965.292788]SELinux:mountinvalid.Samesuperblock,differentsecuritysettings(devmqueue,mqueue)[9965.449401]IPv6:ADDRCONF(NETDEV_UP):eth0:linkisnotready[9965.462738]IPv6:ADDRCONF(NETDEV_UP):vetheacc333c:linkisnotready[9965.468942]IPv6:ADDRCONF(NETDEV_CHANGE):vetheacc333c:linkbecomesready....你还可以查看/var/log/messages文件中的所有Linux系统日志，在这里找到与特定问题有关的错误。如果你对硬件进行改动，比如挂载额外磁盘或添加以太网网卡，有必要通过tail命令实时密切关注信息。比如说，这是tail -f /var/log/messages命令的输出结果：
Dec113:20:33bastiondnsmasq[30201]:usingnameserver127.0.0.1Dec113:20:33bastiondnsmasq[30201]:usingnameserver127.0.0.1Dec113:21:03bastiondnsmasq[30201]:settingupstreamserversfromDBusDec113:21:03bastiondnsmasq[30201]:usingnameserver192.199.0.2Dec113:21:03bastiondnsmasq[30201]:usingnameserver127.0.0.1Dec113:21:03bastiondnsmasq[30201]:usingnameserver127.0.0.1Dec113:21:33bastiondnsmasq[30201]:settingupstreamserversfromDBusDec113:21:33bastiondnsmasq[30201]:usingnameserver192.199.0.2Dec113:21:33bastiondnsmasq[30201]:usingnameserver127.0.0.1Dec113:21:33bastiondnsmasq[30201]:usingnameserver127.0.0.1你可能在复杂的网络环境中有成千上万个云原生应用程序为业务服务提供服务;这些可能包括虚拟化、多云和混合云。这意味着你应该分析网络连接是否正常运行，这是故障排查的一部分。分析Linux服务器中网络功能的实用命令包括ip addr、traceroute、nslookup、dig和ping等。比如说，这是ip addr show命令的输出结果：
1:lo:mtu65536qdiscnoqueuestateUNKNOWNgroupdefaultqlen1000 link/loopback00:00:00:00:00:00brd00:00:00:00:00:00 inet127.0.0.1/8scopehostlo valid_lftforeverpreferred_lftforever inet6::1/128scopehost valid_lftforeverpreferred_lftforever 2: eth0:mtu9001qdiscmqstateUPgroupdefaultqlen1000 link/ether06:af:52:f8:74:98brdff:ff:ff:ff:ff:ff inet192.199.0.169/24brd192.199.0.255scopeglobalnoprefixroutedynamiceth0 valid_lft3096secpreferred_lft3096sec inet6fe80::4af:52ff:fef8:7498/64scopelink valid_lftforeverpreferred_lftforever 3: docker0:mtu1500qdiscnoqueuestateDOWNgroupdefault link/ether02:42:67:fb:1a:a2brdff:ff:ff:ff:ff:ff inet172.17.0.1/16scopeglobaldocker0 valid_lftforeverpreferred_lftforever inet6fe80::42:67ff:fefb:1aa2/64scopelink valid_lftforeverpreferred_lftforever ....Linux硬件故障排查需要具备相当扎实的知识，包括如何使用功能强大的命令行工具、解读系统日志。你还应该知道如何诊断内核空间，可以在内核空间找到许多硬件问题的根本原因。请记住，Linux中的硬件问题可能由许多不同的方面引起，包括设备、模块、驱动程序、BIOS、网络，甚至是旧硬件故障。
linux 怎么读取cpu功耗
获取CPU使用率1实时CPU使用率 类似任务管理器实时系统信息可以通过top命令查看。 显示的信息四个参数分别是：用户的模式（user）、低优先级的用户模式（nice）、系统内核模式（system）以及系统空闲的处理器时间（idle）2查看CPU处理器使用率对于CPU使用率一般都是通过CPU使用情况，查看/proc/stat cpu状态文件3平均CPU使用率对于一般某时间段CPU的使用率来说，可以通过查看/pRoc/loadavg 文件信息4第三方监控软件查看网上有很多网管，监控软件安装配置好之后。 可以通过网页管理查看CPU等硬件情况和CPU使用率，负载等参数END其它相关信息内存使用率 查看 /proc/meminfo查看内存详细信息，也可以通过free 命令查看网络利用率 通过查看文件/proc/net/dev 可以了解，centos系统的网络使用情况跟windows的网络情况类似
如何查找Linux死机原因
Linux 内核虽然号称“不死族”，几乎不会崩溃或者死机，但是特殊情况下，还是有一定几率会宕机的。 因为 Linux 广泛用于生产环境，所以每一次宕机都会引起相当大的损失。 它 Uptime 达到上百天也许你习以为常，但是只要 Down 十几秒，就会立即急的满头大汗。 真的很难以想象证交所宕机会怎么样，也许全国股民会闹翻天。 所以我们需要一些小技巧来查找死机的原因，从而避免死机或者内核崩溃。 （话说 windows 天天蓝屏也没感觉呀 ：-o 难道已经麻木了 ：oops： ） 请注意：以下方法可能不适用于 Server，因为桌面环境和 Server 还是有很大区别的。 X Crash 事实上 Linux 内核很少出错，平常我们所遇到的“死机”都是 X 无响应造成的错觉。 那 X 没响应了应该怎么处理呢？ 通常套路是 Ctrl + Alt +F7 （F8） 切换到某个 tty，然后用 root 登陆，执行 top 查看吃资源最多的程序，然后使用 pkill/kill/killall 等命令杀死该程序。 或使用组合键 Ctrl + Alt + Backspace重启 X （黑日白月注：这个快捷键组合在最新的 Ubuntu 和 Fedora 中关闭）。 如果偶遇切换 tty 失败或者没响应，可以试着使用 SSH 登陆此电脑，然后再杀死程序。 也许只是 X 不响应，而内核和 SSH daemon 仍然工作，故此可以实施此法。 arch 配置 SSH daemon 万一X 不给力，各种方法试了无效，又没有办法通过 SSH 登陆到此 pc，那怎么办呢？别着急，我们还有万能的 “reisub” 大法。 不过在启用前先要激活内核 sysrq 功能 （via） 。 系统启动时执行：echo “1” > /proc/sys/Kernel/sysrq 或者修改 /etc/ 文件，设置 = 1。 系统异常时依次按下 Alt+sysrq+{reisub} ，然后系统会自动重启。 （有关 sysrq 请看：Linux 死机了怎么办？） 不建议长按 Power 按键强制关机，有可能损坏硬件或者丢失数据，甚至导致磁盘坏道！ X 崩溃而内核完好 常见的症状有：程序无响应，花屏，鼠标移动指针无动作，键盘输入没有识别等。 但后台的音乐可以正常播放，或者键盘 Caps Lock/Num Lock/Scroll Lock 按键按后对应 LED 可以正常亮灭。 遇到此种情况可以使用上述方法重启 X 或者电脑即可恢复正常。 Application Crash 这个比较常见，但是也是相当难解决的。 因为 Linux 上的应用软件大部分都是开源的，所以可能没有超高的稳定性。 也许由于库的缺少或者版本错误，或者代码的 Bug，都有可能导致程序出现异常。 一般遇到这种问题，建议检查配置文件是否正确，对配置文件的错误修改可能导致程序的运行失败。 如果您确信配置文件没有错误但是程序仍然异常，可以尝试把配置文件删除（注意备份！），然后再次打开软件尝试。 通常程序的配置文件在： ● ~/.[APPNAME]● /etc/[APPNAME] 或者有可能是库的错误，您可以在终端输入程序名或者程序路径运行程序，根据终端的提示信息除错。 由于导致程序崩溃的可能性多种多样，在此不能一一列举，所以建议您根据出错信息去 google 搜索并找到解决方案。 Kernel Panic X 的问题还好办，可是如果 RPWT 碰到 Kernel Panic，那可真是上天无路入地无门，撞墙的心都有 ：evil： 。 一般引起 Kernel Panic 的原因很多，但是都比较罕见。 例如硬件问题 （irq confilct， bad block， high temperature），软件问题（错误的 mod，内核的 Bug），或者文件系统不支持（没有内建 ext4 支持却挂载 ext4 的 root 分区），硬件的变动（如添加/更换内存，不支持架构的cpu），错误的驱动。 Kernel Panic 的表现形式也是多种多样：启动失败，不正常的长时间 io 操作，键盘灯的不正常频闪，wireless 等指示灯错误闪烁，无响应（请区别 xorg crash 情况），彻底锁死，黑屏，reisub 大法不灵 等等。 21/212>
linux下磁盘占用达到100%了，找不到哪些大文件耗尽了磁盘。
楼上的各位，麻烦你们回答问题的时候看清楚别人问的是什么好吧？1、如果是大文件占用了，那么查询大于某个值的文件的方法：find / -size +100c -print这是从根盘开始查找大于100字节的文件（至于字节数你当然可以自己设置）你可以用find / -size +100c -exec ls -l {}\;来列出文件属性。 2、如果只是因为有些应用生成的日志文件较多，长时间没有清理后占用了，这种情况最明显的标志为系统空间使用量逐步递增，每天的增量基本相差不大。 那么最快捷的方式莫过于询问应用厂商要到日志存放目录后进行清理。 如果找不到厂商，那只好自己动手咯，写个脚本查：#!/bin/ksh#####用du命令输出所有目录所占的磁盘空间大小，以G为单位#########du -h >fs_######判断各层目录大小，查到占用量大的目录######cat fs_|while read LINE FS_USEDdoif[ $LINE -ge 10 ]then echo $FS_USED >>####查看运行结果#######more 这样你就能看到占用量比较大的目录，从而有针对性的到相应目录下检查，看到底是什么东西在占用硬盘空间了。 （if[ $LINE -ge 10 ] ，这里是判断超过10G的目录，你可以修改）3、因为人为的误操作，导致了某些进程在没有执行完成的时候被kill掉了，但是缓存中的程序没有释放，仍然在运行，这会产生一些临时文件占用大量的磁盘空间资源，这种现象的特点是爆发式的增长，在很短时间内就将磁盘空间占满。 解决的方法：i、如果是因为父进程被杀除，子进程还运行导致，那么最简单，kill子进程，就会释放。 ii、如果能用ipcs确认是哪个用户的进程，那么也不困难，顺着使用ipcrm就行（这个就不一一例举了，有了命令查使用方法还是很方便的）iii、执行进程的用户是比较关键的用户如：root用户、有实例的oracle用户、在线的生产用户等。 那么建议在确认是因为共享缓存的原因导致的问题后重启服务器。 4、你已经删除了一些占用量大的文件，或者在根盘下做du -h发现占用量远远的小于130G，df的结果仍然是100%的使用率。 那么基本肯定你碰到了linux的一个bug，直接重启就能解决。 （当然了也不一定是bug，我碰到过那种程序在写一个日志，但是删除日志后空间不释放的问题。 这个是linux本身的机制引起的，只需要停止相关的程序空间就会释放的）
发表评论