宝塔面板内存占用高与系统加固插件无直接关系；该插件仅封装安全策略，常驻Python进程占30–80MB内存，还会fork子进程扫描，加重低配机器负担。
宝塔面板内存占用率居高不下，和「系统加固插件」没有直接关系——它不释放内存，也不优化资源，装了反而可能加重负担。
系统加固插件实际干了什么
这个插件本质是安全策略封装工具：自动配置 iptables 规则、禁用 root 远程登录、限制 SSH 重试次数、扫描弱口令、记录登录日志。它启动后会常驻一个 python 进程监听事件，本身就要吃 30–80MB 内存，还会定期 fork 子进程做扫描任务。
在 1GB 内存的机器上，你本已接近 OOM 边缘，再加一个持续轮询的加固服务，只会让 bt 主进程和 /usr/bin/python 更频繁触发内存回收压力。
- 它不管理 PHP-FPM、MySQL 或 OPcache 的内存分配
- 它不会清理
/dev/shm中堆积的 session 文件 - 它不修改
pm.max_children或innodb_buffer_pool_size - 它甚至不提供「一键释放内存」按钮（那是伪需求）
真正有效的内存释放动作有哪些
内存不是被“锁住”了，而是被进程实实在在占用了。所谓“释放”，只能靠停止进程、调低配额、或清空缓存池。以下操作立竿见影：
- 执行
bt restart重启面板 —— 会杀掉所有python子进程，重置监控轮询状态，通常能回落 150–300MB - 删掉不用的 PHP 版本：比如只用
php74，就卸载php80、php82，每个版本至少省 80MB RSS - 手动清空 OPcache：访问
http://你的域名/oc.php（内容为<?php opcache_reset(); ?>），比重启 PHP-FPM 更轻量 - 清空
/dev/shm中残留 session：rm -f /dev/shm/php-fpm.*，注意别删错成/dev/shm/mysql.sock
哪些操作看似“释放内存”实则无效或危险
网上流传的很多“释放脚本”或“一键清理”，往往混淆了 cache、buffer、RSS 和虚拟内存的概念，执行后 free -h 看起来数字变小了，但真实负载没变，甚至引发服务中断。
-
echo 3 > /proc/sys/vm/drop_caches：只清 pagecache、dentries、inodes，对 PHP/MySQL 占用的 RSS 毫无影响 - 在计划任务里加
sync && echo 3 > /proc/sys/vm/drop_caches：每天半夜执行，纯属自我安慰，还可能拖慢备份速度 - 卸载「网站监控」「防火墙」插件却不改
/www/server/panel/data/interval.pl：轮询逻辑还在，只是界面不显示，内存照吃 - 把
pm.max_children直接设成 1：并发请求会排队或 502，用户感知更差，不是“省内存”，是“堵住出口”
最常被忽略的一点：宝塔的内存统计本身不包含 OPcache 和 MySQL buffer pool 的私有内存池。你看到的 ps aux 里 mysqld RSS 是 1.2G，但 innodb_buffer_pool_size 设的是 1.5G —— 那多出来的 300MB 就在内核页表里，free 不显示，top 也抓不到，但它真真切切压着物理内存不放。
