이 페이지는 기계 번역되었습니다. 영어 원본을 읽어보세요. English

IBSurgeon 라이브러리

Windows Server 2016에서 Firebird를 1분 이내에 20% 더 빠르게 작동시키는 방법

越来越多的用户从旧版本升级到Windows Server 2016,其中一些人注意到,即使在相同的硬件和相同的数据库上,Windows Server 2016的运行速度也比以前的版本慢。

我们在Windows Server 2016和Firebird上进行了多次测试,发现了一个对Windows Server 2016性能影响巨大的选项:电源计划。

默认情况下,Windows 2016采用「平衡」电源计划,它会在支持硬件上自动平衡性能与能耗。听起来似乎没什么危险,但实际上,Windows Server 2016的平衡电源计划会大幅抑制CPU性能,降低服务器的整体性能。

可以即时切换电源计划,无需重启。看看在运行Firebird数据库、服务70个连接的服务器上启用「高性能」电源计划的效果:

高性能电源计划对CPU利用率的影响

好吧,这可能只是CPU利用率的问题,那整体性能呢?我们运行了多项测试,类似于TPCC(OLTP应用模拟),得到了以下数据:

电源计划 TPC-C吞吐量(越高越好)
平衡 17029
高性能 21226

该测试高度受磁盘限制,因此差异仅为20%,对于CPU密集型操作,提升幅度可能更大。

此外,我们还使用不同的电源计划对144Gb的Firebird 2.5数据库进行了恢复测试(使用gbak -c):

电源计划 恢复时间(越短越好)
平衡 4小时7分钟
高性能 2小时35分钟

仅仅一个「节能」选项就几乎让恢复性能翻倍!为什么会有如此显著的性能提升?答案在于索引:在恢复过程中,索引会大量使用CPU进行值排序。

看看gbak恢复中5个最大索引的时间戳值(以秒为单位)。

使用平衡电源计划的gbak:

Code
gbak: 9529.339 1230.343 5028900 346529     activating and creating deferred index INDMF_TAG_PLC_DATA_DT_D
gbak: 10787.610 1258.270 5028909 233365     activating and creating deferred index INDMF_TAG_PLC_DATA_TAG_D
gbak: 11824.329 1036.718 5028907 216488     activating and creating deferred index INDMF_TAG_PLC_DATA_LU_D
gbak: 12571.012 746.683 5028907 265160     activating and creating deferred index INDMF_TAG_PLC_DATA_C1
gbak: 13304.334 733.321 5028908 359393     activating and creating deferred index PKMNF2_DOC_DOWNTIME

总时间:3775秒

使用高性能电源计划

gbak: 5301.785 615.045 5028900 346529 activating and creating deferred index INDMF_TAG_PLC_DATA_DT_D

Code
gbak: 5924.667 622.882 5028909 233365     activating and creating deferred index INDMF_TAG_PLC_DATA_TAG_D
gbak: 6569.815 645.147 5028907 216488     activating and creating deferred index INDMF_TAG_PLC_DATA_LU_D
gbak: 7186.322 616.506 5028907 265160     activating and creating deferred index INDMF_TAG_PLC_DATA_C1
gbak: 7894.340 708.018 5028908 359393     activating and creating deferred index PKMNF2_DOC_DOWNTIME

总时间:2593秒

总结

因此,控制面板->硬件->电源选项中的这个简单设置可以极大地提升Windows Server 2016上Firebird数据库的性能。

请检查并立即启用高性能电源计划!

更多关于Firebird数据库性能的阅读:

特别感谢Oleg Matveev对本文撰写的帮助!