第1章 ERP系统性能瓶颈分析

第1章：ERP系统性能瓶颈分析

大家好，我是老张。在ERP这个行当摸爬滚打了十几年，我见过太多系统慢到让人抓狂的场景。今天咱们就来聊聊，ERP系统到底卡在哪儿，以及怎么用工具把它揪出来。

说实话，ERP系统的性能问题，从来不是单一环节的事。它就像一条流水线，任何一个环节堵了，整条线都得停。我个人习惯从四个维度去拆解：数据库、应用服务器、网络、前端。咱们一个一个说。

1.1 数据库瓶颈：最常背锅的“老大哥”

数据库往往是第一个被怀疑的对象。嗯，很多时候它确实该背这个锅。

常见问题：

慢查询：这是最常见的。比如报表查询、月末结算，一个SQL跑几分钟甚至几十分钟。我在项目中遇到过，一个销售订单汇总的SQL，因为没走索引，硬生生跑了45分钟。
锁竞争：ERP里大量并发操作，行锁、表锁一多，事务就得排队。你想想看，大家都在抢同一张订单表，能不卡吗？
连接池耗尽：应用服务器开了200个连接，数据库只能处理150个，剩下的50个请求就只能干等着。
磁盘I/O瓶颈：数据量大了，磁盘读写跟不上。尤其是机械硬盘，随机读写性能很差。

核心观点：数据库优化，80%的工作都在SQL和索引上。别一上来就想着换硬件，先看看你的SQL写得对不对。

怎么用工具定位？

我个人习惯用Prometheus + Grafana搭一套监控。具体做法：

# 用mysqld_exporter采集MySQL指标
# 关键指标：慢查询数量、锁等待时间、连接数、QPS/TPS

# Prometheus配置示例
scrape_configs:
  - job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']

# Grafana里建个看板，重点关注：
# - 慢查询趋势图（超过1秒的SQL数量）
# - 锁等待时间分布
# - 活跃连接数 vs 最大连接数

我曾经帮一个客户排查，发现他们的慢查询集中在凌晨2点的数据归档任务。后来加了索引，把全表扫描改成分批处理，归档时间从2小时降到了15分钟。

小技巧：在Grafana里设置告警，比如慢查询超过10个/分钟就发钉钉通知。别等用户投诉了才去查。

1.2 应用服务器瓶颈：别让CPU空转

应用服务器的问题，说白了就是“活儿干不过来”。

常见问题：

线程池配置不当：线程太多，上下文切换开销大；线程太少，请求排队。我见过一个项目，Tomcat线程池设了1000个，结果CPU全花在切换上了。
内存泄漏：Java应用里，对象创建了不释放，GC越来越频繁，最后Full GC把应用卡死。
代码逻辑低效：比如在循环里查数据库，或者用for循环处理上万条数据。
JVM参数没调优：堆大小、GC策略，这些默认参数往往不适合ERP这种高并发场景。

怎么用工具定位？

Prometheus的jmx_exporter可以采集JVM指标。我建议重点关注：

# 关键JVM指标
# - heap_used：堆内存使用率，超过80%就要警惕
# - gc_time：GC暂停时间，超过1秒就是大问题
# - thread_count：活跃线程数，看是否异常增长

# Grafana看板示例
# 左边放CPU使用率、内存使用率
# 右边放GC次数和暂停时间
# 下面放线程池活跃度

我记得有一次，客户说系统每天下午3点准时卡顿。我一看监控，发现那个时间点有个定时任务在跑，把CPU吃满了。后来把任务挪到凌晨，问题就解决了。你看，有时候问题就这么简单。

避坑指南：我曾经遇到过，应用服务器内存一直涨，但GC就是不回收。查了半天，发现是ThreadLocal没清理，导致对象一直被引用。嗯，这种问题最难查，建议用jmap dump堆内存，然后用MAT分析。

1.3 网络瓶颈：看不见的“隐形杀手”

网络问题往往被忽略，但它确实能拖慢整个系统。

常见问题：

带宽不足：尤其是分公司访问总部ERP，上传下载大文件时，网络直接堵死。
延迟高：跨地域部署，一次请求来回几百毫秒，累积起来就很可观。
丢包重传：网络不稳定，TCP不断重传，性能直线下降。
DNS解析慢：每次请求都要解析域名，虽然单次影响不大，但量大了也受不了。

怎么用工具定位？

Prometheus的blackbox_exporter可以监控网络连通性和延迟。我建议：

# 配置blackbox_exporter
modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]

# 在Grafana里看：
# - 各分公司的网络延迟（超过200ms标黄，超过500ms标红）
# - 丢包率（超过1%就要处理）
# - 带宽使用率

你想想看，如果网络延迟从10ms涨到100ms，一个页面加载需要10次请求，那用户就要多等1秒。这1秒，可能就是用户骂娘的开始。

小技巧：用ping和traceroute先做个快速排查。如果延迟高，看看是不是路由跳数太多，或者中间有设备在做流量整形。

1.4 前端瓶颈：用户感知的“最后一公里”

前端慢，用户直接骂。虽然很多时候问题不在前端，但背锅的往往是它。

常见问题：

资源加载慢：JS、CSS、图片没压缩，或者没做缓存。一个页面加载几兆的资源，能不慢吗？
DOM操作频繁：比如表格渲染时，每行数据都触发一次重排。数据量一大，浏览器直接卡死。
API调用过多：一个页面发几十个请求，每个请求都要等后端响应。我见过一个采购订单页面，加载时调了30多个接口。
浏览器兼容性问题：有些功能在Chrome上跑得飞快，到了IE就卡成PPT。

怎么用工具定位？

前端监控可以用Prometheus的pushgateway，或者直接用Grafana的浏览器性能插件。我建议：

# 用Performance API采集前端指标
window.performance.timing

# 关键指标：
# - domContentLoadedEventEnd - navigationStart：DOM加载时间
# - loadEventEnd - navigationStart：页面完全加载时间
# - 资源加载时间（JS、CSS、图片）

# 在Grafana里展示：
# - 页面加载时间分布（P50、P95、P99）
# - 各资源加载耗时
# - API调用次数和耗时

我记得有一次，用户说某个报表页面打开要10秒。我一看，发现页面加载了5MB的图片，而且没做懒加载。后来改成按需加载，首屏时间降到了2秒。

核心观点：前端优化，优先做“首屏加载”。用户等不了你全部加载完，先让用户看到东西，其他的慢慢来。

1.5 总结：四维一体，缺一不可

好了，四个维度都聊完了。说白了，ERP性能优化就是个“木桶效应”——哪个板子短，水就从哪儿漏。你不能只盯着数据库，也不能只优化前端。

我个人习惯的做法是：

先搭监控：用Prometheus + Grafana把四个维度的指标都采集起来。
找短板：看哪个维度的指标最差，先处理它。
持续迭代：优化完一个维度，再看下一个。别想着一口吃成胖子。

嗯，这一章就到这里。下一章咱们会深入聊聊数据库层面的具体优化技巧，包括索引设计、SQL改写、分库分表这些实战内容。到时候见。

课后思考：你的ERP系统里，哪个维度的问题最突出？试着用Prometheus搭一套监控，看看数据怎么说。

📚 课程目录