调整Firebird和Linux,以容纳691 GB的数据库,可容纳1000多个用户

Firebird是在俄罗斯非常受欢迎的开放式DBMS,尽管没有嘈杂的营销活动,但它仍用于大量关键系统中,尤其是在医疗和状态自动化系统中。

数据库的大小和此类系统中的活动用户数量通常都很大,因此在本文中,我将基于BeZdorov (Ingosstrakh), AlfaZdrav的大型Firebird数据库的特定示例,讨论优化Firebird和Linux设置经验,我将介绍其他优化公司经验火鸟+ Linux。

让我们仔细看一下优化的主题-Firebird 3.0.5 DBMS(具有HQbird扩展),为691GB数据库(当前)提供每日1000-1100个用户,在Linux CentOS 7上运行,服务器使用HP DL380 Iron。 已为数据库配置了到备份服务器的复制(复制问题不在本文讨论范围之内)。

DBMS为医疗信息系统Infoklinika(由俄罗斯公司Smart Delta Systems生产 )提供服务,该系统是俄罗斯最受欢迎的医疗信息系统之一。

让我们看一下该数据库操作的详细信息(屏幕快照稍后从HQbird截取):

数据被大量插入数据库-每天增加约0.4-0.5 GB



通常每天的负载为1000-1100个连接:



尽管有大量的增长和活跃的工作,但是数据库并没有包含大量的垃圾记录版本,这要归功于对多版本体系结构有充分了解的应用程序以及正确配置的垃圾收集:



绿区中的交易标记:



顺便说一句,请注意数据库中的数据是字符串,存在blob,但是它们很少-总大小中的690 GB中只有10 GB。

数据库负载的性质是混合的,其中75%的读取操作和25%的写入操作:




服务于该系统的服务器还不错,但是离高端还很远:

HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT 320Gb RAM, 4 network cards 

磁盘子系统由两部分组成:本地745Gb磁盘和到SAN的双2光纤通道连接,具有1.8Tb分区。

作业系统


使用CentOS 7,内核版本:

 Linux version 3.10.0-957.21.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2019 

对于逻辑问题,为什么不使用最现代的内核和CentOS 8,答案也是合乎逻辑的-关键系统的迁移仅在几个次要版本的发布和严格测试之后才发生-这是已知错误优于两个未知的情况之一。

但是,应该指出的是,直到2017年,该系统都在CentOS 6.x上运行,并且在迁移之后,性能指标得到了显着改善。

Linux设置


Firebird的绝对必要的Linux定制


在运行Firebird的所有Linux服务器上必须增加2个参数-虚拟内存区域(VMA)的数量和Firebird进程打开文件的数量。

1. VMA

默认的VMA编号为64K,必须增加4倍,为此,请在sysctl.conf中添加该行

 vm.max_map_count=262144 

要检查当前值,请使用以下命令

 sysctl vm.max_map_count 

2.最大打开文件数

Firebird为与数据库的每个连接最多打开20个描述符(文件句柄)(考虑到Linux中所有资源看起来都像文件的事实),因此默认情况下打开的最大文件数(通常为4096)可以很快耗尽。

要检查Firebird的可用文件数,最好查看Firebird可执行文件的限制:

 cat /proc/$(pgrep firebird)/limits 

在哪里检查“最大打开文件”的值,并在必要时增加它们。

为了增加Firebird的“最大打开文件数”参数,我们在[service]部分的firebird-superserver.service文件中添加了以下行:

 LimitNOFILE=49999 

可选的Linux设置


在此服务器上,我们还进行了以下设置

1.减少交换

由于服务器专用于Firebird DBMS,并且我们希望在DBMS高速缓存和操作系统文件高速缓存下有效地使用RAM,因此我们将sysctl.conf减少了默认的60%到10%的可交换性。

 vm.swappiness=10 

2.增加了特殊操作系统进程的最小保留内存大小

 vm.min_free_kbytes=1048576 

即1GB的内存。 此设置间接影响内存碎片整理。

请注意,此设置是单独的-鉴于我们有320GB的RAM,那么1GB并不是很多,但是在内存量较小(例如32GB)的情况下,1GB可能太多。

3.减少keepalive

Firebird依靠keepalive间隔检查连接状态,并且keepalive的默认值可能非常大。 将其限制为300秒,我们摆脱了挂起的连接

 net.ipv4.tcp_keepalive_time=300 net.ipv4.tcp_keepalive_probes=5 net.ipv4.tcp_keepalive_intvl=15 

更多Linux调优


为什么我们局限于少数几个Linux设置?

首先,我们采用保守的方法来通过Linux调整服务器(每个新版本都在不断完善),其次,此Firebird数据库既不是非常大也不是负载最大,并且Linux可以处理指定的设置与您的任务。

当然,还有更多可用于在Linux上优化Firebird的设置-例如,联邦法警服务中有关3 TB Firebird数据库(RedBaza)演示中介绍了许多有趣的事情。

配置Firebird


带有firebirdsql.org的Firebird社区的配置文件配置非常保守,并且在或多或少强大的服务器上,您需要更改配置文件并仔细选择所使用的体系结构(在Firebird 3.0中,有2种连接类型:Embedded和NetworkServer,以及3种类型的体系结构:SuperServer ,SuperClassic,Classic)。
此外,您必须使用每个数据库的设置-即 将参考特定数据库的关键设置放在database.conf中。

在我们的案例中,我们选择了3.0版中最受欢迎的SuperServer体系结构,因为 它有效地使用了多核处理器,并为所有连接共享了一个缓存(但对于每个数据库却是单独的)。

以下是配置文件(仅与性能相关的值):

firebird.conf-服务器上所有数据库的配置文件

 DefaultDbCachePages = 50K # pages FileSystemCacheThreshold = 300K # pages TempBlockSize = 2M # bytes TempCacheLimit = 20480M # bytes LockMemSize = 30M # bytes LockHashSlots = 30011 WireCompression = true ServerMode = Super ExtConnPoolSize = 500 # HQBird ExtConnPoolLifeTime = 14200 # HQBird SortDataStorageThreshold = 8192 #HQbird reports queries 

在性能方面,此处的关键参数是:

1. DefaultDbCachePages = 50K#它以DB上的页面为单位进行测量,第16K = 0.8Gb

firebird.conf中DefaultDbCachePages页面缓存的大小默认情况下特别设置为800Mb,以便服务器上意外混乱的测试数据库不会尝试占用大量RAM。

2. FileSystemCacheThreshold = 300K#页

重要的是将此参数设置为大于DefaultDBCachePages的值,以启用OS文件缓存的使用。

3. TempCacheLimit = 20480M#字节

此参数为带有排序(和其他一些操作)的查询设置内存大小,并且对于每个系统都是单独的。
监视排序大小的结果是,我们发现20GB对于该数据库是最佳的。

4. LockMemSize和LockHashSlots-锁定表的参数

这些参数确定锁定表的初始大小以及用于计算哈希函数的插槽数。

5. WireCompression =真

配置可压缩客户端和服务器之间的流量,这对于运行客户端应用程序的密集的“外部执行语句”特别有用。

其余参数在firebird.conf本身以及Firebird和HQbird的相关文档中进行了描述。

我们使用正确的数据库在database.conf中进行了最重要的设置

 database1 = /data/database1.fdb { DefaultDbCachePages = 14080K # 16K pages, 220 GB FileSystemCacheThreshold = 15361K TempSpaceCacheThreshold=2G #HQbird only, track big sorts LockHashSlots = 40099 LockMemSize = 50M } 

如您所料,这种情况下的主要困难是如何正确计算大型数据库分配的内存大小。

对于具有SuperServer体系结构的Firebird 3.0,有两种方法-保守的,用于具有少量RAM(最大包括32GB)的服务器,其中包括为页面缓存分配不超过25%的RAM,否则依赖文件操作系统系统和微调,当我们精确确定排序的最佳大小时,为OS内核分配一定的内存大小,为海量的文件操作(例如备份)保留一定数量的内存, 其余分配给页面缓存。

在第二种情况下,不可能立即获得最佳的高速缓存大小,因为对于不同类型的数据库,负载的性质可能会有很大差异,但是经过几次迭代后,您可以获得很好的结果。

配置Firebird的常见错误


典型错误包括以下内容:

1)在DB标头页上显式指定的页面缓存的大小,它将覆盖firebird.conf和database.conf中指定的值。

特别是在将体系结构从Classic / SuperClassic更改为SuperServer时,经常会发生此错误-如果Classic / SuperClassic连接的缓存大小可以正常工作,并且大小清楚(500-2000页),则SuperServer需要更大的缓存。
要检查,请运行命令

 gstat -h databasepathname 

并检查Page Buffers值-应该为0,然后Firebird将使用database.conf或firebird.conf中的值。

要重置标题页上的页面缓存设置,请运行以下命令

 gfix -buff 0 databasepathname 

2)当增加页面缓存时,他们忘记增加FileSystemCacheThreshold,这导致文件缓存断开,从而降低了性能。

3)使用默认数据库页面大小(4096或8192),而对于大型数据库,则需要使用16K。

结论


通常,与Linux配置的和Firebird配置的负载相对应的1000多个Firebird用户可以正常工作。 在性能方面,此服务器具有一定的优势,已在峰值负载下测试了最多1500-1800个用户。

在具有类似负载的Firebird数据库的Linux发行版中,最受欢迎的是CentOS 7,推荐的版本是Firebird 3.0。

如果您有任何疑问,我将很乐意在评论中回答,或者发送电子邮件至ak@ibase.ru。

Source: https://habr.com/ru/post/zh-CN476636/


All Articles