svn服务端内存占用过高需先诊断真实瓶颈：用svnlook tree测目录遍历耗时，查apache日志定位fsfs碎片或delta失败，运行iostat -x 1确认磁盘%util是否超95%；若成立，应关闭fsfs冗余校验、隔离大文件、升级ssd，而非盲目加内存。
SVN服务端内存占用过高，往往不是单一配置问题，而是I/O、连接模型、仓库结构与硬件资源共同作用的结果。关键不在于“杀进程”或盲目调大内存，而在于识别真实瓶颈并针对性干预——比如磁盘持续%util >95%，此时加内存只会让排队更久。
定位真实瓶颈：三步快速诊断
别猜，用工具确认：
-
查版本树开销：执行
time svnlook tree -r HEAD /path/to/repo | wc -l。若返回超5万行且耗时＞2秒，说明目录遍历已成性能热点，尤其影响svn list和检出首屏加载。 -
翻Apache日志：在
error_log中搜索Can’t open file（FSFS碎片严重）或delta calculation failed（二进制未启用增量压缩，每次提交写全量副本）。 -
盯磁盘I/O：运行
iostat -x 1，观察%util是否长期＞95% 且await＞50ms。一旦成立，说明磁盘已达吞吐极限，此时调高MaxRequestWorkers反而加剧请求堆积。
关闭FSFS冗余校验，换速度保体积
对含大量相似二进制文件（如PSD、DOCX、安装包）的仓库，禁用内容块共享可显著降低提交延迟：
- 编辑仓库
db/fsfs.conf，在[fsfs]段下添加：enable-rep-sharing = false - 新建仓库时直接指定：
svnadmin create --fs-type fsfs --config-file /tmp/svn-fast.conf /new/repo - 注意：该设置会使仓库体积增加10%～25%，但提交耗时可下降40%以上；旧仓库需通过
svnadmin dump/load迁移才生效。
Apache连接与内存参数精准控制
不是越多越好，而是够用且可控：
- 将
MaxRequestWorkers从默认250降至120，避免并发请求挤占系统资源； - 在
<location></location>块内显式声明：SVNPath /var/svn/repoSVNListParentPath offSVNReposName "Project Repo"（缺一不可，否则 mod_dav_svn 会反复扫描父目录）； - 添加内存防护：
LimitRequestBody 262144000（限制单次请求最大250MB，防大文件上传拖垮服务）； - 重启前务必执行
apachectl configtest验证语法，失败立即回退。
大文件隔离 + SSD硬件升级
把ISO、VM镜像等＞50MB文件踢出主仓库，是成本最低、见效最快的减负方式：
- 新建专用仓库：
svnadmin create /var/svn/large-bin - 配置其
db/fsfs.conf：[fsfs]max-files-per-dir = 1000log-addressing = true - 在Apache中新增
<location></location>映射，独立托管； - 将主仓库迁移到SSD存储——实测可提升提交/检出速度2～3倍，尤其对历史查询类操作（如
svn log -l 100）改善明显。
不复杂但容易忽略：很多团队卡在“以为是内存不够”，实际是磁盘在喊救命。先看 iostat，再动配置，效果立判。
