记一次Linux服务器top命令us负载很高,但是找不到高负载进程,引起服务器频繁重启的错误,内核升级

本文分享了一次解决CentOS服务器频繁重启问题的经历,详细记录了从发现问题、定位故障源头到手动编译安装新内核的全过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近发现一台测试服务器频繁重启,各种排错找不到原因,
服务器:CentOS6
内核:2.6.32-431.1.2.0.1.el6.x86_64
这里要注意了,引起服务器频繁重启的原因很有可能是内核引起的
随后查找了目前为止有缺陷的内核版本,如下:

Centos 6:

2.6.32-220.el6.x86_64
2.6.32-431.el6.x86_64
2.6.32-71.el6.x86_64

Centos 7:

3.10.0-229.el7.x86_64
这里说一下,内核升级一定要编译安装的方式升级,请勿使用yum。因为服务器在机房,做内核升级用yum,导致开机起不来的情况时有发生。

问题:

随后用top命令查看服务器负载不高,但是发现用户态占用cpu使用率非常高,16核cpu,经常12个都是100%,但是查看进程并没有cpu占用太高的进程,从右侧上方查看cpu负载也不是很高
如图:
这里写图片描述
如果是内核态占用率高的话也就好怀疑是内核的问题了,但是内核态看起来一切正常。通过ps aux命令查看所有进程进行逐一排查,并停掉所有在使用的进程,并没有发现异常进程。用户态占用还是奇高。加上此内核在缺陷内核列表内,所以接下来进行内核升级。

升级内核:

官网现在最新稳定版kernel,截至2018.5.28最新稳定版本是4.16.11,因为服务器在国外,所以下载很慢,这里推荐多线程下载器 mwget 命令行多线程下载器,安装也很简单,因为服务器很不稳定,所以我加上了nohup进行后台下载,这里的mwget是指定几个线程同时下载。当然用wget下载也是可以的。mwget只是推荐。

  • 下载:
nohup mwget -c0 -n 32 https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.11.tar.xz &

然后解压内核:

tar xJf linux-4.16.11.tar.xz -C /usr/src/kernel

  • 环境准备:

    yum yum groupinstall "Development Tools" -y

    yum -y install openldap openldap-clients openldap-developenldap-servers gcc gcc-c++ glibc automake autoconf libtool makelibmcrypt-devel mhash-devel libxslt-devel libjpeg libjpeg-devel libpnglibpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-develglibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-develcurl curl-devel e2fsprogs e2fsprogs-devel krb5 krb5-devel libidn libidn-developenssl openssl-devel hmaccalc  binutils-devel elfutils-libelf-devel bc

    • 编译安装内核:
      cd /usr/src/kernel/linux-4.16.11/
      因为已经有老内核,所以用老内核的配置文件,省事。复制老内核配置文件到当前目录下并改名为.config
      1. cp /boot/config-2.6.32-431.el6.x86_64 ./.config
      接下来本应该运行这个命令: make mrproper && make clean进行编译但是没安装的文件进行清空,因为我是刚解压过来的,所以就免了。直接下一步。
      2. make menuconfig
      用这个命令可以对内核模块进行定制,我只改个名其它没有修改。
      这里记录一下,这个命令是基于.config进行内核模块的修改。建议没什么特殊需求,直接用改个名字退出就行,退出的时候问你是否保存,当然要保存,也可以先save进行保存。
      3. make -j 16
      这里说一下,-j 就是指定几个cpu进行编译。我希望快点,所以用了所有cpu,当然 也可以用make all

    这里进行编译的时候会报错

    也不是绝对的,我升级了两个机器,虚拟机正常,但是实体机会报错。
    * Error during update of the configuration.
    make[2]: * [silentoldconfig] 错误 1
    make[1]: * [silentoldconfig] 错误 2
    SYSTBL arch/x86/include/generated/asm/syscalls_32.h
    SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
    SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
    SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
    make: * 没有规则可以创建“include/config/kernel.release”需要的目标“include/config/auto.conf”。 停止。
    make: * 正在等待未完成的任务….

    解决办法

    思路就是复制老内核的auto.conf给新内核使用。
    cp /usr/src/kernels/2.6.32-431.1.2.0.1.el6.x86_64/include/config/auto.conf /usr/src/kernel/linux-4.16.11/incloud/config/
    如果没有config目录,就创建这个目录。然后再进行编译就不报错了。

4. make modules_install
编译安装 .config给定的各种模块
5. make install
进行安装。然后等待安装完毕,如果安装成功,打开/etc/grub.conf。会显示有两个版本的内核,默认启动老内核,更改default默认值,从上往下依次从0开始,保存/etc/grub.conf并重启。

[root@localhost ~]# uname -r
4.16.11dongsi

6.然后就是重启服务器
大功告成,负载也下来了。服务器平稳运行:
这里写图片描述
下面这个问题好像全网都没解决办法,不少人也遇到了,再贴一下,为了帮助更多人
* Error during update of the configuration.
make[2]: * [silentoldconfig] 错误 1
make[1]: * [silentoldconfig] 错误 2
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
make: * 没有规则可以创建“include/config/kernel.release”需要的目标“include/config/auto.conf”。 停止。
make: * 正在等待未完成的任务….

解决办法

思路就是复制老内核的auto.conf给新内核使用。
cp /usr/src/kernels/2.6.32-431.1.2.0.1.el6.x86_64/include/config/auto.conf /usr/src/kernel/linux-4.16.11/incloud/config/
如果没有config目录,就创建这个目录。然后再进行编译就不报错了。

<think>好的,我现在需要帮用户分析他们提供的top命令输出。首先,我要回忆一下top命令各个部分的含义,确保自己理解正确。用户给出的信息包括系统运行时间、用户数、负载、任务状态、CPU使用情况、内存和交换空间的使用情况。 首先看第一行:16:31:40是当前时间,up 228天表示系统已经运行了228天,说明这是一台长期运行的服务器,可能没有重启过,稳定性不错。2 users显示当前有两个用户登录,可能是通过SSH或者其他方式连接的用户。负载平均值分别是7.00、7.01、7.14,这三个值代表过去1分钟、5分钟、15分钟的平均负载。通常来说,如果每个核心的负载超过1,说明系统可能过载。但需要知道系统有多少个CPU核心才能准确判断。例如,如果有8个核心,那么负载在8以下都是可以接受的。但这里用户没有提供CPU核心数,可能需要提醒用户这一点,或者假设常见的配置来分析。如果系统是8核,那7左右的负载可能接近饱和,但如果是更多核心,比如16核,那负载在7左右可能还有余量。不过负载持续在7左右,可能需要关注是否有资源瓶颈。 接下来是Tasks行:总共有1057个进程,其中1个正在运行,1056个休眠,没有停止或僵尸进程。这里运行中的进程数量很少,大部分处于休眠状态,说明系统当前没有大量活跃的进程,但可能存在一些高负载的任务在后台运行,或者有某个进程占用了大量资源,导致负载较高。没有僵尸进程是好的,说明没有残留的进程问题。 然后是CPU使用情况:用户空间占6.1%,系统空间1.8%,ni(nice值调整的进程)0%,空闲92.1%。这说明CPU大部分时间处于空闲状态,用户态和内核态的占用都不高,所以CPU并不是瓶颈。高负载但低CPU使用率可能意味着等待I/O或者其他资源,比如磁盘I/O或内存交换。但这里的wa(等待I/O)是0%,看起来磁盘I/O没有问题。需要进一步分析内存使用情况。 内存部分:总内存261505.4 MiB(约255GB),空闲25,466.4 MiB,已使用91,405.9 MiB,缓存/缓冲144,633.0 MiB。Linux的内存管理会尽可能利用内存作为缓存,所以虽然已使用内存显示较高,但大部分可能被缓存占用。实际可用的内存是空闲的25GB加上缓冲/缓存的144GB,所以总共有约170GB可用(25+144),不过avail Mem显示的是123,711.2 MiB(约120GB),这个值可能更准确,因为avail Mem考虑了哪些缓存可以立即释放。这说明内存使用情况良好,没有严重的内存压力。 交换空间:总16,382.9 MiB,空闲11,094.9 MiB,已使用5,288.0 MiB。使用了约5GB的交换空间,这可能是因为部分不活跃的内存页被换出到磁盘,但剩余11GB可用,交换空间使用率不算高。不过,如果系统频繁使用交换空间,可能会影响性能,但目前看来使用量不大,可能只是偶尔使用。 综合来看,系统的负载较高但CPU使用率低,可能的问题点在哪里呢?可能的原因包括:1. 大量的I/O等待,但wa是0%,所以排除;2. 大量的进程处于不可中断睡眠状态(D状态),这种情况会导致负载升高但CPU使用率低,因为进程在等待I/O完成,无法被中断。不过top默认不显示进程状态,需要用户检查进程列表,查看是否有D状态的进程。或者可能存在锁竞争,导致进程在等待资源。另外,高负载也可能是由于大量的短时进程频繁启动和退出,导致上下文切换频繁,但sy(系统CPU时间)只有1.8%,似乎不高。可能需要检查磁盘性能,使用iostat查看磁盘使用情况,或者使用vmstat查看上下文切换次数。 此外,虽然内存和交换空间看起来足够,但需要确认是否有内存泄漏导致缓存无法释放,不过avail Mem显示有120GB可用,可能问题不大。建议用户检查进程列表,看看是否有异常进程占用资源,或者使用iotop检查磁盘I/O,以及检查网络状况等其他可能影响系统性能的因素。</think>以下是您提供的 `top` 命令输出的逐项分析: --- ### **1. 系统概要信息** ``` top - 16:31:40 up 228 days, 22:34, 2 users, load average: 7.00, 7.01, 7.14 ``` - **16:31:40**:当前系统时间。 - **up 228 days, 22:34**:系统已连续运行 228 天,稳定性较高。 - **2 users**:当前有 2 个用户登录。 - **load average**:系统负载(1分钟、5分钟、15分钟)均为 **7.00** 左右: - 若 CPU 核数为 **8**,则负载接近饱和(需结合核数判断)。 - 若负载持续高于 CPU 核数,可能表示资源瓶颈(如 I/O、CPU 竞争)。 --- ### **2. 进程状态** ``` Tasks: 1057 total, 1 running, 1056 sleeping, 0 stopped, 0 zombie ``` - **1057 total**:总进程数较多,常见于复杂服务环境。 - **1 running**:仅 1 个进程处于运行状态,其他均为休眠(sleeping)。 - **0 zombie**:无僵尸进程,系统进程管理正常。 --- ### **3. CPU 使用率** ``` %Cpu(s): 6.1 us, 1.8 sy, 0.0 ni, 92.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st ``` - **us (用户态)**:6.1%,正常范围。 - **sy (内核态)**:1.8%,无显著系统调用压力。 - **id (空闲)**:92.1%,CPU 资源充足。 - **wa (I/O等待)**:0.0%,无磁盘 I/O 瓶颈。 - **st (虚拟机窃取时间)**:0.0%,虚拟化环境无资源争抢。 --- ### **4. 内存使用** ``` MiB Mem : 261505.4 total, 25466.4 free, 91405.9 used, 144633.0 buff/cache MiB Swap: 16382.9 total, 11094.9 free, 5288.0 used. 123711.2 avail Mem ``` - **物理内存**: - 总量:约 **255 GB**(261505.4 MiB)。 - 已用:91.4 GB(含应用程序和缓存)。 - 缓存/缓冲:144.6 GB,Linux 自动利用空闲内存加速 I/O。 - **可用内存**:123.7 GB(`avail Mem`),资源充足。 - **交换分区**: - 总量:16 GB,已用 5.3 GB,剩余 11 GB。 - 少量交换空间使用,通常无需担心。 --- ### **关键问题诊断** 1. **高负载但低 CPU 使用率**: - 可能原因:进程处于 **不可中断睡眠(D 状态)**(等待 I/O 或网络响应)。 - 检查方法:在 `top` 中按 **`d`** 查看进程状态,或使用 `ps aux | awk '$8=="D"'`。 2. **潜在 I/O 瓶颈**: - 虽然 `wa=0%`,仍需排除存储延迟问题,建议使用 `iostat -x 1` 观察磁盘利用率。 3. **进程竞争**: - 检查是否有大量短生命周期进程频繁启动/退出,导致上下文切换(通过 `vmstat 1` 查看 `cs` 列)。 --- ### **建议操作** 1. **查看高负载进程**: - 在 `top` 中按 **`P`**(按 CPU 排序)或 **`M`**(按内存排序),定位资源消耗者。 2. **检查磁盘性能**: ```bash iostat -x 1 # 查看磁盘 I/O 使用率和延迟 ``` 3. **监控网络**: ```bash nload # 查看网络带宽使用 ``` 4. **排查 D 状态进程**: ```bash ps aux | awk '$8=="D"' # 列出不可中断睡眠的进程 ``` --- 若需进一步分析,请提供以下信息: - **CPU 核数**(`lscpu | grep "Core(s)"`) - **高负载进程的详细信息**。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值