当前位置: 首页 > news >正文

2026 年两款服务器面板内存占用测试:宝塔面板和 1Panel 表现如何

很多人在选择服务器面板时,除了功能、界面和操作习惯之外,都会关心一个很现实的问题:面板本身到底占不占资源。尤其是对普通的VPS云服务器来说,内存本来就不算宽裕,如果面板常驻占用过高,多少会压缩网站、数据库和运行环境的可用空间。

所以这次,我们准备做一次尽量公平、直观的实测:在腾讯云上开通两台相同配置、相同实例类型的云服务器,分别安装宝塔面板和 1Panel,对两者的内存占用表现进行对比测试。为了尽可能减少环境差异带来的影响,测试过程中会统一服务器配置、系统环境和操作步骤,尽量把变量控制在同一条件下,看看两款面板在真实安装和运行场景里的资源占用到底表现如何。

先说结论:从这次实测结果来看,在相同配置、相近环境和一致测试思路下,宝塔面板在面板本体占用,以及后续安装常用环境、部署 WordPress 后的整体内存表现上,都要比 1Panel 更轻一些。

当然,这里的“更轻”主要是基于本次测试场景下的实际结果,并不等于所有环境、所有配置下都会完全一致。具体差距是怎么拉开的,后面我们再一阶段一阶段展开看。

测试环境

  • 厂商:腾讯云

  • 地域和可用区:广州七区

  • 实例类型:SA9.MEDIUM2

  • 实例配置:2H2G

  • 系统:Debian12.11

  • 硬盘:50G

机型和可用区

系统配置

测试步骤

第一阶段:纯净系统基线测试

在正式安装宝塔面板和 1Panel 之前,我们先对两台腾讯云服务器的纯净系统状态进行一次基线测试。先确认在相同配置、相同实例类型、相同操作系统版本下,服务器本身的初始资源占用情况,避免后续对比时把系统环境自身带来的差异误算到面板头上。本次测试中,两台服务器在完成系统安装和基础初始化后,暂不安装任何面板、网站环境或额外业务组件,仅保留系统默认运行所需的基础进程。随后让服务器空闲运行数分钟,待系统状态趋于稳定后,再分别通过 free -m、ps aux --sort=-%mem | head -20 和 top 记录当前的内存使用情况与主要进程占用。

1)整体内存情况

先通过下面的命令查看两台服务器当前的整体内存状态:

free -m

实测结果如下:

服务器

总内存

已用内存

空闲内存

buff/cache

可用内存

服务器 A(175.178.*.*)

1934 MB

370 MB

1358 MB

351 MB

1564 MB

服务器 B(43.136.*.*)

1934 MB

358 MB

1370 MB

351 MB

1575 MB

从结果来看,两台机器在纯净系统下的基础内存占用非常接近,已用内存分别为 370MB 和 358MB,差值仅 12MB。这说明两台测试机器在正式安装面板前,整体环境基本处于同一水平,能够作为后续对比测试的统一起点。

2)主要进程占用情况

随后使用下面的命令查看当前内存占用最高的进程:

ps aux --sort=-%mem | head -20

从进程列表来看,两台服务器当前占用内存较高的进程高度一致,主要集中在腾讯云默认自带的监控与安全相关组件,以及少量系统基础服务上。

其中较明显的几个进程包括:

  • YDService:RSS 分别约 74916 KB、75920 KB

  • barad_agent:RSS 分别约 28456 KB、28528 KB

  • YDLive 相关进程:RSS 分别约 23308 KB、25324 KB

  • systemd-journald:RSS 分别约 15568 KB、15616 KB

  • tat_agent:RSS 分别约 14708 KB、12696 KB

可以看到,这一阶段的内存消耗主要还不是来自业务服务,而是来自云服务器默认环境中的运维、监控与日志组件。也正因为如此,先做纯净系统基线测试是有必要的——只有把这些“系统原生占用”先记录下来,后面安装宝塔面板和 1Panel 后的增量变化才更有参考意义。

3)实时状态补充观察

为了避免只看单次快照带来的误差,我们还使用 top 对系统实时状态进行了补充观察:

top

从实时结果来看,两台服务器在空闲状态下的表现也基本一致:

服务器

已用内存

空闲内存

buff/cache

可用内存

进程总数

服务器 A

359.1 MB

1369.6 MB

352.0 MB

1575.8 MB

96

服务器 B

359.1 MB

1369.4 MB

352.3 MB

1575.8 MB

97

两台机器的实时内存占用几乎可以看作处于同一水平,说明当前测试环境稳定,适合继续进入下一阶段。

从第一阶段的数据来看,两台腾讯云服务器在未安装任何面板前,基础内存占用大致都在 360MB 左右,整体差异非常小。

这意味着后续如果在安装宝塔面板和 1Panel 后出现明显占用差异,基本就可以更有针对性地归因到面板本身及其附带服务,而不是底层系统环境不一致造成的偏差。

完成纯净系统基线测试后,接下来分别在两台相同配置的腾讯云服务器上安装宝塔面板和 1Panel,并对安装完成后的基础资源占用情况进行记录。

第二阶段:安装面板后的基础占用测试

这一阶段主要关注的是:在不安装额外网站环境、不部署业务应用的前提下,两款面板本体及其默认附带服务会带来多少内存增量。

为了尽量保证测试结果可比,本阶段两台服务器继续保持相同的系统版本和实例配置,安装时也没有额外修改参数,而是直接使用两家官网当时提供的最新安装命令进行部署。也就是说,本次测试尽量贴近普通用户的实际安装方式,不额外做精简、裁剪或自定义优化,测试结果更接近大多数用户第一次安装后的真实状态。

安装完成后,两台服务器均不额外部署 Nginx、MySQL、PHP、Docker 等运行环境,也不创建站点、数据库或容器业务,仅保留面板安装后默认启动的服务。同时,为避免安装脚本刚执行完成时仍有初始化任务、依赖拉取或后台检测进程残留带来的短时波动,面板安装结束后先让系统空闲运行一段时间,再统一开始记录数据。

我们使用测试机A安装1Panel,测试机B安装宝塔面板,分别复制官网的最新命令

在机器执行命令开始安装

注意:为尽量减少额外环境变量带来的影响,本阶段暂时不安装 1Panel 所依赖的 Docker 组件。由于 Docker 对 1Panel 后续环境部署基本属于必要依赖,因此会在后续测试运行环境时再进行安装;这一阶段先单独观察面板本体的基础占用。

安装完成后,我们先等待5分钟左右,避免安装脚本刚执行完成时仍有初始化任务、依赖拉取或后台检测进程残留带来的短时波动,面板安装结束后先让系统空闲运行一段时间,再统一开始记录数据。

1)整体内存情况

先通过下面的命令查看安装完成后的整体内存状态:

free -m

实测结果如下:

面板

总内存

已用内存

空闲内存

buff/cache

可用内存

Swap

1Panel

1934 MB

480 MB

797 MB

809 MB

1454 MB

0 MB

宝塔面板

1934 MB

495 MB

206 MB

1417 MB

1439 MB

1024 MB

从 free -m 的结果来看,安装完成后两台服务器的已用内存都在 500MB 左右,其中:

  • 1Panel 已用内存为 480MB

  • 宝塔面板已用内存为 495MB

如果和第一阶段的纯净系统基线相比:

  • 1Panel:由 370MB 增加到 480MB,增量约 110MB

  • 宝塔面板:由 358MB 增加到 495MB,增量约 137MB

单看这一轮整体内存数据,两者差距并不算大,宝塔面板比 1Panel 高出约 15MB。

(截图内的面板登录信息均已失效)

2)主要进程占用情况

随后通过下面的命令查看内存占用最高的进程:

ps aux --sort=-%mem | head -20

从结果来看,两台服务器安装面板后,占用内存最高的进程已经开始出现明显差异。

1Panel 侧主要进程

进程

RSS

1panel-agent

97548 KB

YDService

75396 KB

1panel-core

34708 KB

barad_agent

28684 KB

YDLive

25356 KB

其中,1Panel 自身最核心的两个进程分别是:

  • 1panel-agent:约 97 MB

  • 1panel-core:约 35 MB

两者合计大约 132 MB。 如果再加上云服务器默认自带的腾讯云组件,如 YDService、barad_agent、YDLive 等,整体占用会继续抬高,但这些并不属于 1Panel 本体,需要和第一阶段基线一起看待。

宝塔面板侧主要进程

进程

RSS

YDService

79392 KB

BT-Panel(Python)

45824 KB

YDLive

30384 KB

barad_agent

28708 KB

exim4

18364 KB

site_total

16832 KB

BT-Task(Python)

15044 KB

宝塔面板安装后,和面板直接相关的主要进程包括:

  • BT-Panel:约 46 MB

  • BT-Task:约 15 MB

  • site_total:约 16 MB

这里补充说明一下: site_total 是宝塔面板网站数据基础统计模块,也就是安装完成后默认运行的网站基础统计相关程序。因此在这一阶段看到它常驻内存,是符合当前安装状态的。

如果按“默认安装后的面板相关进程”口径统计,宝塔面板这一阶段可计入的主要进程包括 BT-Panel、BT-Task 和 site_total,三者合计约 77MB。

其中,site_total 为宝塔面板默认安装后启用的网站数据基础统计模块。由于本文测试的是默认安装状态下的实际占用,因此这里将其纳入面板相关进程一并统计;如果只看面板主程序本体,则可主要参考 BT-Panel 与 BT-Task。

从进程明细来看,宝塔面板的面板相关进程更分散一些,而 1Panel 则更集中在 1panel-agent 和 1panel-core 这两个核心进程上。

3)实时状态补充观察

为了避免只看单次命令快照带来误差,本阶段还通过 top 对系统稳定后的实时状态做了补充观察:

top

实测结果如下:

面板

已用内存

空闲内存

buff/cache

可用内存

进程总数

1Panel

464.5 MB

812.3 MB

810.3 MB

1470.4 MB

98

宝塔面板

510.5 MB

191.2 MB

1418.6 MB

1424.5 MB

100

这一轮 top 的结果和 free -m 基本一致,仍然可以看出:

  • 1Panel 整体已用内存略低

  • 宝塔面板整体已用内存略高

  • 两者差距大致仍在几十 MB 以内

同时,从进程列表中也能再次看到:

  • 1Panel 侧最高的是 1panel-agent,RES 约 116236 KB

  • 宝塔面板侧最高的是 YDService,其次是 BT-Panel,RES 约 45824 KB

  • site_total 在宝塔面板侧保持常驻,RES 约 16908 KB

4)小结

如果只看安装完成后的整机内存数据,两款面板在这一阶段的差距其实并不算大:

  • 1Panel 已用内存约 480MB

  • 宝塔面板已用内存约 495MB

也就是说,单从 free -m 的结果来看,两者在默认安装后的整体内存占用仍然处于比较接近的区间,本轮测试中宝塔面板甚至略高一些。

但如果进一步拆到面板相关进程来看,情况就不一样了。

以本次实测为例:

  • 1Panel 侧主要相关进程为 1panel-agent 和 1panel-core,合计约 132MB

  • 宝塔面板 侧主要相关进程为 BT-Panel、BT-Task 和 site_total,合计约 77MB

其中,site_total 为宝塔面板默认安装后启用的网站数据基础统计模块。由于本文测试的是默认安装状态下的实际占用,因此这里将其一并纳入面板相关进程统计。

换句话说,如果只按“默认安装后的面板相关进程”这一口径来看,宝塔面板在第二阶段的占用是低于 1Panel 的。不过如果从整机层面来看,两者此时的总已用内存差距还不算特别明显,因此这一阶段更适合得出的结论是:

宝塔面板的面板本体相关进程占用更低,但整机内存占用与 1Panel 仍处于接近区间。

同时也需要说明的是,为减少额外运行环境对本阶段结果的影响,1Panel 在安装过程中暂未启用 Docker。鉴于 Docker 在 1Panel 后续环境部署中基本属于强依赖组件,本文会在后续运行环境测试阶段再补充安装;因此,本阶段数据更适合用于比较两款面板在未引入 Docker 变量时的基础占用表现。

在完成面板基础占用测试后,接下来分别进入常用运行环境的安装阶段,以观察两款面板在更接近实际使用场景下的资源变化情况。

第三阶段:安装常用运行环境后的资源占用测试

和第二阶段不同,这一阶段不再只看面板本体,而是开始模拟更真实的建站使用路径。本次测试尽量选择建站场景中最常见的基础组合,包括 Web 服务、数据库服务以及 PHP 运行环境。

考虑到两款面板在默认推荐的软件形态上存在一定差异,本次测试遵循“功能接近、安装方式默认”的原则进行部署:

  • 1Panel:安装 OpenResty、MySQL、PHP

  • 宝塔面板:安装 Nginx、MySQL、PHP

其中,数据库统一选择 MySQL;PHP 两边均采用面板默认安装配置,保留默认扩展,不额外进行手动精简或裁剪,以尽量减少人为调整带来的干扰。

1)整体内存情况

在两边安装完 Web 服务、MySQL 和 PHP 后,先通过下面的命令查看整机内存状态:

free -m

实测结果如下:

面板

总内存

已用内存

空闲内存

buff/cache

可用内存

Swap

1Panel

1934 MB

1117 MB

103 MB

902 MB

817 MB

0 MB

宝塔面板

1934 MB

1072 MB

71 MB

979 MB

862 MB

1024 MB

从 free -m 的结果来看,安装完常用运行环境后,两边的整体资源占用都明显上升,说明这一阶段已经开始逼近真实建站环境。

其中:

  • 1Panel 已用内存约 1117MB

  • 宝塔面板 已用内存约 1072MB

也就是说,在当前这组环境下,宝塔面板侧的整机已用内存比 1Panel 少了约 45MB。

添加图片注释,不超过 140 字(可选)

2)主要进程占用情况

随后通过下面的命令查看当前内存占用最高的进程:

ps aux --sort=-%mem | head -20

从结果来看,到了这一阶段,两边内存占用的主体已经不再只是面板本身,而是逐渐转向数据库、Web 服务以及运行时环境。

1Panel 侧主要进程

进程

RSS

mysqld

436232 KB

1panel-agent

88776 KB

dockerd

82084 KB

YDService

63232 KB

containerd

43024 KB

php-fpm: master process

36576 KB

1panel-core

32784 KB

supervisord

30964 KB

从 1Panel 侧来看,当前占用最高的进程是:

  • mysqld:约 426MB

  • 1panel-agent:约 87MB

  • dockerd:约 80MB

  • containerd:约 42MB

  • php-fpm 主进程:约 36MB

可以看到,1Panel 在这一阶段的资源组成已经比较明确: 除了 MySQL 和 PHP 之外,Docker 运行时本身也成为了不可忽略的常驻开销。

宝塔面板侧主要进程

进程

RSS

mysqld

421900 KB

BT-Panel

123868 KB

YDService

77692 KB

nginx: worker process

41624 KB

python3.7

32268 KB

barad_agent

28072 KB

YDLive

26064 KB

exim4

17632 KB

BT-Task

16064 KB

site_total

13092 KB

nginx: master process

13172 KB

php-fpm: master process

11292 KB

宝塔面板这一侧,占用最高的同样是 MySQL:

  • mysqld:约 412MB

  • BT-Panel:约 121MB

  • nginx worker:约 41MB

  • BT-Task:约 16MB

  • site_total:约 13MB

  • php-fpm 主进程:约 11MB

可以看到,宝塔面板这一阶段没有引入 Docker 运行时本身的常驻开销,但面板主进程 BT-Panel 的占用明显高于第二阶段。

添加图片注释,不超过 140 字(可选)

3)实时状态补充观察

为了避免只看单次快照带来的误差,本阶段还通过 top 对系统稳定后的实时状态做了补充观察:

top

实测结果如下:

面板

已用内存

空闲内存

buff/cache

可用内存

进程总数

1Panel

1117.5 MB

102.8 MB

902.9 MB

817.4 MB

115

宝塔面板

1051.2 MB

93.0 MB

979.5 MB

883.8 MB

112

从 top 的结果来看,整体趋势与 free -m 基本一致:

  • 1Panel 已用内存略高

  • 宝塔面板已用内存略低

  • 宝塔面板当前可用内存更多一些

尤其在“available”这一项上:

  • 1Panel:约 817MB

  • 宝塔面板:约 884MB

这意味着在当前环境下,宝塔面板侧还能多保留出大约 60MB+ 的可用空间。

4)这一阶段说明什么

到了第三阶段,测试重点已经不再只是“面板本体谁更轻”,而是两边在完成常用环境部署之后,整套架构的实际占用表现。

从这组数据来看,可以得到几个比较清晰的结论:

第一,两边最大的内存消耗都来自 MySQL。 无论是 1Panel 还是宝塔面板,mysqld 都是当前占用最高的进程,而且数值非常接近,分别约为 426MB 和 412MB。这也说明,进入真实环境阶段后,数据库本身已经成为整机占用的核心因素之一。

第二,1Panel 侧引入了额外的 Docker 运行时开销。 在 1Panel 中,dockerd 和 containerd 合计已经带来了约 120MB 以上的常驻内存占用,再加上 containerd-shim 等相关进程,Docker 运行时本身的资源成本已经比较明显。这也是为什么第二阶段暂时不安装 Docker 是有意义的:只有这样,前后阶段的变化才更容易看清。

第三,宝塔面板在整机层面的占用略低于 1Panel。 虽然宝塔面板侧 BT-Panel 本身占用更高,但由于没有额外引入 Docker 运行时,在当前这组环境下,整机已用内存和可用内存都略优于 1Panel。

5)小结

如果说第二阶段更适合回答“谁的面板本体相关进程更轻”,那么第三阶段更适合回答的是:当真正装上常用建站环境后,两款面板的整体资源占用分别会到什么水平。

从本次实测结果来看,在安装 OpenResty / Nginx、MySQL 和 PHP 后:

  • 1Panel 整机已用内存约 1117MB

  • 宝塔面板 整机已用内存约 1072MB

在当前测试条件下,宝塔面板整体占用略低于 1Panel。差距不算特别夸张,但已经可以看出:当 1Panel 进入实际环境部署阶段后,Docker 运行时带来的额外成本会逐渐体现在整机资源占用上。

第四阶段:创建 WordPress 站点后的资源占用测试

在完成 Web 服务、MySQL 和 PHP 环境安装后,接下来分别在 1Panel 和宝塔面板中创建一个可正常访问的 WordPress 站点,以进一步观察两款面板在实际建站场景下的资源占用变化。

相比只安装运行环境,WordPress 会同时调用 Web 服务、PHP 与 MySQL,更接近真实的网站部署状态,因此这一阶段的结果也更有参考意义。

需要说明的是,两款面板在 WordPress 的部署方式上并不完全相同:本次测试中,1Panel 侧使用一键部署方式创建 WordPress 站点,而宝塔面板侧则采用手动上传源码的方式完成部署。因此,本阶段更适合用于观察两款面板在各自实际使用路径下,完成 WordPress 建站后的整体资源占用表现,而不强调部署步骤本身完全一致。

在站点创建完成并确认前台、后台均可正常访问后,先让系统静置数分钟,再分别记录整机内存状态与主要进程占用情况。随后再对站点首页和后台进行简单访问,以进一步观察在实际请求进入后,两款面板的资源变化表现。

1)整体内存情况

在两边 WordPress 站点均部署完成并可正常访问后,先通过下面的命令查看整机内存状态:

free -m

实测结果如下:

面板

总内存

已用内存

空闲内存

buff/cache

可用内存

Swap

1Panel

1934 MB

1246 MB

89 MB

818 MB

688 MB

0 MB

宝塔面板

1934 MB

1103 MB

81 MB

964 MB

831 MB

1024 MB

从整机结果来看,在 WordPress 部署完成后,两边内存占用都进一步上升,但差异已经比第三阶段更明显:

  • 1Panel 已用内存约 1246MB

  • 宝塔面板 已用内存约 1103MB

也就是说,在当前这组测试条件下,宝塔面板侧整机已用内存比 1Panel 少了约 143MB。

如果和第三阶段相比:

  • 1Panel:由 1117MB 增加到 1246MB,增量约 129MB

  • 宝塔面板:由 1072MB 增加到 1103MB,增量约 31MB

从这一点看,创建 WordPress 站点后,1Panel 侧的额外资源增长更明显,而宝塔面板侧变化相对更平缓。

2)主要进程占用情况

随后通过下面的命令查看当前内存占用最高的进程:

ps aux --sort=-%mem | head -20

1Panel 侧主要进程

进程

RSS

mysqld

477604 KB

1panel-agent

86548 KB

dockerd

64832 KB

apache2

61204 KB

YDService

58128 KB

apache2

57992 KB

apache2

53788 KB

apache2

51996 KB

apache2

47788 KB

apache2

42760 KB

containerd

40976 KB

1panel-core

27836 KB

这一阶段 1Panel 侧最明显的变化,是除了 MySQL 继续上升之外,WordPress 一键部署带起的 Web 相关进程明显增多。从进程列表可以看到,当前存在多组 apache2 -DFOREGROUND 进程,占用已经比较可观。

其中比较明显的部分包括:

  • mysqld:约 466MB

  • 1panel-agent:约 85MB

  • dockerd:约 63MB

  • 多个 apache2 进程:单个约 40MB - 60MB

  • containerd:约 40MB

也就是说,在 1Panel 侧,WordPress 建站完成后,内存压力已经不仅仅来自 MySQL 和 Docker,站点运行本身也开始带来更明显的增量。

宝塔面板侧主要进程

进程

RSS

mysqld

459704 KB

BT-Panel

125592 KB

YDService

70780 KB

nginx: worker process

40180 KB

nginx: worker process

38648 KB

barad_agent

28060 KB

YDLive

24824 KB

nginx: master process

20164 KB

exim4

18180 KB

BT-Task

16116 KB

site_total

13620 KB

php-fpm: master process

12572 KB

宝塔面板这一侧,WordPress 建站完成后,占用最高的仍然是:

  • mysqld:约 449MB

  • BT-Panel:约 123MB

  • nginx worker:约 39MB - 40MB

  • BT-Task:约 16MB

  • site_total:约 13MB

  • php-fpm 主进程:约 12MB

相比之下,宝塔面板侧站点运行后的新增进程结构更集中,没有像 1Panel 侧那样出现一组占用较高的 apache2 进程群。

3)实时状态补充观察

再结合 top 的实时状态来看:

top

实测结果如下:

面板

已用内存

空闲内存

buff/cache

可用内存

进程总数

1Panel

1245.6 MB

90.7 MB

818.5 MB

689.3 MB

128

宝塔面板

1083.4 MB

101.2 MB

964.6 MB

851.5 MB

112

从实时状态看,整体趋势与 free -m 基本一致,而且差距进一步被放大:

  • 1Panel 已用内存约 1246MB

  • 宝塔面板已用内存约 1083MB

同时在可用内存上:

  • 1Panel 约 689MB

  • 宝塔面板约 852MB

也就是说,在当前这组 WordPress 场景下,宝塔面板侧比 1Panel 多保留出了大约 160MB 左右的可用空间。

4)这一阶段说明什么

到了第四阶段,测试已经进入更接近真实使用的状态。此时对比的不再只是“环境装好了没有”,而是真正跑起一个 WordPress 站点后,两边整机资源会发生什么变化。

从这组数据来看,可以得到几个比较明确的观察:

第一,两边最大的资源消耗仍然来自 MySQL。 无论是 1Panel 还是宝塔面板,mysqld 仍然是当前最吃内存的进程,而且都已经来到 450MB+ 的量级。

第二,1Panel 侧在 WordPress 建站后,整机增量更明显。 和第三阶段相比,1Panel 的已用内存增加了约 129MB,而宝塔面板只增加了约 31MB。 这说明在当前测试路径下,WordPress 跑起来后,1Panel 侧的运行开销抬升更明显。

第三,1Panel 侧除了 Docker 运行时之外,还出现了一组占用较高的 Apache 相关进程。 这部分进程在当前数据里非常显眼,也使得 1Panel 侧的站点运行成本进一步上升。 而宝塔面板这边则主要还是以 Nginx、PHP-FPM、MySQL 为核心,没有出现额外一组体量较大的 Web 进程群。

5)小结

从本次实测来看,在 WordPress 站点创建完成并正常运行后:

  • 1Panel 整机已用内存约 1246MB

  • 宝塔面板 整机已用内存约 1103MB

在当前测试条件下,宝塔面板整体资源占用明显低于 1Panel,差距已经超过 100MB。而且从第三阶段到第四阶段的增量变化来看,宝塔面板的资源增长也相对更平稳。

需要说明的是,本阶段两边的 WordPress 部署路径并不完全相同:1Panel 使用一键部署,宝塔面板使用手动上传源码。因此,这一阶段更适合得出的结论是:

在各自常见部署方式下完成 WordPress 建站后,宝塔面板当前这组测试环境下的整体内存占用低于 1Panel。

第五阶段:统一为手动上传源码后,再次测试 WordPress 场景下的资源占用

在第四阶段中,1Panel 侧使用的是一键部署方式创建 WordPress 站点,而宝塔面板侧使用的是手动上传源码的方式完成部署。虽然这更接近两款面板各自常见的使用路径,但从测试严谨性的角度来看,两边部署方式并不完全一致,仍然可能引入额外变量。

因此,在第五阶段中,我们进一步补充了一轮测试:在 1Panel 中不再使用一键部署,而是改为手动上传 WordPress 源码、创建站点并完成配置,再次观察整机内存状态与主要进程占用变化。

这一阶段的目的,不是推翻第四阶段的结果,而是进一步回答一个更具体的问题:

如果把 WordPress 的部署方式尽量拉齐,1Panel 和宝塔面板在实际建站场景下的资源占用差异还会不会明显。

1)整体内存情况

在 1Panel 改为手动上传源码部署 WordPress 后,先通过下面的命令查看整机内存状态:

free -m

实测结果如下:

面板

总内存

已用内存

空闲内存

buff/cache

可用内存

Swap

1Panel(手动源码)

1934 MB

1253 MB

92 MB

806 MB

681 MB

0 MB

宝塔面板(手动源码)

1934 MB

1093 MB

93 MB

962 MB

841 MB

1024 MB

从整机结果来看,在两边都按更接近“手动上传源码”的方式完成 WordPress 部署后,差距依然存在,而且仍然比较明显:

  • 1Panel 已用内存约 1253MB

  • 宝塔面板 已用内存约 1093MB

也就是说,在这一轮更接近统一部署方式的测试下,宝塔面板侧整机已用内存依然比 1Panel 少了约 160MB。

如果和第四阶段相比:

  • 1Panel:由 1246MB 增加到 1253MB,变化约 +7MB

  • 宝塔面板:由 1103MB 降到 1093MB,变化约 -10MB

也就是说,把 1Panel 从一键部署改为手动源码部署后,整机内存占用并没有出现明显下降,整体趋势基本保持不变。

2)主要进程占用情况

随后通过下面的命令查看当前内存占用最高的进程:

ps aux --sort=-%mem | head -20

1Panel 侧主要进程

进程

RSS

mysqld

507776 KB

1panel-agent

91316 KB

dockerd

73672 KB

YDService

60196 KB

php-fpm: pool www

57416 KB

php-fpm: pool www

49760 KB

containerd

47412 KB

php-fpm: pool www

42080 KB

1panel-core

33560 KB

从 1Panel 侧来看,改为手动上传源码后,第四阶段里那组比较显眼的 apache2 进程已经不见了,说明前一阶段一键部署方式确实带来了额外的 Web 相关进程开销。

但与此同时,当前的主要占用仍然集中在这些部分:

  • mysqld:约 496MB

  • 1panel-agent:约 89MB

  • dockerd:约 72MB

  • containerd:约 46MB

  • 多个 php-fpm: pool www:单个约 40MB - 57MB

这说明即便去掉了一键部署带来的 Apache 进程群,1Panel 这一侧的压力依然主要来自:

  • MySQL

  • Docker 运行时

  • PHP-FPM 工作进程

  • 面板常驻进程本身

宝塔面板侧主要进程

进程

RSS

mysqld

459704 KB

BT-Panel

125592 KB

YDService

72064 KB

nginx: worker process

40180 KB

nginx: worker process

38648 KB

barad_agent

28084 KB

YDLive

24812 KB

nginx: master process

20164 KB

exim4

18180 KB

site_total

17592 KB

BT-Task

16116 KB

php-fpm: master process

12620 KB

宝塔面板这一侧的进程结构和第四阶段相比变化不大,整体仍然比较稳定:

  • mysqld:约 449MB

  • BT-Panel:约 123MB

  • nginx worker:约 38MB - 40MB

  • site_total:约 17MB

  • BT-Task:约 16MB

  • php-fpm 主进程:约 12MB

相比之下,宝塔面板侧在 WordPress 跑起来后,进程结构依然较集中,新增开销没有出现明显放大的情况。

3)实时状态补充观察

再结合 top 的实时状态来看:

top

实测结果如下:

面板

已用内存

空闲内存

buff/cache

可用内存

进程总数

1Panel(手动源码)

1271.4 MB

65.1 MB

815.9 MB

663.6 MB

125

宝塔面板(手动源码)

1086.0 MB

100.9 MB

962.4 MB

849.0 MB

109

添加图片注释,不超过 140 字(可选)

从实时状态看,整体趋势和 free -m 基本一致,而且差距进一步拉开:

  • 1Panel 已用内存约 1271MB

  • 宝塔面板已用内存约 1086MB

同时在可用内存上:

  • 1Panel 约 664MB

  • 宝塔面板约 849MB

也就是说,在当前这一轮更接近统一部署方式的 WordPress 场景下,宝塔面板侧仍然比 1Panel 多保留出了大约 180MB 左右的可用空间。

4)这一阶段说明什么

第五阶段的价值,在于它让第四阶段里最容易被质疑的变量——部署方式不一致——被进一步弱化了。

从这组数据来看,可以得到几个比较明确的观察:

第一,1Panel 改为手动上传源码后,第四阶段里那组 Apache 相关进程确实消失了。 这说明第四阶段中,一键部署方式确实带来了一部分额外的 Web 相关进程开销,这个质疑点是成立的。

第二,但即便去掉一键部署带来的 Apache 进程群,1Panel 的整体占用并没有明显下降。 整机已用内存仍然维持在 1250MB+ 的区间,和第四阶段相比只变化了很小一部分。

第三,两边差距依然存在,而且趋势没有反转。 在更接近统一部署方式之后,宝塔面板侧依然比 1Panel 保留了更多可用内存,整机已用内存也更低。

这意味着,第五阶段实际上给出的信号是:

第四阶段中观察到的差距,并不只是由“一键部署方式不同”造成的。 即使把 1Panel 改为手动上传源码,整体资源占用仍然高于宝塔面板,说明差异更多还是来自面板运行架构及其依赖方式本身,而不只是部署路径差异。

5)这一阶段的小结

从第五阶段的实测结果来看,在尽量拉齐 WordPress 部署方式后:

  • 1Panel 整机已用内存约 1253MB

  • 宝塔面板 整机已用内存约 1093MB

在当前测试条件下,宝塔面板整体资源占用依然明显低于 1Panel,差距仍然在 150MB 左右。 同时,从实时状态看,宝塔面板的可用内存也依然明显更多。

因此,第五阶段进一步验证了一个更稳妥的结论:

即使将 WordPress 部署方式尽量拉齐,宝塔面板在当前这组测试环境下的整体内存占用仍低于 1Panel。

总结:这次实测看下来,宝塔面板和 1Panel 的内存表现如何?

把前面五个阶段的测试结果放在一起看,这次对比大致可以分成两个层面来理解。

第一层,是面板本体的基础占用。 在第二阶段中,如果只统计默认安装后的面板相关进程,宝塔面板的占用要低于 1Panel。也就是说,单从面板本体和默认常驻模块来看,宝塔面板在基础占用上更轻一些。 不过如果只看整机总已用内存,两者在这一阶段的差距还不算特别大。

第二层,是进入真实使用场景后的整体占用。 从第三阶段开始,无论是安装常用运行环境,还是部署 WordPress 站点,差距都逐渐被拉开。尤其是在 1Panel 引入 Docker 运行时之后,这部分额外成本会比较持续地体现在整机内存占用上。 到了第四阶段和第五阶段,不管是按各自常见路径部署 WordPress,还是进一步把 1Panel 也改成手动上传源码的方式重新测试,宝塔面板这一侧的整体内存占用都仍然低于 1Panel。

换句话说,这次实测里可以看到一个比较清晰的趋势:

  • 只看面板本体,宝塔面板更轻

  • 看安装环境后的整体占用,宝塔面板也更低

  • 看 WordPress 建站后的实际场景,宝塔面板依然更省内存

  • 即使尽量拉齐部署方式,这个趋势也没有明显改变

当然,也需要说明的是,面板的选择本来就不只取决于内存占用。 不同产品在架构设计、部署路径、生态取向上本身就有差异,资源占用只是其中一个维度。 但如果你的服务器配置本身比较紧张,或者你更在意轻量环境下能尽可能多留出资源给网站和业务本身,那么从这次实测结果来看,宝塔面板在“内存占用”这个维度上的表现更有优势。

http://www.jsqmd.com/news/653140/

相关文章:

  • GB/T 13123-2026 竹胶合板检测
  • 免费论文AIGC检测使用指南:原理实操全攻略
  • 扫普通链接二维码打开小程序页面参数获取
  • 开发者面试内卷:突出重围的差异化战术
  • 实战解析 | Workbench多单元混合建模在静力学分析中的高效应用
  • 当AI学会害怕和好奇——V4认知与情绪
  • 五大Web GIS地图框架深度对比:Leaflet、OpenLayers、Mapbox、Cesium与ArcGIS for JavaScript
  • 多益网络笔试里的Python哲学题怎么答?‘Explicit is better than implicit’对新手程序员意味着什么?
  • Cursor Pro激活技术深度解析:3大核心技术实现与实战指南
  • 如何用Jasminum插件3分钟搞定中文文献管理:Zotero终极效率提升指南
  • 【JVM深度解析】第02篇:类加载机制深度解析
  • DelphiZXingQRCode 实战:从零到一构建企业级二维码生成模块
  • OpenClaw Windows 一键部署全流程|解压即装+环境免配置,龙虾AI智能体本地快速落地
  • openEuler 22.03下5分钟搞定Docker安装与镜像加速(华为云镜像源实测)
  • 避开Matlab新手必踩的坑:空值判断的正确姿势(为什么a==[]永远返回false)
  • Bring up
  • 家庭网络搭建指南:从光猫到路由器的全流程解析
  • 将小龙虾接入ClawBot教程,用微信就能出电影解说视频
  • vue 拖拽排序实现方案
  • 三堵墙逼出来的智慧——V3障碍与感知
  • 2026奇点大会最重磅签约项目曝光:3省医保局联合接入AI咨询结算系统,附可立即套用的DRG-AI交叉计费对照表
  • 如何在Obsidian中实现Excel表格的无缝编辑?终极Excel插件让笔记与数据完美融合
  • 面试官最爱问的哈希表实战:用C++手撕‘存在重复元素II’和‘字母异位词分组’
  • 从空调温控到智能驾驶:模糊推理在工业控制中的实战避坑指南
  • seL4微内核入门-代码下载运行及资料
  • 用 QClaw 做了一个工程合同风险审计技能,说说我的完整实践过程
  • PLDM实战指南:加速卡层级建模与传感器配置
  • 从零到一:基于VSCode与PlatformIO的ESP8266双框架(Arduino/RTOS_SDK)开发环境全攻略
  • 记一次项目完整实战测试
  • RV1106 在 4G 网络下基于 libdatachannel 构建低延迟 WebRTC 视频推流系统