熊大 - 原来HANA DB抓连接数也很容易

熊大 - 原来HANA DB抓连接数也很容易

StrongBear这家小型规模的公司，有一部分业务是SAP基于HANA Cloud的云业务。其运行状态也一直稳如老狗。HANA Cloud在Multi-tenancy方面的支持基本上是不遗余力。

光头强强总一直忙于公司的外部业务拓展，甚至也有基于PostgreSQL(后边简称PG)自研的计划，并且开展了一段时间了，也有自己的内部版本了。只是一直没有往外公布而已。偷偷给客户用上，提供满意的服务质量，也很“香”。将整个业务线分成：PostgreSQL和非PostgreSQL两大块。

背景:

话说HANA Cloud那边，偶尔也出现一些小问题。比如，最近某天，一个客户抱怨，”我的HANA tenant DB突然连不上了。“ 但是呢有一部分现有的业务的连接又都正常。

熊大直接上场，登上HANA Cloud实例，先是简单看了下这个实例的vCPU核的数量。嗯，比较小：只有2个。那么支撑的并发连接数量就不会太多了。再看看版本，已经是2024的Q1了。

熊大回忆起，Q1的那个版本推出一个新功能，就是可以从LIMIT相关系统视图里能准确的得到实例最终允许的最大连接数。如：

SELECT * FROM M_SYSTEM_LIMITS WHERE name LIKE '%SESSIONS' 

CATEGORY|NAME                      |VALUE|TYPE   |UNIT|COMMENT                                 |
--------+--------------------------+-----+-------+----+----------------------------------------+
SERVICE |MAXIMUM_NUMBER_OF_SESSIONS|1000 |INTEGER|    |Maximum number of concurrent connections|

并且SAP做了基于cpu资源的连接限制，即每个vCPU的核，最多支持500个连接。最终最大连接数与vCPU是500的倍量关系。

在Q1以前的版本，可能就只是返回给你一个65536，那样给出的值只是理论值，参考意义不大。

再次查一下当时的真实的连接消耗情况：

SELECT count(*) FROM m_connections WHERE connection_id > 0

COUNT(*)|
--------+
     997|

熊大一看这个结果，就大概猜到后边的大概原因了，客户的连接数过多。可能是他的应用确实需要很多连接。于是他又用了下边的连接作了进一步分析：

SELECT user_name, count(*) FROM (SELECT * from m_connections WHERE connection_id > 0) AS CONNS GROUP BY user_name ORDER BY 2 DESC;

USER_NAME                                                    |COUNT(*)|
-------------------------------------------------------------+--------+
4A8DFA518D714xxxxxxxxxxxxxxx2FC7_72NBEKZ3W7N5SJSG04OA5JWGM_RT|     903|
A369D8Exxxxxxxxxxxxxx434178CB832_2OCMJ35UJ78ALMGY2385NIDMB_RT|       9|
7021F8BA8xxxxxxxxxx04F036385ED07_1PXHGQDU2ZY6RYU6UVV1BI0EB_RT|       8|
_SYS_STATISTICS                                              |       6|
7021F8xxxxxxxxxx8504F036385ED07_49EQHE6X6G2QEOUPUNNQ7IOST_RT |       5|
_SAP_METRICS_EXPORTER                                        |       3|
SYS                                                          |       3|
xxxxxxx                                                      |       3|
4C6972xxxxxxxxxxxxBA1996E0D6A7BE_C3XU8HO86BIVAMZS7NK8KQ457_RT|       2|
..................

这么一看，就基本清楚了。用户：4A8DFA518D714xxxxxxxxxxxxxxx2FC7_72NBEKZ3W7N5SJSG04OA5JWGM_RT消耗的连接过多。系统一旦把1000个连接全部用完，就无法再得到新的连接了。（注：HANA Cloud为多租户生成的用户名就是很长，比如这种：4A8DFA518D714xxxxxxxxxxxxxxx2FC7_72NBEKZ3W7N5SJSG04OA5JWGM_RT，所以，一般情况下，也没有必要去记这么长的用户名了）

于是熊大赶紧联系客户，告诉他们有两种选择：

1. 救急：允许的情况下，重启一下所有相关应用 （安全重启，不影响现有业务）
   但是，估计要不了多久，还是会将连接数用完。
   与此同时，需要分析业务系统的连接使用情况，将各个连接池的数量进行核定、限制好，使总数在可控范围以内。
2. 加大vCPU数量，比如原来的是2个，申请弄成4个。那样就可以得到最大2000个连接了。当然，这也意味着要多花一些钱。

经过沟通，客户愿意花几天时间进行业务代码相关配置的调整，再看看效果。在有希望从应用角度来解决的前提下，没有必要升级硬件资源。

熊二这时走过来问熊大，“老大，那些新特性，如果不知道的话，是不是意味着要走一些弯路？”

“是的，对哪种数据库而言，都是一样的，当更新至新版本以后，你就得及时了解新版本的一些新功能。这样，你能及时的使用新功能去解决一些实际问题。所以，经常读读官方文档， 是非常有必要的，毕竟它永远是一手资料。“

至于客户那边如何调整自己的业务代码及相关配置，且听以后分解。

总结：

对于整个系统连接数的监控，基本上都是有必要的。并且，给出一个告警阈值，才更合理。以上边的小案例为例，1000个连接，如果到了900就告警，那么熊大就有机会直接与客户沟通，给出更及时合理的建议。

同样的案例，换到PostgreSQL，一样的有效。