我们的一个系统最终投入生产，在高峰时段(任何时候约有 200 个并发用户)，流量可以在一小时内增加到 30,000 个用户交易。
我们注意到一个奇怪的行为，即在我们的 SQL 服务器重新启动后，性能非常快。即使一开始有200个并发用户，到SQL server 2008 R2的事务也不到10ms。然而，在大约 15,000 笔交易之后，我们可以看到每笔交易可能需要 100 毫秒才能完成。当涉及到大约 30,000 个事务时，每个事务最坏的情况可能需要 300ms。如果我们不重启 SQL 服务器，即使是单线程，事务仍将在 300 毫秒左右。
每笔交易将执行以下操作:
- 1 在主表中选择和 2 在帐户表中选择，1 插入或更新主表，1 插入或更新帐户表，1 或 2 插入历史表
- 账户表(2列作为主键，4列作为索引，另外6列作为数据列)
- 主表(3列为主键，5列索引，11列数据)
- 历史表(3列作为主键，4列作为索引，另外15列作为数据列)
注意:上面的某些数据列是索引上面是因为我们在where子句中使用了。
注意:在 Select 期间，我们不会出于性能目的连接任何表。
注意:DB Server和Web Server其实是同一个服务器。
系统设置:
- 操作系统:Windows 2008 企业版
- 网络服务器:Tomcat 网络服务器
- 与数据库的连接:Spring 连接池(最小 50，最大 350)
- 使用最新的 SQL JDBC 驱动程序
- 数据库服务器:SQL Server 2008 R2 SP1
服务器硬件:
- CPU:4 x 四核 CPU(每个核心有 2 个线程)，即总共 32 个物理线程
- 内存:16GB
- 硬盘:RAID 1 在 4 个 SAS 15K 硬盘上。这意味着 2 个硬盘对操作系统可见。应用程序数据和操作系统使用一个硬盘，而 SQL DB 使用另一个硬盘。
知道我们可以在哪里跟踪和解决 10,000 次交易后性能下降的问题吗？
最佳答案
原来硬盘Raid配置有误。与在这里选择 SQL/Oracle 无关，罪魁祸首是“Raid 1”配置。
我们延迟实际启动日期并在 Raid-0 上用两个硬盘重新测试，似乎 SQL 服务器的速度要好得多(快 30%)并且更加一致。此外，我们将硬盘重新格式化为 SQL MVP 推荐的 64k 簇大小。
我们最终在生产环境中将 6 个硬盘配置为 Raid 1-0，它运行得非常出色!
问题解决了!
关于java - 从繁忙的 Java Web 应用程序插入 30,000 个用户后，SQL Server 2008 变慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3673330/