TG咨询虚拟桌面资源池容量不足，常见表现不只有“机器跑满”：早间集中登录变慢、应用切换卡顿、桌面偶发断连，都可能来自不同瓶颈。重新做虚拟化桌面资源池容量规划时，应先按真实峰值测量，再分别核算以下六项指标，而不是只增加服务器数量。
先确定测量口径
选取覆盖正常工作日和高峰时段的监控数据，最好连续观察一至两周；同时记录登录量、活动会话数、应用类型和维护任务。不要只看日均值，重点比较高峰时的平均值与 p95、p99 等高分位数据。若早间登录集中，应单独记录启动风暴，避免它被全天平均值掩盖。
容量重算的六项指标
1. 并发会话与单机密度
统计“已连接会话”而非仅统计已分配桌面数，并区分轻办公、视频会议、图形应用等负载。测出典型用户和重负载用户各自的资源消耗后，以最紧张的资源项反推单台主机可承载会话数。不同应用混跑时，不宜直接用轻办公用户的平均值套算全部用户。
2. CPU 使用率与调度等待
同时看宿主机 CPU 使用率、虚拟机 vCPU 利用率，以及虚拟化平台提供的 CPU 等待或争用指标。若使用 VMware Horizon 等桌面方案，应结合底层 ESXi 的主机与虚拟机监控数据判断；单看 CPU 百分比，可能漏掉虚拟机排队。视频会议、实时音频和大型表格并行运行时，通常需要比静态办公更宽的 CPU 余量。
3. 内存实际压力
查看宿主机可用内存、虚拟机工作集、内存回收或交换活动。桌面配置的内存总和不等于实际峰值需求，但持续发生交换、回收或应用内存不足时，也不能以“平均占用不高”作为扩容依据。可按用户类型抽样，记录登录后、应用高峰和闲置时的差异，再确定每类桌面的内存配置。
4. 存储容量、延迟与 IOPS
容量要核算桌面镜像、用户数据、快照和增长空间；性能则看读写 IOPS、吞吐量及延迟。登录风暴会集中触发系统盘读取，补丁部署或批量重启也可能形成写入高峰。观察存储端和主机端的延迟曲线，并按实际应用可接受的响应时间设目标，不采用脱离阵列类型、缓存和负载的统一阈值。
5. 网络带宽与丢包
统计桌面协议流量的峰值带宽、链路利用率、丢包和往返延迟；视频、音频和高分辨率多屏会提高带宽需求。还要核对用户接入链路、数据中心上联与东西向流量，避免只扩服务器网卡，却忽略交换链路已接近饱和。
6. 故障余量与维护窗口
按“失去一台主机后，其余主机能否接住会话”做 N+1 校验，并把升级、补丁维护期间下线的主机计入可用容量。日常利用率刚好装满的资源池，遇到故障或维护就可能触发重连和性能下降。预留比例应结合故障域大小、恢复时间和业务要求确定，不能把预留空间当成可长期销售的容量。
把测量结果变成扩容方案
按用户类别和时段导出会话、CPU、内存、存储与网络监控数据，统一时间范围。
找出高峰期最先触顶的指标，并检查它是否与卡顿、登录延迟或断连同时发生。
以实测的单机承载量计算所需主机数，再扣除故障及维护时不可用的主机，复核剩余容量。
先处理明显的配置或分布问题，例如桌面集中落在少数主机、存储热点集中；仍不足时，再按瓶颈扩展计算、内存、存储或网络。
扩容后在相同高峰条件下复测，确认体验改善且故障余量仍满足要求。
例如，CAD 桌面和普通文档桌面混用一个资源池时，应分别测量图形负载和轻办公负载，再决定是否分组调度或配置图形加速；不能仅按总用户数平均分摊资源。最终的虚拟化桌面资源池容量规划应能回答：峰值有多少活动会话、哪项资源先到瓶颈、失去一台主机后是否仍可运行。
常见问题
只看宿主机 CPU 利用率够吗？
不够。还要看 CPU 等待、会话体验和应用负载，利用率不高也可能存在调度争用或存储瓶颈。
用户数等于并发数吗？
不等于。应统计高峰活动会话，并关注集中登录、轮班交接等会造成短时峰值的场景。
容量不足时应该先加服务器吗？
先定位瓶颈。若问题在存储延迟或网络丢包，单纯增加计算节点通常不能解决；若 CPU 或内存确实先饱和，再据实扩展。
多久复测一次？
资源池扩容、桌面镜像更新、用户规模或主要应用变化后应复测；日常则持续观察峰值趋势，及时调整虚拟化桌面资源池容量规划。