最近使用 Amazon Lightsail 部署了一个web服务，但它经常会断联，甚至ssh也无法登陆。推测应该是某个性能尖峰时刻把系统资源打爆了。下面记录一下排查和处理方法。 由于购买的是最小规格实例，所以一开始就先创建了 swapfile ，避免瞬时内存暴涨导致系统失效。不过，在这个环节有一些疏忽，导致后来运行过程中实际没有生效。具体原因后面再谈，先看看遇到的状况：
- 首先是访问 web 服务一直提示 timeout；
- 使用 ssh 连接也无法连通；
- 使用 Amazon 自己的 console 也无法连入 ssh。虽然在 console 中，实例状态仍然是 running ，但这只是说明了实例本身的虚拟机进程还在，无法说明虚拟机内部服务仍然正常；
诊断过程
第一步排查先看了CPU利用情况
可以看到，虽然存在一些尖峰，但未超过100%，基本可以排除 CPU 被打爆导致的异常
第二步看 status check 下的几个图表（status check failures、instance status check failures、system status check failures）
可以看到，System status check failures 中没有异常，但其余两者都出现了问题。
那么基本可以大胆猜测，是我自己部署的服务出现了问题，拖垮了系统资源。现在应该考虑重启一下，再用 journalctl 查看我的服务日志了。
这里一定要直接点击 console 里的 reboot ，可以保证 ip 不变。
重启后，ssh 服务恢复，进入后运行 sudo journalctl -b -1 -p err..alert
ummm 问题清晰地出现在眼前，真的 OOM 了。进一步看看内存占用和 swap 情况：
wait…为啥 swap total 0B ？我 swapfile 呢？ 回顾了 command history 后意识到一个问题，因为没把它加入到 fstab 中，所以一重启就失效了。。。
一定要记得 echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
常用命令
最后列一些运维常用命令
uptime
用法：直接 uptime
输出：02:33:33 up 1:00, 1 user, load average: 0.02, 0.05, 0.02
02:33:33 表示当前服务器的时间
up 1:00 表示已经运行1小时
load average: 0.02, 0.05, 0.02 分别表示过去1、5、15分钟的 CPU 负载
要注意，负载需要结合 CPU 核心数看。如果只有 1 核，1.0 就是满载。如果 2 核，2.0 才是满载
free
查看内存和 swap 使用情况
一般用 free -h ，改换单位，输出成人类更可读的格式
df
查看硬盘使用情况，和free类似，一般用 df -h
top
用法：top -o %CPU
-o %CPU 的意思是按 CPU占用率排序
同理，可以用 top -o %MEM 按内存占用率排序
journalctl
重要的服务日志查看工具，可以查看 systemd 收集的日志
-p 显示 err 到 alert 级别的日志，包括：
errcritalert不含warninginfodebug
--since "24 hours ago" 只看最近24小时的日志
-k 仅查看内核日志
-b -1 上一次启动周期
dmesg
环形缓冲区日志，主要记录了 内核 输出的信息 环形的意思是存储区域循环使用，类似于行车记录仪滚动删除
dmesg 默认的计时使用启动后秒数。加 -T 参数可以转换成实际时间
一般配合 egrep 过滤输出，比如不区分大小写滤除特定关键词的日志，可以这样用：
sudo dmesg -T | egrep -i 'oom|killed process|error|ext4'
它一般只能保存本次启动以来的日志，之前的日志应该使用 journalctl 查看