Browsed by
标签: swap

定时清理释放内存

定时清理释放内存

家里有台 Raspberry Pi3, 日常做点小任务,比如做 samba 服务器当 NAS、做 web 的功能测试、学习点 Linux 知识等,基本都是一些负荷不大的任务。不过由于我是死忠的 GUI 党, 因此总是喜欢进入 Pi 那个巨丑无比的界面里进行操作,这也导致 Pi3 的内存会逐渐显得有些捉襟见肘,时间长了,就不得不使用 swap 。这可能会有损 microSD 卡的寿命,因此希望 Pi 能定时清理、释放内存。

网上搜了搜,也比较简单,而且效果比较明显。简要记录一下:

在 /etc/cron.daily 目录下,创建一个 gilson-clearcache 文件,内容如下:

#!/bin/sh
sync
echo 3 > /proc/sys/vm/drop_caches

将这个文件设置为可执行文件即可:

sudo chmod +x ./gilson-clearcache

设置为可执行文件后,可以手工执行一下,可以看到 “free -m” 显示的结果里,“buff/cache available”等项有明显的改善。

不过考虑到 Pi3 可怜的 1GB 内存,这种内存回收方面的改善,估计不能从根本上解决问题,上 Pi4 (2GB或者4GB)或许更好。后续继续观察一下,如果实在不行,就换 Pi4 或者等 Pi5 吧。

给 vbox 的客机系统扩容

给 vbox 的客机系统扩容

主机是Window 10, 运行在 VirtualBox 中的客机系统是 Debian (testing)。当初估计不足,只划了 8G 空间给客机系统,因此面临着容量不足的问题,迫切需要扩容,要不然就要重新构建一个客机,实在过于麻烦了。

从网上搜集了一些信息,有各种问题。绝大部分的资料其实不能算扩容,无非就是增加一个盘,然后 mount 到新的分区而已。而我希望是将现有的虚拟硬盘直接扩容,无需改变或者 mount 特定的分区或者目录。最后通过安装 GParted 软件,加上修改部分配置,终于解决了问题,从8G 扩展到 28G, 如下图所示:

扩容后的硬盘分区
扩容后的硬盘分区

系统只有两个分区: 主分区 和 交换分区。目的就是扩大主分区(/dev/sda1)的容量即可,其他无需改变(至少在使用者的角度是没有任何变化)。

增加 VBox 虚拟介质容量

VBox 新版都支持给虚拟介质扩容,操作简单。在“管理 – 虚拟介质管理”里找到客机的虚拟介质,直接增加容量即可。比如,将介质从 8G 直接调整到 28G。

但是客机系统不是直接就使用了扩容的硬盘容量。新增加的部分对客机系统而言,属于“未分配”的容量,因此需要进入客机系统(也就是 Debian)中进行磁盘管理,让系统能识别、管理这部分新容量。

Debian 磁盘管理

牛人直接用 fdisk 大概就可以搞定。作为一名无可救药的图形界面党, 我当然还是倾向于使用图形界面的软件来解决问题(非常不 linux,非常不 geeker),也就是 GParted。

GParted 很像 Windows 的磁盘管理工具,因此使用起来油然而生熟悉的感觉。启动 GParted 后,很容易就看到未分配的磁盘容量。可惜不能直接移动或者扩容/dev/sda1,原因大概是中间有个 swap 分区。刚开始我被困住了,后来想明白:

既然 swap 分区阻挡了主分区的扩容(移动),那删除掉 swap 分区,那主分区和未分配分区不就连起来了吗? 试试后发现果然如此:(1)删除 swap 分区, (2)调整主分区(/dev/sda1)的大小,(3)然后再重新将剩余的分区设置为 swap 分区。

千万别格式化主分区!只需要重新格式化 swap 分区即可。

GParted 有个bug:在上述步骤中,重新删除、创建了 swap 分区,可是 GParted 并没有修改 /etc/fstab 里对应的 UUID 值!导致每次重启后,发现 swap 区都没有激活使用。

解决这个bug也简单,在 GParted 中查询 swap 分区的属性,获取其 UUID 值,然后修改 /etc/fstab 中对应的 swap 分区的 UUID 值即可。

一点思考

本次扩容过程中,被 swap 分区困扰了很久,有各种问题。要么是 swap 分区阻挡了主分区扩容,要么是 swap 分区的 UUID 更新(这个算GParted的bug)。

如果不设置 swap 分区呢? 修改为采用 swap 文件方式,只保留一个主分区,这样就灵活很多。当然,实际部署 Linux 系统如果采用这种方式,可能会有问题(比如崩盘导致数据丢失等),既然是客机系统,倒是无所谓。

DigitalOcean小坑

DigitalOcean小坑

DigitalOcean是我个人非常喜欢的云计算服务商,我们在部署自己的网站、云通信系统、向客户推荐等各种情况都会采用DO(以及Linode,另一个非常优秀的云计算服务商)。

绝大多数情况下,DO节点运行非常快速、稳定,然而有时候也有意想不到的情况发生。最近我们发现一个节点的服务突然中断了,经检查后发现是MySQL数据库异常退出,错误原因是内存分配不足。以前从未发生过这种情况,简单对比后发现这个节点是个小内存节点,只有512M内存(通常我们都为生产环境节点配置2G内存)。我们认为这个节点的MySQL数据库不应该占用太多内存,即便512M内存不够,加上SWAP的支持也应该足够了。

然而分析该节点信息,惊讶地发现DO默认居然没有分配SWAP区(与之对比的是,Linode可以在创建节点时指定SWAP分区)!

检索了DO的文档,对这种情况的解释是建议采用更多内存的节点,SWAP做缓存会拖慢系统,并可能影响其他用户。原则上这点没错,如果频繁发生内存不够的情况,的确应优先升级节点,采用更多内存。然而,如果仅仅是在尖峰时刻偶尔少量内存不足,采用SWAP过渡一下完全合理。

更重要的是,即使SWAP相对而言慢一些,但相比程序crash而言,一个慢点但是稳定的系统显得更合理。同时考虑到DO采用SSD硬盘,速度可以接受,因此我们手工增加了2G的SWAP设置。事实证明,内存在忙时实际只少了1M,用SWAP来应对这1M内存的需求,相当合理。

在DO节点增加SWAP很容易,请点击这里了解细节。文档是基于Ubuntu 14.04,我们的节点是Debian 8,按照这篇文档的介绍,也能设置成功。