我目前正在开发一个Java应用程序，用于比较2个不同数据库中存在的表数据。
我正在使用连接池和线程池执行器服务。我将连接数和线程数配置为可配置的，因此试图找到最佳的连接数和所需的最佳线程数。
我知道获得最佳数量的最佳方法是尝试不同的数量，但是我的问题是我应该考虑哪些因素或如何计算连接/线程所需的数量。
通常有3000个要比较的表，并且表的列表/模式可以预先使用，并且暂时假设每个表中的记录数是几百个（因此，我不需要查询一个表以上）。
当前，我的应用程序为每个表生成一个线程（从线程池），并且它与2个不同的数据库建立2个不同的db连接（现在依次），一旦检索到数据，同一线程将调用一个方法来比较数据。
我这里有几个问题，说N不。芯数，M为最大数。数据库可以连接的数据库连接数量
答案 0 :(得分：1)
N不是。芯数，M为最大数。数据库可以连接的数据库连接数量
- 如果我的线程数多于N，这对我的用例有用吗？如果是，怎么办？
- 这里的限制因素是什么-核数或数。连接？
- 线程数多于M有用吗？
是的，产生更多线程而不是内核会有所帮助，因为在任何给定时间，某些线程将被阻塞以进行I / O，这时其他线程可以进行处理。
从以上可以看出，限制因素当然不是核心数。但是，连接数也可能不是限制因素。当然，您不能超过连接数，但是从达到磁盘吞吐量（在数据库服务器端）或网络拥塞可能会成为问题之前，您可能会发现甚至无法达到该上限。 p>
如果您确保a）从连接池中获得连接，b）读取所有数据，c）将连接释放回，则线程数超过最大连接数可能会带来一些小的好处。池，然后d）对数据进行比较。那是因为当一个线程在比较数据时，另一个线程可以使用该连接来读取数据。但是，比较数据听起来很简单并且很快速，因此好处不会那么大：您的线程将相当快地完成数据比较，之后它将希望从池中获取另一个连接，然后如果所有连接都在使用中，它将被阻止。
话虽如此，我希望您知道以下事实：现有的工具，甚至是免费工具，都可以为您做这些比较。搜索“ SQL比较”。 （我知道，这是一个错误的称呼，这些工具不比较SQL，它们比较数据库，并且碰巧使用SQL查询它们比较的数据库；我没有给出名称，这些工具的创建者做了。 ）
答案 1 :(得分：0)
您问题的简单答案是“取决于”；即没有简单的答案或魔术公式。
您执行的每个数据库查询都包含涉及客户端计算的步骤，需要服务器上的计算和磁盘I / O的步骤以及涉及通过网络传输查询和结果的步骤。对于任何给定的查询，这些步骤都以特定的顺序发生。执行查询的实时时间是执行每个步骤所花费的时间，一个接一个地进行。
让我们假设（出于争论的目的）查询是独立的；也就是说，一个查询不会锁定另一个查询所依赖的资源。
现在，如果您的工作量足够轻（取决于查询本身和客户端线程的数量），则每个查询的各个步骤将消耗越来越多的可用（相关）资源（CPU，I / O）带宽）。您可以继续增加客户端线程的数量，但是在某些时候，其中一种资源可能会超额使用...，您将遇到瓶颈。一旦达到这一点，增加客户端线程数量并不会使事情变得更快。进得太远了，由于各种资源竞争的影响，吞吐量实际上可能开始下降。
问：我们能否预测吞吐量极限是多少？A：并非没有对整个系统和工作负载的深入分析，这是不切实际的。
问：我们可以预测瓶颈是什么吗？
A：并非没有对整个系统和工作负载的深入分析，这是不切实际的。
问：我们能否推论给定数量的客户端核心的最佳客户端线程数量。A：并非不知道前两个问题的答案。
问：那么，如何解决线程池大小难题的实际方法是什么？
A：基准测试和调整！
计算出实际的工作量，创建指示性基准（或将您的工作量视为基准），然后反复运行它，同时向上或向下调整客户端线程的数量。同时，测量客户端和数据库上的实际CPU和I / O负载，以尝试找出实际资源瓶颈所在的位置。这些措施可能对其他类型的调整（例如数据库和查询优化，网络调整）以及确定是否需要更多硬件，更快的网络接口等有用。
如果采用“基准和调整”，则不需要准确预测线程数。