火鸟在资源可用时减速

我有一个Firebird数据库的奇怪的减速问题。 在数据库的日常使用过程中，客户端遇到显着的减速，而系统仍然有大量的可用资源。 有关环境的一些信息：

• 在超级服务器模式下运行的64位Firebird 2.5.2服务器
• 该数据库在64位Windows 2008 R2服务器操作系统上运行
• 服务器操作系统运行在具有4个CPU核心和16 GB RAM的VMware 4.1 VM中
• 数据库大小约为37 GB，并发连接到数据库的数量约为150。

在观察减速的同时：

• 机器上的CPU使用率在40-60％之间，没有更高的峰值，并且负载在所有4个内核之间均匀分布
• 服务器的内存使用量约为4-6 GB，其余内存用作操作系统caching
• 磁盘队列长度几乎不会超过0.3，延迟时间大约为2-5毫秒
• 服务器上几乎没有networking活动。

尽pipe如此，放缓似乎与服务器上的一般负载有关。 在没有用户连接到数据库/没有后台作业正在运行的夜晚，用于引用的testing查询在4-5秒内执行，而在所有用户连接到数据库的当天，执行相同的参考查询需要60+几秒钟完成。 应该加上虽然减速是一般的性质，没有特定的查询是较慢的，而服务器负载，一切都变慢特定的Firebird数据库内。 服务器有其他数据库每天执行的交易数量非常less，这些其他数据库没有减速的迹象。 我甚至创build了一个经历减速的实时数据库的副本，并针对原始数据库和重复数据库执行相同的查询 – 原始的执行查询速度慢，重复速度快。 我知道的原始和重复之间唯一的区别是连接用户/并发事务的数量。

由于我在可用的操作系统资源中找不到任何明显的原因，所以我尝试从Firebird获取统计信息。

观察结果：

• 在高峰时间，根据mon $语句，数据库有30-40个事务并行运行（其中mon $ state == 1，根据存档意味着事务正在运行或正在等待locking）
• fb_lock_print显示关于数据库的以下内容：

LOCK_HEADER块

Version: 145, Active owner: 0, Length: 2097152, Used: 1335440 Flags: 0x0001 Enqs: 9993237, Converts: 93191, Rejects: 1417230, Blocks: 2 Deadlock scans: 0, Deadlocks: 0, Scan interval: 10 Acquires: 19972846, Acquire blocks: 0, Spin count: 0 Mutex wait: 0.0% Hash slots: 1009, Hash lengths (min/avg/max): 0/ 2/ 7 Remove node: 0, Insert queue: 0, Insert prior: 0 Owners (38): forward: 20824, backward: 872088 Free owners (126): forward: 973360, backward: 728016 Free locks (370): forward: 852200, backward: 195936 Free requests (12425): forward: 614608, backward: 1230536 Lock Ordering: Enabled 

在这里，我注意到“拒绝”字段占“enqs”字段的14％，但不幸的是我不知道这些值的确切含义。 我猜大约有14％的locking请求因某种原因被拒绝，但我可能完全错误。

所以问题：

• 在这种情况下，应如何解释fb_lock_print的输出？ 这些数字在某种意义上是否是“错误的”？ 他们可以改进一些参数调整？
• 应该采取哪些额外措施来查明造成减速的原因？