sql-server - Analysis Services 多维数据集处理挂起,但通过查询多维数据集重新激活
问题描述
在 SQL Server 2014 Analysis Services 中处理多维多维数据集时,我们遇到了一个非常奇怪的问题。多维数据集进程应该在大约 45 分钟内运行,但它似乎经常在处理过程中“卡住”或挂起,并且 msmdsrv.exe 进程的 CPU 和磁盘活动从非常高下降到几乎为零。从我们所看到的,如果您离开它,多维数据集将无限期地保持这种状态,但奇怪的是,如果您对多维数据集执行任意选择查询,它会自发地恢复处理。
据我所知,这似乎与this和this是同一个问题,尽管这些帖子来自 SQL 2005。
我们尝试按照这些帖子中的建议增加“ThreadPool\Process\MaxThreads”设置,但问题仍然存在。从那以后,我意识到在更高版本的 SQL 中还有另一个新的线程池设置“ThreadPool\IOProcess\MaxThreads”,所以我们现在也尝试增加它,看看效果如何。
有没有其他人以前见过这个问题,并且可以确认解决它的最佳方法?或者这是在更高版本中修复的 Analysis Services 的错误?
解决方案
我们似乎通过将ThreadPool\Process\MaxThreads和ThreadPool\IOProcess\MaxThreads都设置为256(高于基于 CPU 数量计算的默认值 64)解决了这个问题。
这似乎稍微减慢了多维数据集的处理速度(从大约 45 分钟到大约 55 分钟),但自从进行此更改以来,我们没有遇到任何处理挂起的问题。
推荐阅读
- laravel - Laravel 数据表 - 只返回请求的列,删除额外的模型字段
- c++ - boost::asio 不会触发读取处理程序,而 wireshark 会看到数据进入
- r - 使用 darksky r 包抓取每日历史天气数据
- java - 检查通用对象变量的类
- python - 更改其他类中 c_ulong() 的值
- angular - 带参数的角度http服务调用单元测试
- c# - 逆变/协方差 - 无法将类转换为接口
- javascript - 在 Bing 地图中显示来自数据源 URL 的所有业务位置
- python - 如何检查 TPU 设备类型是 v2 还是 v3?
- javascript - 编译 ejs 时 /workspace/Frontend/todoApp/views/board.ejs 中出现意外的标识符?