-
年ilovehim2021-10-31 07:09
- 44
- 0
问题描述通过终端登录时候后需要等待 几秒 才登录到系统; 然后执行其他命令时; 时而快，时而慢;而使用Debian镜像没有出现过类似问题,排除了家里网络问题登录成功注意到信息: #System information disabled due to load higher than 4.0#,猜测是 系统负载过高造成....`执行 uptime 输出：ubuntu@ubuntu:~$ uptime 06:08:53 up 33 min, 1 user, load average: 4.75, 4.88, 4.50ubuntu@ubuntu:~$ uptime 06:08:55 up 33 min, 1 user, load average: 4.75, 4.88, 4.50ubuntu@ubuntu:~$ uptime 06:08:55 up 33 min, 1 user, load average: 4.75, 4.88, 4.50因为系统为4核心,可以看出 在 1min,5min,15min 系统还是过载执行 top 输出：top - 06:11:03 up 35 min, 1 user, load average: 4.94, 4.88, 4.55Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie%Cpu0 : 0.7 us, 1.7 sy, 0.0 ni, 82.8 id, 14.8 wa, 0.0 hi, 0.0 si, 0.0 st%Cpu1 : 0.7 us, 3.0 sy, 0.0 ni, 61.5 id, 34.8 wa, 0.0 hi, 0.0 si, 0.0 st%Cpu2 : 0.7 us, 1.0 sy, 0.0 ni, 97.7 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st%Cpu3 : 0.7 us, 1.3 sy, 0.0 ni, 17.5 id, 80.5 wa, 0.0 hi, 0.0 si, 0.0 stMiB Mem : 7810.3 total, 6697.4 free, 582.0 used, 530.9 buff/cacheMiB Swap: 0.0 total, 0.0 free, 0.0 used. 7116.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4952 mysql 20 0 1049172 375468 30992 S 7.6 4.7 0:01.41 mysqld 2000 mongodb 20 0 973476 73396 31316 S 1.0 0.9 0:25.15 mongod 4940 ubuntu 20 0 10692 3256 2692 R 1.0 0.0 0:00.27 top 210 root 20 0 0 0 0 D 0.3 0.0 0:02.78 usb-sto+ 2060 redis 20 0 50212 4628 3088 S 0.3 0.1 0:05.78 redis-s+ 3288 root 20 0 0 0 0 I 0.3 0.0 0:00.67 kworker+ 3703 root 20 0 0 0 0 I 0.3 0.0 0:00.83 kworker+ 1 root 20 0 167636 10668 7116 S 0.0 0.1 0:06.21 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 再次执行 top 命令输出top - 06:14:14 up 38 min, 1 user, load average: 4.87, 5.02, 4.68Tasks: 148 total, 2 running, 146 sleeping, 0 stopped, 0 zombie%Cpu(s): 2.2 us, 4.0 sy, 0.0 ni, 46.5 id, 47.3 wa, 0.0 hi, 0.0 si, 0.0 stMiB Mem : 7810.3 total, 6866.6 free, 423.6 used, 520.1 buff/cacheMiB Swap: 0.0 total, 0.0 free, 0.0 used. 7274.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5206 mysql 20 0 254784 206804 20384 R 14.2 2.6 0:00.43 mysqld 2000 mongodb 20 0 973476 73396 31316 S 1.0 0.9 0:27.05 mongod 1 root 20 0 167636 10668 7116 S 0.7 0.1 0:06.46 systemd 908 root 19 -1 67452 14556 13572 S 0.3 0.2 0:01.05 systemd+ 1964 root 20 0 237596 6764 5852 S 0.3 0.1 0:00.30 account+ 2060 redis 20 0 50212 4628 3088 S 0.3 0.1 0:06.31 redis-s+ 4150 root 20 0 0 0 0 I 0.3 0.0 0:00.37 kworker+ 4152 root 20 0 0 0 0 I 0.3 0.0 0:00.41 kworker+ 5125 ubuntu 20 0 10692 3284 2716 R 0.3 0.0 0:00.49 top 2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par+ 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker+ 7 root 20 0 0 0 0 I 0.0 0.0 0:00.36 kworker+ 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_perc+从上面 top 输出可以看出 可能是 mysqld 的问题 下面停掉 mysql服务sudo systemctl stop mysql重新登录后 执行 uptime 命令ubuntu@ubuntu:~$ uptime 07:04:59 up 1:29, 1 user, load average: 2.77, 3.93, 4.48ubuntu@ubuntu:~$ uptime 07:05:00 up 1:29, 1 user, load average: 2.77, 3.93, 4.48ubuntu@ubuntu:~$ uptime 07:05:00 up 1:29, 1 user, load average: 2.77, 3.93, 4.48ubuntu@ubuntu:~$ uptime 07:05:01 up 1:29, 1 user, load average: 2.77, 3.93, 4.48ubuntu@ubuntu:~$ uptime 07:05:01 up 1:29, 1 user, load average: 2.77, 3.93, 4.48从上面可以看出 load average 基本正常了,现在的问题是 为什么 mysql造成 load average 这么高？环境简述 系统为 ubunt server 使用 U盘(32G) 安装在 raspberry-pi 4(8G RAM) 上面click here to see ubuntu raspberry-pi image info系统信息ubuntu@ubuntu:~$ uname -aLinux ubuntu 5.4.0-1045-raspi #49-Ubuntu SMP PREEMPT Wed Sep 29 17:49:16 UTC 2021 aarch64 aarch64 aarch64 GNU/LinuxCPU 信息ubuntu@ubuntu:~$ lscpuArchitecture: aarch64CPU op-mode(s): 32-bit, 64-bitByte Order: Little EndianCPU(s): 4On-line CPU(s) list: 0-3Thread(s) per core: 1Core(s) per socket: 4Socket(s): 1Vendor ID: ARMModel: 3Model name: Cortex-A72Stepping: r0p3CPU max MHz: 1500.0000CPU min MHz: 600.0000BogoMIPS: 108.00Vulnerability Itlb multihit: Not affectedVulnerability L1tf: Not affectedVulnerability Mds: Not affectedVulnerability Meltdown: Not affectedVulnerability Spec store bypass: VulnerableVulnerability Spectre v1: Mitigation; __user pointer sanitizationVulnerability Spectre v2: VulnerableVulnerability Srbds: Not affectedVulnerability Tsx async abort: Not affectedFlags: fp asimd evtstrm crc32 cpuid架构:aarch64, 1 个 cpu , 4 核心以往经历之前因为 aria2 log 占满整个分区导致 系统卡顿,命令执行缓慢执行 df -m 输出:Filesystem Size Used Avail Use% Mounted onudev 3.7G 0 3.7G 0% /devtmpfs 782M 4.0M 778M 1% /run/dev/sdb2 29G 6.1G 21G 23% /tmpfs 3.9G 0 3.9G 0% /dev/shmtmpfs 5.0M 0 5.0M 0% /run/locktmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup/dev/loop0 49M 49M 0 100% /snap/core18/2248/dev/loop1 49M 49M 0 100% /snap/core18/2068/dev/loop2 62M 62M 0 100% /snap/lxd/19040/dev/loop3 27M 27M 0 100% /snap/snapd/10709/dev/loop4 60M 60M 0 100% /snap/lxd/20330/dev/loop5 28M 28M 0 100% /snap/snapd/11843/dev/sdb1 253M 166M 87M 66% /boot/firmwaretmpfs 782M 0 782M 0% /run/user/1000Refunderstanding-the-load-average
0
打赏
收藏
点击回答
- 共 0 条
- 全部回答
-
暗云飞飞 普通会员 1楼
在 Ubuntu Server 中，
load average可能会导致负载过高。load average是一个统计值，用于衡量系统负载的变化情况。如果这个值过高，可能意味着系统正在处理大量的请求，或者系统在某个特定的时间段内处理请求的速度较慢。以下是一些可能的原因和解决方法：
-
连接数过多：如果在服务器上运行多个数据库服务，可能会导致
load average过高。你可以尝试减少数据库服务的数量，或者考虑使用负载均衡技术。 -
服务器性能不足：如果服务器的 CPU 或内存 硬件性能不足，也可能导致
load average过高。你可以考虑升级服务器的硬件配置，或者使用更高效的操作系统和数据库管理系统。 -
数据库性能问题：如果数据库本身的性能存在问题，也可能导致
load average过高。你可以考虑优化数据库的查询性能，或者升级数据库硬件。 -
网络问题：如果网络连接不稳定或者速度慢，也可能导致
load average过高。你可以尝试优化网络设置，或者检查网络连接。 -
负载均衡设置不当：如果你的服务器没有正确地设置负载均衡，也可能导致
load average过高。你需要检查负载均衡设置，确保正确的将请求分发到各个服务器。
总之，要解决
load average过高的问题，你需要找出问题的原因，并采取相应的措施进行解决。 -
更多回答
网站公告
- 扫一扫访问手机版
回答动态
- 神奇的四哥：发布了悬赏问题阿里云幻兽帕鲁服务器更新之后。服务器里面有部分玩家要重新创建角色是怎么回事啊？预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题函数计算不同地域的是不能用内网吧？预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题ARMS可以创建多个应用嘛?预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题在ARMS如何申请加入公测呀？预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题前端小程序接入这个arms具体是如何接入监控的，这个init方法在哪里进行添加？预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题阿里云幻兽帕鲁服务器刚到期，是不是就不能再导出存档了呢？预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题阿里云幻兽帕鲁服务器的游戏版本不兼容 尝试更新怎么解决？预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题阿里云幻兽帕鲁服务器服务器升级以后 就链接不上了，怎么办？预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题阿里云幻兽帕鲁服务器转移以后服务器进不去了，怎么解决？预计能赚取 0积分收益
- 神奇的四哥：发布了悬赏问题阿里云幻兽帕鲁服务器修改参数后游戏进入不了，是什么情况？预计能赚取 0积分收益
- 回到顶部
- 回到顶部