我们正在升级我们的数据库服务器，我遇到了一个奇怪的性能问题。
我们的旧服务器是一个8核和4 GB RAM的双处理器系统，在Java 6u22上运行Tomcat 7.0.37上运行的Win2k3 R2 Standard（32位），MS SQL Server 2005和SOLR 4.2。 我们正在使用MS SQL JDBC 3.0驱动程序来运行DIH以将我们的logging导入到solr中。 这个import过程大约需要4.5个小时。
我们的新服务器是一个双处理器系统，具有16核和32 GB的RAM，在Java 7u17上运行的Tomcat 7.0.39上运行的Win2k12 Standard（64位），MS SQL Server 2008 R2和SOLR 4.2。 我使用了相同的MS SQL JDBC 3.0驱动程序来运行DIH。 import过程花了8个多小时。
我目前正在使用MSSQL JDBC 4.0驱动程序运行一个导入testing，但是如果状态与我现在看到的一致，这也将需要7-8小时。
任何人都可以帮我弄清楚这个性能exception，并帮我纠正它？ 理想情况下，我希望看到导入过程缩短（服务器有更多的资源，所以它应该），但我会满足于获得相同的速度。
谢谢。
我发现import过程中主要的放缓。 这是10个儿童实体中的一个，也许是两个，也是他们各自的疑问。 在这10个中，这两个也是唯一没有使用CachedSqlEntityProcessor的。 尽pipe当我尝试重写以允许caching时，但是我却没有了解内存exception。 这些查询是相同的，旧的服务器使用 – 所以我不知道为什么它实际上放缓了新的服务器。
我决定重新整个过程。 我想我会有更好的结果从导入预处理文件，而不是单独运行子查询。 所以我创build了一个用于bcp的存储过程，用于将导出的所有文件导出为一个XML格式的文件，然后使用useSolrAddSchema打开。
bcp导出大概需要20分钟，而dih使用FileDataSource需要5分钟。
所以最后我对自己的performance感到满意。 他们在我们旧服务器上的Solr 1.3上开始了10个多小时，升级到了Sol 4.2，我可以把它缩减到4.5个小时，而现在新的服务器减less到大约25分钟。 我现在称之为胜利。