SAP S/4 如何大幅提升性能

HANA（High Performance Analytic Appliance高性能分析设备）全内存数据库，2010年SAP 58亿美金收购Sybase发展而来，用列式数据存储、并行运算、内存计算等技术，极大地提高了数据处理效率，于2015年11月推出第一个ERP HANA版本SAP S/4 HANA 1511，实际使用下来在性能上相比之前版本确实大幅提升。

以下图为Forrester Wave企业内存数据库分析。

本文阐述版本SAP S/4 HANA1610，OP部署。

业务量剧增带来的问题

随着业务往电商方向蓬勃发展和系统的迭代，偶尔会出现系统宕机、卡顿。主要原因还是并发量大导致，SKU数量由最初的30万增加到500万，采购价格数量从200万增加到2000万，销售单数从30万单增加到770万，MRP区域行数从1500万增加到5亿，日志表当日增加量在500万条左右，同时分子公司增加十几家，主数据从MDM同步几百万条时间太长，年度调价的时候往往是几千万条价格更新，这个时候可能就会造成拥堵。

以下为SAP应用架构，优化点考虑网络、服务器、数据库、软件、日志、内存、实例等。

关于SAP S/4 性能优化最好的策略是在设计中解决，而非出现问题再解决。上线后要坚持优化并关注第二象限解决方案，因为很多稳定性问题长则需要半年时间分析解决。

主要优化事项：

• 代码持续优化，贵在坚持，不多说
• 在云上增加灾备环境供大数据平台获取数据，由原来5个小时降低到了1个小时，同时降低主库压力
• UPDATE压力过大，取消一些日志更新（刚开始是删CDHDR和CDPOS，发现删除数据跑不赢新增，所以在函数COND_A_WRITE_DOCUMENT改成不更新日志了，把UPDATE线程释放出来）
• 接口模式调整，Webservers改成RFC批量传输，然后解耦走Rabbit MQ消息队列，对于几千万的MQ，消息队列也会存在消费时间过长的情况，最后改成了批量直接走HANA数据库，把几千万数据先进HANA中间表，内部通过并发模式处理，每天消费1500万问题不大，到此基本上解决了数据同步问题
• 线程参数调优及工作负载分配（SM51查看，进程参数调优上监控了半年，结合实际情况优化了十几个版本，难点是是否有人真正长期坚持）
• 采购、客服、计算，接口实例分开，避免相互影响
• 代码优化要结合设计，当代码优化到一定程度，就是设计问题了，很多人觉得是代码效率问题，但是往往高手都是从设计角度去解决问题，比如在SQL取EKPO采购订单价格的时候，保存的时候更新EKPO含税和未税及总金额，你就不用在Inner join PRCD_ELEMENTS，效率极大提升
• 数据SAP同步到外部系统，同步改异步，降低IO并发，同时保障数据一致性
• 应用服务器新增了2个实例（04_01,05_01），分流并发业务
• 单表容量超过最大（约21亿），要做表分区，如果是CDPOS表满了会导致所有更新操作写入不了数据库，详细查询2154870 - How-To Understanding and defining SAP HANA Limitation
• 业务问题顾问牵头解决，代码问题研发牵头，整体解决顾问牵头，BASIS保障系统稳定性

监控+持续优化

等优化进入深水区，除了硬件、软件、操作系统的监控之外就要做业务侧的监控，如果平常业务没啥问题，偶尔出现问题，要通过监控策略把一些大报表，慢SQL，高并发的程序找出来优化，对应用服务器负载做到本质性的优化，而非头痛医头脚痛医脚，时不时还是出问题。

主要优化事项：

方式1：SAP Solution Management原生监控系统，可以做到邮件报警，对BAIsis级排查和监控问题帮助较大，主要从Host、Databases、Instances、Systems监控，除了监控还有一些架构部署、缺陷纠正、请求履行等管理功能

方式2：Zabbix+Grafana搭建监控系统，相对看起来比SLM直观，缺点是不能监控业务层级的报警，主要还是在操作系统，应用系统，数据库，网络

方式3：阿里云原生监控系统+企业微信报警机器人，类似Grafana，监控指标会多一点，感觉界面更直观

方式4：借用云厂商自带的监控系统，这个也是我们正在考虑的上云项目，借助云厂商的中间件工具监控更细的性能，比如响应时长，ABAP Dumps，Update等

方式5：业务类日志监控需要自己埋点，用BI平台输出，比如监控接口的出入负责情况，整体调用占比等等，然后针对性改善

提升HANA性能

HANA是内存计算、并行计算模式，对比分布式CAP原则，HANA则在Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）综合还不错，为保证计算效率HANA会尽可能调用可用CPU并行计算以缩短所需时间，所以在OLAP领域是HANA强项。

那么为什么在ERP领域还是会存在性能挑战呢，主要原因还是产品定位，ERP商务管理软件属于业务链条长数据逻辑复杂的场景，OLTP领域并发DML规模并未那么高。但是如果遇到高并发业务通信成本会飙升，高并发则会是一个挑战，这个时候最好还是从整体IT架构入手，采用模块外延更专业的应用系统承接，而不是所有业务都在ERP里面一勺烩。

主要优化事项：

• 互联网业务更多由专业系统承接，让专业的系统干专业的事，ERP聚焦本身的优势领域，如逐步上线了OA、WMS、TMS、OMS、CRM、SRM、票务、低代码等
• 持续监控ST22 Dump，该日志较大，注意不要Dump过大撑死日志盘带着系统宕机
• SM51 Trace 是否关闭，等于1表示开启，资源消耗还是很大
• HANA内存由1T增加到2T，可以运行SAPLWBABAP评估HANA内存目前业务是否够用

• 我们内存增加后把大报表计算下沉到HANA，采用CDS-AMDP技术将高频程序进行重构，使用AMDP 替换原有在ABAP层逻辑的处理
• HANA 1.0升级到2.0 利用灾备库可读（1.0不行），大数据平台获取数据由5个小时降低为1个小时，同时降低主库压力
• 大报表SQL制定备机获取数据，减少主库压力，平常备机基本上CPU利用率不到10%，充分利用起来
• 日志清理，很多是有标准程序可删除的，比如RSCDOK99删除修改记录，RSSNAPDL删除ST22，清理SM58处理异常数据
• 自定义表将大表数据同步到备份表，降低对大表的频繁访问；对配置表激活Buffer,提升I/O效率
• 做好中长期规划，系统扩展方式 Scale up和Scale out，参考1825774 - SAP Business Suite Powered by SAP HANA - Multi-Node Support

关于Notes

Notes可能是解决Bug，也可能是提升性能，也有可能是增强包，这是一件细致的活，注意一点就是不要认为打Note就没风险，一定要谨慎再谨慎，我们打了几次后出现系统崩溃，立即做了回滚。使用4年一共打了168个Notes在解决系统Bug和性能，有的Notes在测试环境验证了几个月才敢往生产系统传输，千万别拿生产环境试错，否则你的代价太高。以下图为168个Notes分类。

优化效果

经过一系列优化，最终解决了性能问题，单个接口效率最高提升56%，抗住了每天5000万次左右的事务性调用，同时前端用户不再卡顿，日常报表都可以查询，提升了整体的运营效率。

长期考虑

性能优化是一件长期的事，涵盖操作系统、硬件、数据库、软件、网络、业务逻辑等，更有可能牵扯IT规划，从业务层面上升到架构层面，持续监控优化，不断探索未知，因为你所能做的改变是你所已知的部分。