任务并行库和外部SQL Server

4
我有一个Windows服务,使用Task Parallel Library(TPL)并行执行大量任务。现在需要扩展它以处理与外部服务器上的SQL Server交互的任务。
TPL 可以有效地衡量负载并为任务分配正确数量的并行线程。是否有一种方法使其能够识别外部SQL Server实例的负载?实际在本地服务器上运行每个任务的代码非常少,但对数据库的调用可能会很重。
我是否可能因为TPL看到本地服务器有大量空闲资源而导致服务向数据库发送请求而导致数据库挂起?还是已经有一种已知的处理方式?

如果有一种方法可以从并行任务中提取数据库交互,那将是您最好的选择。 - Steven
数据库交互是我想要并行处理的部分,因此将其提取为非并行执行是没有意义的... - Christian Rygg
这并不意味着你必须完全按顺序执行,但是在分离它时,你将拥有更多的控制权。 - Steven
3个回答

3

TPL本身没有任何东西可以帮助您解决这个问题。TPL的作用是管理/最大化本地应用程序的CPU负载。它对SQL负载一无所知,更不用说在另一台机器上了。

话虽如此,如果你想疯狂一下,有一个称为TaskScheduler的可扩展点。您可以理论上实现一个自定义的TaskScheduler,它可以监视SQL服务器上的负载,并仅在该负载达到某个定义的阈值时调度任务执行。

但老实说,我认为这不是解决问题的正确方法。管理共享资源(如SQL服务器)的负载是与TPL设计要解决的完全不同的问题。您最好确保设计应用程序,使其不会滥用SQL服务器本身的权利,通过负载测试、找到甜点并配置应用程序不超出这些限制来解决问题。从那里开始,由您的DBA确定SQL服务器基础架构的正确解决方案,以管理该应用程序的需求以及其他外部负载。


0
如果您在客户端应用程序中并行化数据访问功能,那么您会发现下一个瓶颈是SQL Server连接池。

我认为这不会成为问题,这取决于硬件配置。当然,在同时运行多个SQL批处理是完全正常的。此外,该问题似乎暗示着已经有一个在并行执行繁重工作的服务,不一定与SQL绑定。 - Polity

-1

TPL 擅长对数据进行分区,而对于负载的测量任务,则由您的操作系统来确定(实际上它非常擅长这个任务)。因此,这更多是一个配置问题,而不是开发问题。(您的 SQL Server 实例是否比您的服务具有更高的优先级?)


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接