私有化部署项目管理工具越用越卡怎么办？怎么优化

私有化部署项目管理工具用了一两年后变慢，未必是服务器老了。数据量、附件、日志和定时任务一起增长，原来够用的配置会被慢慢吃满。中大型团队尤其常见：用户数没翻倍，历史需求、Bug 和附件却积累了几轮。先别急着加内存，先分清是哪一种卡，再按低风险顺序处理。若团队规模已明显扩张，可先对照容量与并发规划确认配置是否还在合理区间。

先分清“越用越卡”是哪一种卡

“卡”不是单一原因，而是一组症状。不同表现对应不同入口，混在一起处理容易做无用功。

如果四种都有，先处理全站慢和磁盘写满，它们会放大其他问题。

优化前先做三件事：备份、基线、回滚点

没有可恢复的备份，不要动数据库和附件目录。 禅道管理员可在后台 → 数据 → 备份执行备份；18.2 及之后版本入口调整为后台 → 系统设置 → 备份。Linux 一键安装包可停服务后备份整个 /opt/zbox 目录，数据库可用 mysqldump 导出。附件默认在 zentao/www/data 下，不要只备数据库。具体路径可参考禅道使用手册。

基线要在变更前记录：早高峰、午间、下班前各取一次首页、项目页、需求页的响应时间，同时记录 CPU、内存、磁盘使用率、MySQL 连接数和慢查询数量。没有基线，改完只能凭感觉判断。回滚点包括数据库快照、附件目录快照和配置文件副本。

第一层：先看服务器资源和磁盘

先用 top、free -m、iostat -x 1、df -h、df -i 看四件事：CPU 被谁占用、内存是否换页、磁盘 I/O 是否长期满载、磁盘空间和 inode 是否耗尽。

磁盘写满时，数据库可能无法写入，日志也无法落盘，表现往往不是“慢”，而是报错或卡死。禅道官方论坛有一个案例：Windows 一键部署版 21.5 使用后越来越卡，排查后确认机械硬盘读写太慢，建议更换固态硬盘。另一个案例中，一台 2 核 2 G 的云服务器在业务量上来后频繁 CPU 飙升，官方建议先确认是数据库、Apache 还是其他进程占用，再判断是否扩容。

如果 CPU 长期高于 80%、内存频繁换页、iowait 持续偏高，先记录，不要立刻加配置，继续往下看是谁造成的。

第二层：数据库往往是主要瓶颈

进入 MySQL 先执行 SHOW PROCESSLIST;，看是否有长时间运行的查询、锁等待或大量睡眠连接。再看慢查询日志：MySQL 官方文档说明，慢查询日志默认关闭，long_query_time 默认是 10 秒。这个阈值对项目管理系统太宽，排查时可临时调到 1 秒。

SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;

日志生成后，用 mysqldumpslow 汇总高频、高耗时 SQL，再用 EXPLAIN 看执行计划。重点看全表扫描、索引顺序不匹配、分页偏移过大。索引不是越多越好，新增索引会占空间并拖慢写入；联合索引要把区分度高、过滤性强的列放前面。

动作日志、附件记录、队列任务等表会持续变大。历史数据优先归档，不要直接删除；确需清理时先备份，并确认审计、外键和报表依赖。MySQL 官方文档提到，专用服务器上 InnoDB 缓冲池常可分配到物理内存的约 80%，但禅道常与 PHP、Web 服务同机部署，不能照搬。

第三层：附件、日志和备份文件

附件是私有化部署中最容易被忽略的增长点。大附件、历史版本、回收站文件都会占用磁盘。先看 zentao/www/data 的体积和文件数量，再决定是清理、迁移到独立数据盘，还是接入对象存储。

日志同样要管：Apache 或 Nginx 的 access log、PHP 错误日志、MySQL 慢查询日志、禅道自身的 tmp/logs。用 logrotate 做按天轮转、压缩和保留份数，比磁盘告警后手工删除更安全。备份文件也不要无限保留，tmp/backup 保留最近若干份，并定期做恢复演练。清理正在写入的日志前先轮转，不要直接 rm。

第四层：通知、定时任务和大导入

同步发信和同步 Webhook 会把外部服务的延迟带进保存操作。禅道支持把邮件和 Webhook 改为异步发送，异步任务再由后台 → 系统 → 定时执行。对中大型团队来说，一次需求变更可能触发大量通知，改成异步通常比升级硬件更直接。

度量、仪表盘、报表类定时任务如果执行频率过高，也会在后台持续占用数据库。可以先暂停非关键任务，或调整为每天一次，观察队列是否下降。大导入、大导出要分批执行，避免一次处理过多数据导致 PHP 执行超时或内存耗尽。官方支持曾建议排查导入卡顿时检查 memory_limit，但调整前要先确认服务器内存余量。

第五层：运行时与容量，什么时候该扩容

运行时先看 PHP 和 Web 服务：OPcache 是否开启、PHP-FPM 进程数是否合理、Apache 或 Nginx 的连接数是否够用、MySQL 连接数是否被耗尽。容器部署还要检查 CPU 和内存限制，很多时候不是宿主机不够，而是容器配额太小。

扩容的判定条件建议同时满足三条：已完成慢查询和日志清理，CPU 仍长期高于 70% 到 80%；内存持续吃紧或频繁换页；数据量和并发仍在增长。扩容顺序通常是先加内存，再换固态硬盘，最后加 CPU；单机纵向扩容之后，再考虑数据库与附件分离。不同部署形式对性能的影响，可参考部署形式与性能路线。不要用扩容掩盖慢查询。

推荐的优化顺序：从低风险到高风险

这张表的用法不是从上到下机械执行，而是每做一步就验证一次。低风险动作先做，能解决就不进入高风险动作。

改完怎么验证，避免白忙

验证要控制变量：同一时段、同一页面、同一并发量，对比优化前后的 P95 响应时间、慢查询数量、CPU 使用率、iowait 和磁盘占用。只刷新一次首页不算验证，至少观察 24 小时；涉及数据归档或参数调整的，观察 7 天。

同时记录变更日志：改了什么、为什么改、谁执行的、何时回滚。上线验收阶段的性能检查项，可以参考私有化部署项目管理工具上线验收5项检查。

长期不复发：把巡检做成例行工作

私有化部署项目管理工具的稳定运行，靠的是持续巡检，而不是一次大修。每日看磁盘、备份和队列；每周看慢查询 Top 10 和错误日志；每月看附件与日志增长；每季度做一次容量评估。版本升级前先备份，升级后重点验证登录、附件上传下载、报表和大列表页。

如果上线后经常出现“没人负责运维”的情况，可以对照私有化部署项目管理工具实施避坑指南补齐职责和巡检机制。

常见问题

只加索引会不会锁表？ 取决于数据库版本、表大小和执行方式。大表加索引可能长时间锁等待，应在低峰执行，先备份并评估在线 DDL 能力。

能不能在业务高峰做数据归档？ 不建议。归档会带来大量读写和锁竞争，尽量放在维护窗口，分批执行，并确认关联查询不会因历史数据缺失而报错。

容器部署的卡顿有什么不同？ 除了应用本身，还要看容器 CPU、内存限额、数据卷 I/O 和宿主机邻居影响。容器内看到的资源不一定等于实际可用资源。

升级版本能解决卡顿吗？ 新版本可能修复已知性能问题，但不能替代数据治理。升级前仍要备份、清理和验证，升级后按同一基线复测。

对私有化部署项目管理工具来说，稳妥的顺序是：先备份，再测量，再优化，最后验证。

参考资料

• 禅道官方手册：备份禅道，https://www.zentao.net/book/zentaopms/42.html
• 禅道官方论坛：Windows 一键部署版使用后越来越卡，https://www.zentao.net/thread/295866.html
• 禅道官方论坛：服务器 CPU 飙升卡死，https://www.zentao.net/thread/295218.html
• MySQL 8.0 Reference Manual：The Slow Query Log，https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html
• MySQL 8.0 Reference Manual：InnoDB Buffer Pool，https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html