早期的时候买了一台阿里云服务器，99元一年的E系列，2核2G3M，虽然性能一般，但是勉强够做一些测试用了，后来用这台服务器搭建了现在这个博客网站。
但是在使用这台服务器的期间，经常遇到让我抓狂的问题————宕机！！！
拿2024年5月6号的宕机为例，当时我在宝塔界面开始一键安装Docker和Docker Compuse，服务器突然就宕机了，SSH无法连接，网站也直接打不开，甚至也无法ping通，尝试用阿里云控制台的VNC远程连接，依旧无法连接。
查看了阿里云控制台的服务器监控，看到CPU和内存跑满了，我想着是不是安装的时候，超负荷了，毕竟也就2核2G。那么就等一会吧。。。。
可是一个多小时过去了。。。CPU和内存依旧爆满！
提了工单，回复说只能重启来恢复，于是我重启了。。。。足足重启了半个多小时（担心丢失数据没有做强制重启）。
重启成功后，服务器终于恢复了正常了。于是我就把原因归咎于我安装应用的操作超出了服务器的载荷，导致了服务器负载宕机。
下一次控制着点力度就可以了。
后来的一段时间我的博客持续正常运行着，直到今天，大约早上9点多的时候打开了我的博客页面，习惯性的看看是否正常运行着，结果：
倒吸一口凉气，第一个想到的就是服务器上的程序异常了，于是赶紧上号查看，结果SSH直接没有响应，然后又下意识的ping了下：
又宕机了？我再次进入到阿里云控制台的监控页面：
果然，又高负荷了，导致了宕机。从早上7:40就开始突然暴增，没办法，只能先重启。重启到了11:15才重启完成。
一切又恢复了正常，但是这次却有些奇怪，7:40的时候我没有对服务器做过任何的操作，我部署的应用也不可能在内部产生这么高的负荷，我也没有设置7:40的定时任务。可是为什么会高负荷呢？
如果能查看到那段时间的进程日志就好了，好在宝塔提供了这样的功能：
发现一个叫snapd的进程始终排在了TOP1，上网查找了一下，大概知道了这是个Ubuntu的一种全新的软件包管理方式。
Snaps 是 Ubuntu 的母公司 Canonical 于 2016 年 4 月发布 Ubuntu 16.04 LTS（Long Term Support，长期支持版）时引入的一种容器化的软件包格式。自 Ubuntu 16.04 LTS 起，Ubuntu 操作系统可以同时支持 Snap 及 Debian 这两种格式的安装包。
Snap 虽然有一定的优点（与Docker的容器化优点类似），但是不足之处更多。Snap 软件包体积庞大，snapd 进程会导致系统重启等待，并且可能导致卡顿，禁用为佳。特别是服务器版用不上这种软件包，默认是安装的，必须彻底删除。
好，那么我把snap禁用自启就行了。
reboot重启之后验证，依旧运行着：
又查了下，发现snap无法禁用，只能彻底删除。
使用命令sudo apt autoremove --purge snapd
重启后验证，成功彻底删除：
版权声明：如无特殊说明，文章均为本站原创，转载请注明出处
本文链接：https://thechen.work/subject/article/slug_linux/
许可协议：署名-非商业性使用 4.0 国际许可协议
