2020-08-23 09:52发布
点击此处---> 群内免费提供SAP练习系统（在群公告中）加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）主要由于Fiori利用CDS视图... 显示全部
加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）
主要由于Fiori利用CDS视图进行的大量开发，我们在HANA中遇到了负载问题。
通常，系统具有大量可用的CPU和内存，但是有时（每天2-3次）用户将提交复杂的选择标准，从而消耗大量资源； 当他们没有迅速得到答复时，有时会重复重复提交具有相同（或非常相似）查询的搜索。 结合SADL框架并行提交许多查询，这意味着一个用户可以提交40多个高资源查询，并影响系统稳定性，而一个用户几乎消耗所有数据库资源。
理想情况下，我们将有一些参数（或工作负载类）会限制单次使用可以占用的资源。 但是我在当前设计中可以想到的唯一解决方案将意味着每个用户需要一个工作负载类。 但是，即使我们这样做，也无法解决多个并行提交高查询的用户。
为缓解此问题，我们提供了一个巡逻脚本来识别高数据库负载的情况，然后识别并杀死控制数据库的用户的连接。
有人在使用HANA中控制高负载的更标准方法吗？
预先感谢； 斯图尔特
您已经发现，工作负载管理是一个复杂的主题，因为您要处理动态情况以及目标冲突：
您想同时为每个语句提供最佳性能 避免系统因过多的请求而过载（这里有10个用户单击"狂野"并运行100个类似的查询，或者1000个只希望完成一个查询的用户，这并不重要）。
SPS 04 HANA提供了整套不同的功能，旨在解决问题的不同方面：
工作负载类和映射有助于对这些限制进行分组并将其分配给各个用户。 不必为每个用户创建单独的工作负载类，但是每个用户将具有一个映射。 这些映射可以过滤用户名，应用程序名称，应用程序组件等内容-如果应用程序提供了该信息（如许多SAP产品所做的那样）。
这样，就不那么困难了。 可以为BI用户或FIORI用户创建映射。
这些措施均不能直接解决您对超级点击用户的关注，因为HANA不会计算并检查是否存在来自同一用户的查询 同一用户已经在运行或尚未运行。 而且，实际上，这种工作量也可能有正当的理由（定期更新仪表板吗？）。
因此，您可以做的是 设置TOTAL STATEMENT THREAD LIMIT，以便其他工作负荷类仍然可以运行。
是否会降低每个用户的最大性能？ 当然可以。 但是，即使一种HANA使用者正在"狂野"运行，它也允许其他工作负载类运行。
如Mike所述，其他减少常规高资源查询影响的措施是：
尤其是最后一点可以 变得有争议，因为毕竟这是HANA，不需要进行任何预先计算。 实际上，在某些情况下，某些复杂的查询所需的时间比所需的时间长（例如，交互式显示平均需要10秒，而最多需要5（在案例中为95％）秒，则数据实际上不会更改 这么快。 考虑一下全球销售或库存KPI，其中数据提要大约每半天发送一次。 对于这种情况，缓存视图或预先计算的结果可能是一个很好的解决方案。 与往常一样，YMMV和"取决于"。
我希望能对您有所帮助。
干杯
Lars
也许也想为那些开发人员投资一些培训 通常会编写效率低下的脚本，从而导致大量资源消耗。 您似乎是在解决问题的症状，而不是问题的根本原因。
干杯，迈克
嗨，Stuart Havercroft ， 这在SAP HANA中可以通过启用内存跟踪来实现。 请查看设置内存 SQL语句的限制链接：https://help.sap.com/viewer/bed8c14f9f024763b0777aa72b5436f6/2.0.03/zh-CN/7b3e645df1d044cead4d208ed62e8ef7.html
我希望对您有所帮助 致谢 Deepak
我同意Mike； 这是希望提供大量数据集，满足用户需求的复杂计算，遍布各地的用户以及不知道他们在频繁提交时造成的负担的开发人员……我们可以一一解决这些问题； 但从根本上说，HANA应该能够保护自己。 我们的脚本做得很好，但是它填补了关键业务解决方案中应该成为标准的某些方面的空白
干杯。
感谢Lars;
以上内容符合我们的理解； 您的评论中有2条突出显示了我感觉缺少该功能的地方...
-"为BI用户或FIORI用户创建映射并不那么困难。" -"设置TOTAL STATEMENT THREAD LIMIT，以便其他工作负荷类仍然可以运行"
如果只阻塞一个组件/工作负载类而不是完全降低数据库速度，显然会更好； 但对于我们（我猜想大多数公司都是这样），我们不允许一个用户/很少用户能够耗尽资源（例如Fiori）并阻止大量用户使用该资源。 另一个问题是，在许多情况下，HANA都会尝试通过有限的线程来完成昂贵的查询，而不是终止会话以释放资源。另一个限制是您只能限制线程或内存，但不能同时限制两者（我知道SAP 目前正在努力解决这个问题。
如果存在可以按用户/语句散列/应用/等来设置总语句线程限制的功能，而无需创建单独的工作负载类，那将是一个很大的改进。
如果它对更广泛的受众有用，请使用我们的巡逻脚本；
-开始允许所有用户使用高资源（仅受全局参数限制）-被标识为在相当长的时间内消耗了很高资源的用户将失去连接以维护数据库稳定性-该用户将被允许 在一段时间内减少了资源，如果超出资源，连接将再次被杀死-如果用户继续创建高负载，则将他分配给"受限"工作负载类，并且总资源最少，情况将是 在将用户从该工作负荷类别中删除之前，先进行单独跟踪
谢谢，斯图尔特
嗨迪帕克； 我们知道这一点； 但这并不能解决单个查询不是问题的事实； 当查询被并行提交40次以上（由一个或有限数量的用户）时，查询就变成了数据库问题，您提到的参数和工作负载类都不能很好地解决这个问题。
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','http://www.easysap.com/data/attach/logo/logo.png', '推荐 wang628962 的问题《防止HANA负载过高-工作负载类缺少功能》','https://www.easysap.com/q-26997.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
您已经发现，工作负载管理是一个复杂的主题，因为您要处理动态情况以及目标冲突：
您想同时为每个语句提供最佳性能 避免系统因过多的请求而过载（这里有10个用户单击"狂野"并运行100个类似的查询，或者1000个只希望完成一个查询的用户，这并不重要）。
SPS 04 HANA提供了整套不同的功能，旨在解决问题的不同方面：
工作负载类和映射有助于对这些限制进行分组并将其分配给各个用户。 不必为每个用户创建单独的工作负载类，但是每个用户将具有一个映射。 这些映射可以过滤用户名，应用程序名称，应用程序组件等内容-如果应用程序提供了该信息（如许多SAP产品所做的那样）。
这样，就不那么困难了。 可以为BI用户或FIORI用户创建映射。
这些措施均不能直接解决您对超级点击用户的关注，因为HANA不会计算并检查是否存在来自同一用户的查询 同一用户已经在运行或尚未运行。 而且，实际上，这种工作量也可能有正当的理由（定期更新仪表板吗？）。
因此，您可以做的是 设置TOTAL STATEMENT THREAD LIMIT，以便其他工作负荷类仍然可以运行。
是否会降低每个用户的最大性能？ 当然可以。 但是，即使一种HANA使用者正在"狂野"运行，它也允许其他工作负载类运行。
如Mike所述，其他减少常规高资源查询影响的措施是：
尤其是最后一点可以 变得有争议，因为毕竟这是HANA，不需要进行任何预先计算。
实际上，在某些情况下，某些复杂的查询所需的时间比所需的时间长（例如，交互式显示平均需要10秒，而最多需要5（在案例中为95％）秒，则数据实际上不会更改 这么快。 考虑一下全球销售或库存KPI，其中数据提要大约每半天发送一次。
对于这种情况，缓存视图或预先计算的结果可能是一个很好的解决方案。
与往常一样，YMMV和"取决于"。
我希望能对您有所帮助。
干杯
Lars
也许也想为那些开发人员投资一些培训 通常会编写效率低下的脚本，从而导致大量资源消耗。 您似乎是在解决问题的症状，而不是问题的根本原因。
干杯，迈克
嗨，Stuart Havercroft ，
这在SAP HANA中可以通过启用内存跟踪来实现。
请查看设置内存 SQL语句的限制
链接：https://help.sap.com/viewer/bed8c14f9f024763b0777aa72b5436f6/2.0.03/zh-CN/7b3e645df1d044cead4d208ed62e8ef7.html
我希望对您有所帮助
致谢
Deepak
我同意Mike； 这是希望提供大量数据集，满足用户需求的复杂计算，遍布各地的用户以及不知道他们在频繁提交时造成的负担的开发人员……我们可以一一解决这些问题； 但从根本上说，HANA应该能够保护自己。 我们的脚本做得很好，但是它填补了关键业务解决方案中应该成为标准的某些方面的空白
干杯。
感谢Lars;
以上内容符合我们的理解； 您的评论中有2条突出显示了我感觉缺少该功能的地方...
-"为BI用户或FIORI用户创建映射并不那么困难。"
-"设置TOTAL STATEMENT THREAD LIMIT，以便其他工作负荷类仍然可以运行"
如果只阻塞一个组件/工作负载类而不是完全降低数据库速度，显然会更好； 但对于我们（我猜想大多数公司都是这样），我们不允许一个用户/很少用户能够耗尽资源（例如Fiori）并阻止大量用户使用该资源。 另一个问题是，在许多情况下，HANA都会尝试通过有限的线程来完成昂贵的查询，而不是终止会话以释放资源。另一个限制是您只能限制线程或内存，但不能同时限制两者（我知道SAP 目前正在努力解决这个问题。
如果存在可以按用户/语句散列/应用/等来设置总语句线程限制的功能，而无需创建单独的工作负载类，那将是一个很大的改进。
如果它对更广泛的受众有用，请使用我们的巡逻脚本；
-开始允许所有用户使用高资源（仅受全局参数限制）
-被标识为在相当长的时间内消耗了很高资源的用户将失去连接以维护数据库稳定性
-该用户将被允许 在一段时间内减少了资源，如果超出资源，连接将再次被杀死
-如果用户继续创建高负载，则将他分配给"受限"工作负载类，并且总资源最少，情况将是 在将用户从该工作负荷类别中删除之前，先进行单独跟踪
谢谢，斯图尔特
嗨迪帕克； 我们知道这一点； 但这并不能解决单个查询不是问题的事实； 当查询被并行提交40次以上（由一个或有限数量的用户）时，查询就变成了数据库问题，您提到的参数和工作负载类都不能很好地解决这个问题。
一周热门 更多>