| 一、问题现象 在观远BI使用过程中，当查看页面内容或更新数据集时，可能出现如下报错， 连接池等待请求过多（排队数量X），请稍后再试：
该问题通常表现为：多个卡片同时报错、报错集中在某一时间段、报错卡片所使用数据集多为同一个数据账户、过一会可能会自行恢复正常； 二、问题本质 该问题本质是数据账户连接池资源耗尽导致，在观远BI中，sql查询需要占用数据库连接，但连接池可用连接数量是有限的，当连接全部被占用时，新请求会进入等待队列，当排队数量超过阈值时，就会触发上述报错，因此该问题本质不在前端，大多数时候需要从数据库服务端排查原因。 三、排查链路 建议按照以下顺序进行排查：
卡片 → 数据集 → 数据账户 → 连接池监控 → 数据库 四、排查步骤 1)定位报错卡片 进入管理中心-运维管理-任务管理-任务明细中，找到失败任务对应卡片，
也可通过仪表板页面上报错弹窗定位报错卡片，需重点确认：是否多个卡片同时失败、报错时间是否集中、如果多个卡片同时异常，基本可以判断为资源问题。 2)通过卡片定位数据集 进入卡片详情页或编辑页，查看卡片所使用的数据集，通过点击数据集名称跳转到数据集详情页，
3）获取数据账户 进入数据集页面，点击模型结构查看数据集所属数据账户名称：
4）定位数据账户 进入数据账户页面，通过名称搜索，
在此之前也许多确认一些报错卡片是否都是指向同一个数据账户。 5)获取数据账户ID 打开浏览器开发者工具，以chrome为例，切换到Network，点击测试连接，查看请求Header中的Request URL，
从URL中可以获取accountId，该ID是连接池监控的唯一标识，复制该ID。若有开通元数据账户也可直接通过数据账户表进行查询。 6）查看连接池监控 进入管理中心-运维管理-资源监控页面中的Dashboards\GuandataDashboards\HikariCP下查看连接池监控，并通过复制的accountId筛选对应账户的连接池监控：
选择卡片频繁报错的时间区间，定位到具体监控信息：
五、监控内容分析 集合上述监控内容可以看到，在13点10分到13点15分： Active connections达到48 说明连接池已经被完全占满，无可用连接数，同时可以看到，connection time明显升高，这说明SQL执行时间变长、连接被长时间占用得不到释放。 六、连接池机制说明 观远BI数据账户连接连接数支持动态扩容。BI7.0及以上版本举例，初始最大连接数（可在数据账户侧进行配置）为32，当满足一定条件时会扩容至1.5倍，也就是32*1.5等于48，因此监控中看到最大连接数为48，当负载降低后 会自动缩容回32； 七、问题结论及解决方案 结合现象与监控数据可以得出，连接池连接数被耗尽是导致卡片报错的直接原因，连接时间升高说明SQL执行变慢，连接得不到及时释放，问题根因在数据库侧，需要排查数据库集群是否存在大量慢sql同时执行、或负载过高性能下降等问题； 除上述数据库侧的排查外， 若该数据账户本身设置的最大连接数较低或为默认值，可以考虑适当调高最大连接数； 卡片侧可以考虑在卡片内增加筛选条件或查询时多增加一些查询条件再进行查询，减小查询数据量； 数据集侧看是否能对数据集数据结构sql进一步优化，另外可以考虑开启开启调度状态，使用缓存，减轻数据库压力，提高查询效率。 |
