我们正在升级数据库服务器，但遇到了一个奇怪的性能问题。
我们的旧服务器是双处理器系统，具有 8 核和 4 GB RAM，运行 Win2k3 R2 Standard（32 位）、MS SQL Server 2005 和在 Tomcat 7.0.37 上运行的 SOLR 4.2，全部使用 Java 6u22。我们使用 MS SQL JDBC 3.0 驱动程序运行 DIH，将记录导入 solr。此导入过程大约需要 4.5 小时。
我们的新服务器是双处理器系统，具有 16 核和 32 GB RAM，运行 Win2k12 Standard（64 位）、MS SQL Server 2008 R2 和 SOLR 4.2，运行在 Tomcat 7.0.39 上，全部使用 Java 7u17。我使用相同的 MS SQL JDBC 3.0 驱动程序来运行 DIH。导入过程耗时超过 8 小时。
我目前正在使用 MSSQL JDBC 4.0 驱动程序运行导入测试，但如果状态与我现在看到的一致，这也将需要 7-8 个小时。
有人能帮我找出这个性能异常并帮我纠正吗？理想情况下，我希望看到导入过程缩短（服务器拥有更多资源，所以应该如此），但我满足于获得相同的速度。
谢谢。
答案1
我发现导入过程的速度变慢了。这是 10 个子实体及其各自查询中的一个，也许是两个。在这 10 个子实体中，这两个也是唯一不使用 CachedSqlEntityProcessor 的。虽然当我尝试重新工作以允许缓存时，我得到了内存不足异常。这些查询与旧服务器使用的查询相同 - 所以我不确定为什么它在新服务器上的速度会变慢。
我决定重新设计整个过程。我认为导入预处理文件会比单独运行子查询获得更好的结果。因此，我创建了一个存储过程，供 bcp 使用，将我需要的所有内容导出为 XML 文件，格式为可导入的格式，并启用 useSolrAddSchema。
bcp 导出大约需要 20 分钟，而使用 FileDataSource 的 dih 则需要另外 5 分钟。
所以最后我对性能提升感到满意。在我们旧服务器上使用 Solr 1.3 时，一开始需要 10 多个小时，升级到 Sol 4.2 后，我能够将时间缩短到 4.5 小时，现在使用新服务器，时间缩短到大约 25 分钟。现在我认为这是一次胜利。