解决Firebird性能问题

原文为FDD2012上的演讲英文ppt,现翻译为中文,原始链接为:http://www.slideshare.net/ibsurgeon/resolving-firebird-performance-problems

解决Firebird性能问题

Alexey Kovyazin, IBSurgeon

FDD 2012, Brazil


议程

  • 理解Firebird内存模型



    • 内存消耗方式
    • 内存使用调优
  • 冻结问题



    • IO问题 - (RAID)
    • 多余的垃圾回收 - 如何用IBTM和IBAnalyst检查数据库事务的状态和gstat
    • 锁冲突 - 如何检查系统锁表(lock table)状态
  • 缓慢的查询和错误索引



    • 通过MON$和FBScanner定位缓慢的查询
    • 通过FBScanner跟踪查询过程
    • 通过TRACE API插件(需2.5.x之后的版本)来跟踪查询过程


Firebird的内存消耗

Firebird内存消耗

内存消耗调优

  • 我们不能调整:元数据缓存(metadata cache)和索引位图所用内存
  • 我们可以通过firebird.conf调整:



    • 排序用内存: #TempCacheLimit参数(SS中缺省64MB, Classic/SuperClassic缺省8MB)和#TempBlockSize参数(逐步增加)
    • 数据页缓存: #DefaultDbCachePages参数(SS缺省2048页,Classic/SuperClassic缺省只有75页)
    • 应该使用操作系统的缓存么?

      FileSystemCacheThreshold = 65536 - 使用OS文件缓存

      FileSystemCacheThreshold = 0 - 不使用OS文件缓存(原文有误)

推荐设置

  • 对于32bit的SupverServer,内存4GB,数据库<5GB,客户端<20



    • Page size = 8192, Database page buffers = 10000 =>~80MB
    • TempCacheLimit = 134217728 =>128MB
    • FW=ON, MaxUnflushedWrites=default
  • 对于32/64bit的Classic server 或64bit的SuperClassic,>50连接,内存 16~32GB,>50个客户端



    • Page size = 8192, Database page buffers = 1024~2048
    • TempCacheLimit = 134217728 =>128MB(!)
    • FW=ON, MaxUnflushedWrites=default

我想把整个数据库都放进内存!

  • 没人这么干(查看后面的内容)
  • 可靠性变低
  • 记住,你想到的其实是这个:

    Forced writes = OFF (数据库级别)

    MaxUnflushedWrites = -1

    MaxUnflushedWriteTime = -1(在firebird.conf中)

内存方面常见问题

  • 32bit的SuperServer/SuperClassic没使用超过2(3)G的内存



    • 别设置太多的缓存页数(100000+)
    • 使用64bit的SuperServer/SuperClassic
  • 在64位windows,内存大于4G的情况下,32bit的Firebird在所有架构下表现都很糟



    • Firebird 2.5.2已修复此问题
    • 使用64bit的Firebird

      • 如果使用rfunc时有问题就用AUDFL

冻结问题

IO问题

我已经把数据库安装到一个很NB的服务器上,但她很慢

IO问题

  1. RAID的电池没电了(写入速度可能只有3M/s)

  2. 没安装合适的RAID驱动

  3. Write-through缓存设置问题

  4. 安装在虚拟环境(VMWare, Xen, Hyper-V)中,IO带宽有限

  5. RAID(1/5/10等)的驱动文件损坏

  6. 错误的RAID设置

  7. Linux下,使用Ext4时没有设置nobarrier

如何检查和修复IO问题

  • Windows下可以使用HDTune, CrystalDiskMark
  • Linux下可以使用hdparm, IOMeter
  • 如果结果有好几项的值很低,检查RAID的设置及驱动

IO性能的平均水平

  • CrystalDiskMark

    • SATA驱动器在70~140 IOPS
    • SAS驱动器为175 IOPS或更高
    • SSD企业级驱动器在1000+ IOPS

一些建议

  • 为以下内容设置不同的分区(RAIDs)



    • 数据库
    • 临时文件
    • 备份
    • 系统
  • 最好(也是最贵)的驱动器是SSDs

  • 最好的RAID方案是RAID10

  • 最高性价比是使用nSAS(有SAS接口的SATA驱动器)

  • 内存磁盘不会有一点性能改善(与对内存使用进行正确设置相比)

不必要的垃圾收集

  • 有时你会发现应用程序访问数据库很慢,这可能是数据库正在进行不必要的垃圾收集
  • 三个问题

    • 什么时候发生
    • 什么情况下发生
    • 谁正在清理

快速检查潜在的垃圾收集

  • gstat -h

Oldest transaction 1608100

Oldest active 1630966

Oldest snapshot 1489780

Next transaction 3329328

...

Variable header data:

Sweep interval: 20000

*END*

IBTM检查什么时候发生

IBTM

什么情况下发生

  • gstat -a -r 来显示记录和版本

gstat

IBAnalyst - 什么情况下发生

IBAnalyst

MON$ - 谁在清理

Mon$

  • 从进程启动开始就收集相关信息

谁在清理 - GUI工具

  • Synatica Monitor
  • FBScanner - MonLogger(新的模块)

加锁引起的问题(Classic & SuperClassic)

Locking problems

优化锁表(lock table)

  • 锁表大小

    • #LockMemSize = 1048576
    • 建议值=乘10
  • 锁表通道

    • #lockHashSlots = 1009
    • 建议值=乘10

不良的查询语句

如果识别不良的查询语句

  • MON$STATEMENTS

    • FBScanner MonLogger
  • FBScanner general tracing
  • Trace API

    • Standard plugin
    • FBScanner plugin

通过代理 - FBScanner

FBScanner

通过MON$ 表相关信息来检查查询语句

mon$tables

TRACE API

Trace API

标签: firebird, 性能, 内存, 调优, 冻结, IO, 垃圾回收, , 缓慢, 查询, 索引

仅有一条评论

  1. 支持下 写的不错的!

添加新评论