2026 年 IT 资产与工单系统服务器租用：真正的峰值来自采集窗口

一家公司的 IT 部门反映，系统每天上午十点前后特别卡，月底尤其明显。查了一遍账号，后台只有三十几个在用用户，一天新开的工单也就几十条，按任何常理都不该卡成那样。真正的问题在另一条线上：每天十点是采集窗口，几百台终端的代理同时上报整机清单，SNMP 扫描正在扫三个网段的交换机和打印机，网络发现任务也在同一时间往库里塞新设备。这三件事叠在同一分钟，写入量是平时人工操作的几十倍，而值班的人偏偏就在这一分钟打开浏览器开单、上传截图。系统自己制造的负载，比人制造的负载大得多，而且它每天准点来一次。

这类系统的选型因此不能按"多少人用"来算。用户数决定的是并发连接数和页面渲染次数，那是稳定且可预测的；真正把实例打满的是后台那条采集链路，它周期性、突发、且完全不受人控制。谁忽略了这一点，就会在上线三个月后遇到"白天卡、夜里空"的怪现象，然后花很长时间去找一个根本不存在的前端性能问题。

卡在上午十点，是因为定时任务比人先到岗

要理解这个错位，先看两套时间线怎么撞在一起。人的时间线是跟随工作日的：九点前后陆续登录，十点开始进入提交高峰，午休回落，下午再有一个小高峰。采集的时间线是按照"上一次执行完多久再跑"来排的：代理装好之后按固定间隔回连，扫描任务按管理员设的周期触发，邮件收集器按自动动作的频率去收信。这两条时间线在设计的时候没有任何机制保证它们互相避让，于是它们大概率会在某个时刻重合，而且一旦重合就会持续重合下去——因为两边都是固定周期。

更麻烦的是月底。月底往往是资产盘点、保修到期核对、月度报表导出的集中期，也是补丁推送后代理集中回连的时期。三种周期在月末叠加，表现在用户端就是"月底特别卡"，但很多人会把它误判成"工单太多了"，然后去做工单归档，做完了下个月照样卡。

所以第一步不是加配置，而是把负载来源分开看清楚：哪些是人的操作产生的，哪些是系统自己排出来的。分开之后会发现，人那部分几乎从来不是瓶颈。

资产台账和工单流水是两种写法，压力不在同一个地方

IT 资产与工单系统的数据结构天然分成两块。第一块是资产台账，也就是 CMDB 那一侧：计算机、服务器、显示器、打印机、网络设备、软件、耗材，还包括它们之间的关系，比如一台机器归哪个部门、用了哪个许可证、保修到哪天。这块数据的特点是写少但每次写很重——一台终端一次上报可能涉及几十张关联表的增删改，还要跑导入规则去判断"这是新设备还是已有设备的更新"。

第二块是工单流水：工单主表、跟进、任务、解决方案、附件、审批、满意度、以及围绕 SLA/OLA 的计时字段。这块数据的特点是写多读多、每次写很轻、但总量增长快——一条跟进就是一行，一次状态变更可能连带写日志、写历史、触发通知进队列。

两种写法的资源消耗完全不同。资产台账吃的是 CPU 和事务一致性，因为它要在规则匹配、去重、关系更新上花时间；工单流水吃的是磁盘容量、IOPS 和连接数，因为它行数多、附件多、还要留痕。把它们放在同一套配置思路下去评估，结论必然跑偏。很多实例的真实情况是：数据库体积被工单流水和附件目录撑大，而 CPU 峰值被采集窗口打满，两个瓶颈来源不同、时间不同、解决手段也不同。

代理上报、SNMP 扫描、网络发现，这三件事的资源消耗各不相同

采集这条链路上有三种不同的活儿，先把它们分开看。

代理上报是终端上装一个采集代理，按配置的间隔把本机硬件、软件、用户信息打包发给服务端。以 GLPI Agent 为例，它的配置项 delaytime 表示首次联系服务端的延迟上限，单位是秒，默认值是 3600；实际延迟会在该值的一半到该值之间随机取一个数。这个随机区间很关键——它天然起到分散作用。但要注意，文档同时说明该指令只用于首次联系，之后会被服务端在响应中下发的值覆盖。也就是说，真正的上报节奏最终由服务端决定，客户端的随机化只是开局的那一层保护。另一个配置项 lazy 表示不在下次计划时间之前联系服务端，只在前台运行时生效。理解这两点，就能明白为什么"改了客户端配置但上报还是扎堆"——因为节奏的控制权在服务端。

SNMP 扫描面向的是装不了代理的设备：交换机、路由器、防火墙、打印机。它从一个发起点按 IP 段逐个查询，把序列号、系统信息、端口、耗材这些数据取回来。GLPI Agent 的 Toolbox 插件在 1.6 版本之后承担了这部分能力，支持按 IP 范围、按凭证、按计划任务来组织扫描。官方文档明确给了两个可调参数：threads 表示同时查询多少台远程设备，调高能缩短任务总时长，但文档同时强调这个值必须合理，合理值取决于分配给采集端的资源；timeout 是判定一台设备无响应的等待秒数，局域网内响应快的设备可以设到 1 秒，跨远端网络或设备本身负载高时要调高，涉及 SSH 认证时建议 10 秒左右。这两个参数直接决定了扫描任务是"几分钟扫完"还是"挂在那里慢慢等"——等待期间连接和进程是被占住的。

网络发现是按 IP 段去探测"这一段里到底有什么设备"，按业务规则把发现的设备归类成计算机、打印机、交换机等，然后决定要不要入库。它和 SNMP 扫描是关联的：发现负责"找到"，SNMP 清单负责"取回厂商通过 SNMP 协议开放的数据"（序列号、系统版本、耗材等）。发现任务的耗时和 IP 段大小直接相关，官方资料也提醒过，网段设得越大，采集端完成任务需要的时间越长。

三者的共同点是：都不受人控制，都在固定时刻发生，且都会在短时间制造大量数据库写入。区别在于消耗的资源侧重点不同——代理上报吃 Web 层和 PHP 进程（因为要收 HTTP 请求、解析、入库），SNMP 扫描和网络发现吃采集端的并发与超时等待，以及随后的批量插入。

采集窗口不是设个时间就完了：错峰、分批、切范围

既然峰值来自这三条链路在同一时刻叠加，那么削峰的思路就是把它们拆开。具体有四个可操作的维度。

第一是错峰。把代理上报的默认窗口、SNMP 扫描的触发时间、网络发现的触发时间，三者彼此错开，而不是都设在整点。很多实例之所以在整点卡，只是因为管理员在配计划任务时习惯性地填了整点。错开半小时就能让峰值下降一大截，代价是数据新鲜度略有差异——对于资产台账这种容忍小时级延迟的场景，这点代价几乎可以忽略。

第二是分批。不要指望几百台终端在几分钟内全部上报完。按部门、按网段、按楼层把设备分组，每组给不同的上报窗口。服务端下发节奏、客户端随机延迟、以及分组窗口这三层可以叠加使用，把"一分钟几百个请求"摊成"二十分钟里每个时段十几个请求"。

第三是切范围。SNMP 扫描和网络发现按 VLAN 或按网段拆成多个任务，每个任务只扫自己那一段。官方资料也建议，如果 VLAN 很多或者想在不同任务之间切分扫描，就按企业策略把 IP 范围分开。这样做的好处除了削峰，还有可诊断性：某一段扫不动的时候，能立刻定位是哪个任务、哪个网段、哪个凭证出了问题，而不是面对一个大任务超时。

第四是与工单高峰错开。这是最容易被忽略的一条。采集窗口要避开值班人员开单、上传附件、导出报表的时段，尤其要避开月末那几天的上午。反过来，报表与导出也要避开采集窗口。两边各自让一步，比任何一边加配置都有效。

工单侧涨得最快的是附件、历史表和留痕，不是工单主表

很多人盯着工单主表的行数看容量，这是看错了地方。主表一行就是一条工单，一天几十条，一年下来量级有限。真正涨得快的是三类东西。

第一类是附件目录。用户报障时习惯直接截图、贴日志、塞配置文件，一个几 MB 的附件在存储上没什么，但乘以工单量再乘以月份，它就是实例上增长最稳的目录。第三方部署经验里也反复提到，涨得最多的是附件目录和清单数据，规划时要按增长而不是按初始大小来算。附件目录的增长还有个特点：它涨上去基本不会自己掉下来，除非主动清理孤立文档。

第二类是历史与留痕表。每一次字段变更、状态流转、指派调整，系统都会留一条记录。这是审计和追溯要的，砍不得，但它让写入放大：一次看起来只是"改了个状态"的操作，背后可能是主表一行的更新加上历史表一行的插入，再加上日志、队列里一条待发通知。写放大的结果是数据库体积和 IOPS 压力同步上升，而这两样恰恰是最难在线扩容的。

第三类是会话与日志表。登录会话如果不清理会一直堆积，最终拖慢登录；操作日志在活跃实例上增长更快。官方的自动动作清单里就包含了清理过期会话、轮转旧日志、清理孤立文档、清理未关联资产的清单提交文件、清理超过 12 小时的临时清单文件、清理没有安装记录的软件版本等任务。这些任务存在本身说明了一件事：这个系统的数据是会长脏、会长胖的，清理不是可选项而是日常运维的一部分。

所以容量规划要按"附件目录 + 历史留痕 + 会话日志"这三块的增速去算，而不是按工单条数。且这三块的增速必须在你自己的实例上观测一段时间才能确定，别人的数字不能直接搬。

SLA 计时对时钟和调度敏感，漂移和漏跑都会直接变成责任事故

资产台账晚几个小时更新，最坏的结果是台账不准；SLA 计时出问题的结果是责任算错。这是两类完全不同的后果，也决定了为什么 SLA 这条链路在选型时要单独对待。

SLA 与 OLA 的计时、升级通知、自动关闭，都挂在自动动作（crontask）上。官方资料列得很清楚：slaticket 负责 SLA 临近截止的升级，olaticket 负责内部 OLA 的升级，closeticket 负责把已解决超过一定工作时长的工单自动关闭，alertnotclosed 负责对长期未关闭的工单发提醒。这些任务的执行有两个前提：时钟准、调度不漏。

关于调度，官方文档给了明确的推荐做法：自动动作可以运行在 GLPI 模式或 CLI 模式，GLPI 模式下动作在用户浏览系统时被顺带触发，CLI 模式下则由外部计划任务调用 front/cron.php 在自己的会话里执行；官方建议生产环境用 CLI 模式，并且建议让外部计划任务每分钟调用一次，以保证到点的动作尽快被执行。这一点非常关键——如果停留在 GLPI 模式，周末没人登录就没有任何动作运行，邮件不收、SLA 不动、告警不发，周一早上第一个打开系统的人会"替系统把积压的活一次性干完"，然后所有人都会说系统慢。这跟采集窗口造成的卡顿在现象上很像，但根因完全不同，处理方式也不同。

关于时钟，SLA 是按绝对时间点算截止的，服务器时钟一旦漂移，所有截止时刻就整体偏移。更隐蔽的是时区和夏令时的处理：跨分支机构的运维团队常常分布在不同时区，如果服务端时区、数据库时区、用户所在时区三者没有统一口径，报表里的"响应时长"就会和工单页面显示的数值对不上，而这类不一致往往要等到争议发生才会被发现。因此选型时要把"能否稳定对时、能否自主配置时区、能否看到计划任务的实际执行记录"作为机房与操作系统的考察项，而不是当成默认成立的前提。

还有一层是任务重叠。当某个动作的单次执行时间超过它的执行间隔，就会出现上一轮还没跑完下一轮又起来的情况。社区资料在讲邮件收集时特别提到过这一点：处理大量积压邮件时容易发生重叠，此时要么临时拉长间隔，要么手工处理积压。对 SLA 类任务来说，重叠的后果是同一条工单被重复计算、重复通知，看起来像是"通知发了两遍"，实际是调度失控的信号。

数据库同机、分盘、分机，三种摆法的代价不一样

摆放方式决定了你能把瓶颈隔离到什么程度。三种做法各有代价。

同机同盘：Web、PHP、数据库、附件目录全在一台机器的同一块盘上。好处是部署简单、成本低、备份就是一个目录快照；代价是四类资源互相抢——采集窗口的 CPU 峰值会拖慢数据库，数据库的大查询会拖慢页面，备份的磁盘 IO 会拖慢所有东西，附件增长会把系统盘撑满导致整机不可用。这个方案适合设备数量少、采集频率低、且能接受短暂卡顿的场景，但必须做好一件事：附件目录和临时目录要单独分区或至少单独配额，避免把系统盘写满。

同机分盘：同一台机器上，系统盘与数据盘分开，数据库数据目录和附件目录放数据盘，条件允许时附件目录再单独一块。这是性价比最高的中间方案。它解决的是最要命的那个问题——IO 争抢和容量失控——但没有解决 CPU 争抢：采集窗口来的时候，PHP 进程和数据库进程还是在同一组核心上抢。如果采集任务本身不重（设备几十台、扫描段很少），这个方案的瓶颈通常不会出现。

分机部署：数据库单独一台，Web 与应用一台，采集集中点再考虑是否独立。代价是网络延迟进入关键路径——每一次页面请求都可能带着多次数据库往返，如果两台机器之间的网络质量不稳定，页面响应时间会被放大；同时运维复杂度上升，备份要跨机协调，故障排查要同时看两边。好处是隔离彻底：采集把应用机 CPU 打满的时候，数据库还有自己的资源；报表把数据库压住的时候，应用机还能接单。

怎么选取决于你的采集规模。设备几十台、扫描段两三个，同机分盘足够；设备几百台、扫描段十几个、还要跑周期性网络发现，就应该认真考虑把数据库分出去。这个分界线没有通用数字，因为它取决于单次采集的事务量、并发数、以及你对卡顿的容忍度，只能实测。

备份窗口要单独排，单表恢复能力要先演练出来

备份这件事在 IT 资产与工单系统上有两个特殊性，导致它不能照搬一般 Web 系统的做法。

第一个特殊性是备份窗口必须和采集窗口错开。采集窗口里数据库正在批量写入，此时做一致性备份，要么备份出来的数据处于事务中间态，要么备份过程本身把 IO 占满导致采集和在线操作一起变慢。正确做法是把备份排在采集完成、清理任务跑完之后的一个稳定时段，并且留出足够余量——因为随着资产增长，采集窗口会变长，备份耗时也会变长，两个都在长，余量要按增长后的量算。

第二个特殊性是你需要的往往不是整库恢复，而是单表恢复。真实故障长这样：一条错误的导入规则把几百台设备的归属改错了，或者一次误操作删掉了一批资产关系，或者某个插件升级后写坏了配置表。这时的诉求是"把那几张表恢复到昨天"，而不是"整个实例回到昨天"——整库回滚意味着昨天之后所有人开的工单、传的附件全部丢失，代价太大。但单表恢复是有前提的：你得先确认自己的备份方式支持按表恢复，并且真的演练过一次。很多团队是出事之后才发现备份只有整库快照。

演练要覆盖三件事：一是恢复出来的库能不能正常启动并通过应用自检；二是恢复后附件目录和数据库记录是否对得上（附件是按路径存的，数据库里有引用，只恢复一边会造成大量断链）；三是恢复耗时是多少——这个值必须实测，因为它直接决定你的 RTO 能不能被业务接受。演练结果要写进运维文档，而不是留在当时操作的人脑子里。

报表和导出最容易在月底拖垮整个实例

报表的问题是它把前面所有瓶颈串在一起触发。一次导出要做的事情是：大范围扫描工单表、联查历史与关联表、在内存里组织结果、再序列化成文件写出。它同时吃 CPU、内存、数据库 IO 和磁盘 IO，而且通常是长事务，期间会占住连接和锁资源。

为什么偏偏是月底？因为月底同时满足三个条件：资产采集刚跑完（数据变多）、管理层要月度统计（并发导出）、以及所有人都想赶在结账前把工单结掉（在线操作量上升）。三个条件叠在一起，报表的耗时会被放大，而放大的耗时又会让更多人重试，重试再放大负载，形成正反馈。

可行的做法有四条：把固定报表排到夜间或午休低峰生成，白天只读生成好的结果；限制同时执行导出的人数；给导出加上行数上限，超出的走离线文件而不是在线下载；把报表类查询和采集窗口在时间上彻底错开。另外要注意，官方在新版本里做过搜索与仪表盘的性能改进（例如延迟关联的分页、优化计数、消除仪表盘渲染时的重复查询），这类改进能减轻但不会消除问题，因为导出本身的数据量是业务决定的。

PHP 与数据库版本是硬门槛，扩容前先确认能升得动

这一条不是性能问题，是能不能继续用的问题。以 GLPI 为例，官方公布的 12 版本系统要求是 PHP 8.3 及以上，数据库为 MariaDB 10.11 及以上或 MySQL 8.0 及以上；官方同时说明支持的 Web 服务器包括 Apache 2、Nginx、lighttpd、IIS，并提供官方 Docker 镜像。作为对比，官方在 12 版本的说明中提到 GLPI 10 运行于 PHP 7.4+ 与 MariaDB 10.2+，因此多数从 10 升级的实例需要先升 PHP 和数据库。

这个门槛对租服务器的人意味着三件事。第一，选操作系统镜像时要确认能装到要求的 PHP 版本，太老的发行版可能要自己编译或用第三方源，这会带来后续维护负担。第二，数据库的版本要一次选到位，跨大版本升级数据库是有风险的，最好在初次部署时就选符合要求且仍在维护期的版本。第三，插件兼容性要一起看——官方明确指出插件必须适配到对应版本才能用，社区或自研插件要找维护方确认，并且要在测试环境验证。

关于 PHP 内存和硬件配置，网上各类部署资料给出的建议并不一致（例如有资料提到 PHP 内存下限在 128 MB 量级、清单导入需要更多余量，也有资料给出 2 核 4 GB 起、并发用户多时上到 8 GB 以上的说法）。这些都不是官方口径，且彼此冲突，因此不能作为选型依据，只能当作量级参考；真实值必须按你的资产规模、采集并发和工单量实测。同样的道理适用于 PHP 必备扩展清单——不同资料列出的扩展项略有出入，部署时应以官方安装检测或官方文档给出的清单为准。

配置怎么定：CPU 看采集并发，内存看 PHP 与数据库，磁盘看 IOPS 与附件增长

把前面的分析收拢成配置决策，思路是这样的。

CPU：不由用户数决定，由采集并发决定。要估的是采集窗口里同时有多少个 PHP 进程在处理上报、同时有多少个扫描任务在跑。设备几十台、扫描段两三个的实例，峰值并发有限；设备几百台且要跑周期性网络发现的实例，CPU 需要在峰值时还有余量给在线开单。评估办法是在自己环境里观察采集时段的进程数与负载，而不是按用户数套公式。

内存：主要给两处——PHP 进程池（采集时同时活跃多少进程，每进程多少内存）和数据库缓冲（热数据集有多大，历史表和工单表能否放进缓冲）。内存不足的表现不是"慢"，而是开始用交换空间，一旦走到这一步，响应时间是断崖式下降。判断依据是采集时段和测试环境下的实测占用。

系统盘与数据盘：系统盘给操作系统、Web 服务、应用代码和日志，容量要求不高但要有余量，因为日志没清理会撑满；数据盘给数据库和附件目录，容量要按附件与历史留痕的增速乘以保留周期来算。两者分开是底线要求，理由前面说过：防止附件和临时文件把系统盘写满。

IOPS：这是最容易被忽略、也最贵的指标。数据库在写入密集的采集窗口、以及读取密集的报表时段，吃的都是随机 IO。机械盘在这两个时段会明显吃力，固态盘是更稳妥的选择。需要多少 IOPS 同样要实测，观测指标是采集时段和报表时段的磁盘队列与响应延迟。

带宽与独立 IP：这类系统对带宽的要求通常不高——页面以文本为主，采集上报是内网或分支到总部的流量，只有附件上传下载和邮件收集涉及持续外连。真正的点是出口的稳定性与独立 IP：邮件收集器要连外部邮箱，如果出口 IP 因为共享而被列入黑名单，工单邮件就收不进来，而且这个故障是静默的，用户只会觉得"我发了邮件没人理"。因此独立 IP 在这里的价值不在带宽大小，而在可追溯、可控、不被邻居连累。

机房要看时钟与计划任务的可靠性、磁盘 IOPS、快照与备份策略

落到机房选择，前面所有分析指向四个考察项。

第一项是时钟与计划任务的可靠性。SLA 计时、自动升级、自动关闭全靠准点和按时执行。要问的是：宿主机是否提供稳定的时间同步源；虚拟化环境下时钟是否会发生漂移（这在虚拟机上比物理机更常见）；如果计划任务因为宿主机迁移或暂停而漏跑，有没有监控手段能发现。漏跑的代价在前面讲过——邮件不收、SLA 不动、告警不发，而且都是静默的。

第二项是磁盘 IOPS 与存储形态。要问清给的是机械盘还是固态盘、是本地盘还是网络存储、IOPS 有没有明确承诺或至少可实测的基准。对这类系统来说，容量通常不是瓶颈，IOPS 才是。如果只能拿到网络存储，就要额外关注网络路径的稳定性，因为数据库每一次往返都要走网络。

第三项是快照与备份。要分清快照和备份不是一回事：快照通常在同一存储上，快但和存储同命运；备份应该落在不同介质或不同位置。要问的是：有没有可用的快照能力、快照的保留策略与回滚耗时是多少、能否自助做异地备份、备份时是否影响在线 IO。这些问题决定了你前面设计的备份窗口能不能真正落地。

第四项是节点位置。如果终端和分支机构主要在境内，节点放在境内更合适，采集上报和页面访问的延迟都会更短；如果团队或资产分布在境外，就需要考虑是否有中国香港或海外节点可选，以及跨境链路的质量如何。这里要提醒的是，采集上报的流量特征是可预测的、周期性的，它对延迟不敏感但对失败重试敏感——如果链路经常丢包，大量终端会反复重试，反而制造更大的峰值。所以跨境部署时要重点看丢包与抖动，而不只是带宽标称值。

成本构成里，真正会涨的是存储与备份，不是 CPU

把成本拆开看，构成大致是这几块：服务器租用（CPU、内存、系统盘）、数据盘或存储容量、独立 IP 与带宽、快照与备份服务、以及操作系统或数据库需要商业授权时的许可费用（若全部使用开源组件则此项为零）。

其中会随时间持续上涨的是后两块半：数据盘容量随附件与历史留痕增长，备份占用的空间随数据总量增长，快照保留期越长占用越大。CPU 和内存则相对稳定——除非资产规模跨了量级，否则峰值并发不会突变。这个结构决定了预算应该按"存储增长曲线"来排，而不是按"明年会多多少人"来排。

价格性质上需要说明的是：服务器租用、机柜托管、带宽接入、独立 IP、快照与备份的具体价格，都要以服务商官网的实时信息或咨询确认为准，本文不给出任何价格数字。不同机房、不同机型、不同带宽与 IP 数量的组合差异很大，且会随市场调整。做预算时更可靠的做法是：先确定配置清单和资源增长曲线，再拿这份清单去问价，而不是先定预算再倒推配置。

上线前必查的几项：从自动动作模式到临时文件清理

把常见的坑列成一份可执行的上线检查单，按顺序核一遍。

• 自动动作是否已切到 CLI 模式。这是最重要的一条。停留在 GLPI 模式意味着没有用户访问时一切停摆。切到 CLI 之后，还要在系统计划任务里配置好调用，并在界面上确认"上次运行"时间在持续更新。
• 采集窗口是否真的错开了。把代理上报、SNMP 扫描、网络发现、邮件收集、报表生成、全库备份六件事的触发时间列在一张表里，确认任意两件都不在同一分钟扎堆。这张表要在资产规模变化后重新检查。
• PHP 与数据库版本是否满足当前版本要求，插件是否都有对应兼容版本。升级前在测试环境用生产数据的副本验证一遍。
• 时区与时钟是否统一。确认操作系统时区、数据库时区、应用配置的时区三者一致，并确认有稳定的时间同步。
• 附件目录与临时目录是否单独分区或有配额，是否有监控阈值。这两处是最容易把系统盘写满的地方。
• 清理类自动动作是否已启用。包括清理过期会话、轮转旧日志、清理孤立文档、清理未关联资产的清单文件、清理过期临时清单文件等，确认它们真的在跑而不是处于禁用状态。
• 单点附件大小与单次收信数量是否设了上限。没有上限意味着一个异常大附件或一次邮件风暴就能把实例拖住。
• 恢复演练是否做过一次，特别是单表恢复和附件与数据库的一致性校验，并记录实测耗时。

这份清单里没有一项是需要额外花钱的，但它们决定了实例会不会在三个月后变成"白天卡、夜里空"的状态。

资产规模上限、采集频率与云上部署：几个被反复问到的问题

问：几百台设备算不算多，要不要上独立数据库？
没有通用阈值。是否要分机取决于单次采集的事务量和并发数，而不是设备台数——同样是三百台设备，只做代理上报和同时跑三个网段的网络发现，压力完全不同。判断依据是在你的环境里观测采集时段的 CPU、磁盘队列和数据库写入等待，观测到瓶颈再决定。

问：采集频率设成多少合适？
要分开看。资产台账一般不需要实时，按天级甚至更长都可以；保修和合同类的核对也是低频需求。真正需要高频的是工单侧的动作——SLA 计时、邮件收集、通知队列，这些按分钟级更合适。官方文档对邮件收集器默认频率的描述在不同资料里并不一致（有写每分钟，也有写每十分钟并限制单次收取封数），因此应以你实例中自动动作页面显示的配置为准，再按实际邮件量调整。

问：能不能直接跑在云主机上？
可以，官方也提供了 Docker 镜像。要注意两点：一是计划任务的可靠性依赖宿主机，虚拟化环境下时钟漂移和任务暂停需要额外监控；二是存储的 IOPS 通常和机型规格绑定，选型时要单独确认，不能只看 CPU 和内存。另外，若使用官方镜像自带的定时任务机制，要先确认它是否已经在工作，避免自己再加一层造成重复调度。

问：资产台账能不能直接对接监控系统？
这类系统普遍提供 REST 接口，也支持通过 LDAP 同步用户与组织，对接是可行的。但对接本身会带来额外的写入与查询压力，尤其是双向同步时容易产生循环。建议把对接的调用频率也纳入采集窗口的排布里统一考虑。

问：为什么加了配置还是卡？
先确认到底卡在哪一类负载上。如果是采集窗口卡，加 CPU 和内存有效；如果是备份时段卡，加内存没用，要改备份窗口和 IO；如果是月末导出卡，加配置只能缓解，要靠排程和限制并发解决。把负载来源分清楚，比盲目升级配置有效得多。

关于 IT 资产与工单系统采集负载取舍的几条判断线

第一条，削峰优先于扩容。把三条采集链路错开、把扫描范围切小、把上报分批，这些都是零成本的，而且效果通常比加一档配置更明显。只有在错峰已经做到位、峰值依然存在的情况下，才应该考虑加资源。

第二条，资产台账的新鲜度可以让位于在线响应速度。台账晚两小时更新几乎不影响任何决策，而值班的人在开单时卡住会直接影响故障处理。取舍时把台账采集排到低峰，把工作高峰留给人的操作。

第三条，SLA 相关的自动动作优先级高于采集。采集慢一点只是数据旧，SLA 漏跑会导致升级通知不发、责任算错。资源紧张时，优先保证计时、升级、邮件收集这几条链路的执行，采集可以让路。

第四条，数据库是否分机，取决于采集规模而不是用户数。分机的代价是网络延迟进入关键路径和运维复杂度上升，收益是彻底隔离 CPU 与 IO。设备量小、扫描段少时不必分；采集任务重且周期性明显时才分。

第五条，存储规划按增长曲线算，不按当前大小算。附件目录和历史留痕是单调增长的，规划时要把保留周期乘进去，并且预留出备份占用的空间。容量是这里面最容易"一年后出问题"的一项。

第六条，备份的价值等于演练过的恢复能力，不等于备份任务是否成功。一个从未演练过的备份，在真正出事时等于没有备份。演练要覆盖单表恢复、附件一致性、以及实测耗时。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

IT 资产与工单系统部署的口径与来源说明

本文只讨论 IT 资产与工单系统（以 GLPI 这类 ITSM/ITAM 系统为分析对象）的负载来源、采集窗口安排、数据增长与选型思路，不比较任何具体 ITSM 产品或服务商的优劣，不给出任何未经核实的资产规模上限或性能承诺，不指向任何具体客户，也不构成性能或可用性承诺。所有容量数字均需在自有资产规模下实测确定。

文中涉及的确定性事实均来自公开资料：GLPI 12 的系统要求为 PHP 8.3 及以上、MariaDB 10.11 及以上或 MySQL 8.0 及以上，支持 Apache 2、Nginx、lighttpd、IIS，并提供官方 Docker 镜像（来源：GLPI 官方发布说明与官方更新日志）；GLPI 10 运行于 PHP 7.4+ 与 MariaDB 10.2+（来源：GLPI 官方 12 版本说明）；GLPI Agent 的 delaytime 默认 3600 秒、实际延迟在该值一半到该值之间随机、仅用于首次联系且之后由服务端下发值覆盖，lazy 仅在前台运行时生效（来源：GLPI Agent 官方文档）；Toolbox 远程采集任务的 threads 为同时查询的远程设备数、其值取决于分配给采集端的资源，timeout 在快速局域网可设 1 秒、涉及 SSH 时建议 10 秒左右（来源：GLPI 官方文章）；自动动作支持 GLPI 与 CLI 两种模式、官方建议生产环境使用 CLI 模式并由外部计划任务每分钟调用 front/cron.php，slaticket、olaticket、closeticket、alertnotclosed 等动作的职责，以及清理会话、轮转日志、清理孤立文档、清理过期临时清单文件等动作的存在（来源：GLPI 官方帮助中心文档）。

文中明确标注为"需实测"的项目包括：采集窗口的 CPU 与内存占用、扫描任务的并发数与超时取值、附件与历史表的增长速度、单表恢复耗时、报表导出的并发上限、所需 IOPS 与带宽。这些数字随资产规模、采集频率、工单量与保留策略变化，没有通用取值，必须由使用者在自己的环境中观测确定。文中提到的 PHP 内存下限、CPU 与内存起步规格等均出自第三方部署资料而非官方口径，且各家说法不一致，仅作量级参考，不作为选型依据。

文中出现的场景（如"上午十点卡顿""月底导出变慢"）是为说明负载结构而构造的通用示例，不指向任何具体客户、单位或已发生的事件。价格相关内容一律以官网实时报价或咨询确认为准，本文不提供具体价格数字。部署前请以所使用软件版本的官方文档为最高依据，并在测试环境中用生产数据的副本完成验证。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体的机型、机柜、带宽与报价，仍要以官方实时信息或咨询确认为准。