达梦数据库安装部署上线之前对操作系统和实例初始化参数都需要进行相关配置与调整,诸多参数是达梦人经过长期积累和实践探索的宝贵知识财富,下边详细介绍相关设置和配置的原因及意义。linux全面调优请参考之前写的一篇博客,博客里给出了几方面调优和最佳配置的方案及建议,博客链接地址:
一、操作系统层参数调整及原因
1、关闭防火墙和selinux
①SELinux,它是一个 Linux 内核模块,也是 Linux 的一个安全子系统。SELinux的策略分为两种,一个是目标(targeted)策略,另一个是严格(strict)策略。有限策略仅针对部分系统网络服务和进程执行SELinux策略,而严厉策略是执行全局的NSA默认策略。有限策略模式下,9个(可能更多)系统服务受SELinux监控,几乎所有的网络服务都受控。
SELinux的开发原则是基于最小权限原则。所以很多时候设计人员为程序设计时只会开放应用程序合法使用的权限(我一直在被该不该开权限的问题折磨着...)。所以一旦应用程序更新使用了新的权限,才会被内核以权限不足的原因给干掉(也就是为什么程序会在关闭了selinux就能正常运行的原因了。)
案例分析:
Apache - "Document root must be a directory" 问题?有可能和这个问题并发的问题还有 403 Forbidden 禁止访问的问题。
现象描述
不使用系统默认的 /var/www/html作为系统的Document Root,自己新建一个目录后修改/etc/httpd/conf/httpd.conf 中的配置,然后重起Apache的Daemon,发现Apache无法起动,系统报错:Document root must be a directory。但是,我们设置的DocumentRoot 的确是一个目录,而且apache用户具有可读权限。
另一种情况:
新建一个虚拟目录或文件后,无法访问,显示 Forbidden, 403 Error,但文件或目录有可读权限。
问题产生的原因:
一开始想来想去想不出为什么,但是给我感觉是权限的问题,用传统的Linux的思维方式来看,权限绝对没有问题。但是仔细一想,SELinux是不是会有其他安全的设定?
检查 avcmessage,查看 /var/log/messages文件,发现有类似以下内容的这样一段:
Dec 24 17:54:59 hostname kernel: audit(1098222899.827:0): avc:
denied{ getattr } forpid=19029 exe=/usr/sbin/httpd
path=/var/www/html/about.html dev=dm-0 ino=373900
scontext=root:system_r:httpd_t tcontext=user_u:object_r:user_home_t
tclass=file
问题找到了,果然是SELinux的新特性搞的鬼。我把目录或文件设成了user_home_t类型,因此apache的进程没有权限,无法访问。针对Apache的进程所使用的SELinux target policy规定了apache的进程只能访问httpd_sys_content_t类型的目录或文件。
②防火墙iptables,首先,防火墙需要在服务器上进行文件的配置,这就会占用系统的内存,从而造成性能上的浪费;主要工作在网络层,针对IP数据包,体现在对包内的IP地址、端口等信息的处理上,IP信息包通过四表五链的过滤系统(两个组件netfilter和iptables组成)对于高并发高流量的业务服务器仍是不能开的,因为会有较大性能损失,导致网站访问很慢,这种情况下只能在前端加更好的硬件防火墙了。
为此,建议非必要关闭selinux和iptables服务。
2、关闭numa模式
一个 DBA在安装数据库的时候,通常都会按要求关闭NUMA(MOS:DisableNUMAAt OS Level,因为启用NUMA会导致CPU 也许是这类问题太多,因为NUMA的使用比较苛刻,要结合硬件、操作系统和dm版本,稍有不对,努力白费,所以乖乖的关掉NUMA,是比较正确的。
Linux系统初始化开启NUMA,NUMA的内存分配策略是优先在进程所在的CPU处理器的本地内存中分配,会导致CPU进程之间的内存分配不均衡,从而当某些CPU处理器的内存不足时,会导致交换产生,而不是从远程例程分配的内存,甚至另一个CPU处理器上有足够的物理内存。这种内存分配策略的初衷是让内存更接近需要它的进程,但不适合数据库这种大规模内存使用的我们建议用户在使用DM时关闭NUMA。简而言之,就是说,你可以指定内存在本地分配,在某几个CPU节点分配或者轮询分配。除非 是设置为--interleave=nodes轮询分配方式,即内存可以在任意NUMA节点上分配这种方式以外。其他的方式就算其他NUMA节点上还有内 存剩余,Linux也不会把剩余的内存分配给这个进程,而是采用SWAP的方式来获得内存。
具体不描述了,参考如下文章理解吧,如果不能很好的掌握numa的分配规则和程序控制的话,建议关闭,默认SMP共享架构,平均分配内存:
3、关闭swap
swap是如何产生的?
swap指的是一个交换分区或文件,主要是在内存使用存在压力时,触发内存回收,这时可能会将部分内存的数据交换到swap空间内存回收的机制
①Linux内核使用cache对部分文件进行缓存,提升文件读写效率。所以 引入了kswapd进程进行周期性检查,保证剩余内存空间。
②当内存分配没有足够的空间时,直接内存回收。
内存回收如何实现
这部分实现非常复杂,简单来说,内存回收操作主要针对内存的文件页和匿名页,这些页都通过LRU链表来管理。其中anon的匿名页内存主要回收手段是swap,文件页释放方式是写回和清空。
swappiness的值的大小对如何使用swap分区是有着很大的联系的。swappiness=0的时候表示最大限度使用物理内存,然后才是 swap空间,swappiness=100的时候表示积极的使用swap分区,并且把内存上的数据及时的搬运到swap空间里面。linux的基本默认设置为60。简单地说这个参数定义了系统对swap的使用倾向,默认值为60,值越大表示越倾向于使用swap。可以设为0,这样做并不会禁止对swap的使用,只是最大限度地降低了使用swap的可能性。
4、关闭透明大页(transparent_hugepage)
Linux 下的大页分为两种类型:标准大页(Huge Pages)和透明巨页(Transparent Huge Pages)。
1). 标准大页(Huge Pages)是从 Linux Kernel 2.6 后被引入的。目的是用更大的内存页面(memory page size) 以适应越来越大的系统内存,让操作系统可以支持现代硬件架构的大页面容量功能
2). 透明巨页(Transparent Huge Pages)缩写为 THP,透明超大页面(THP)在 RHEL 6 中默认情况下对所有应用程序都是启用的。内核试图尽可能分配巨大的页面,主内核地址空间本身被映射为巨大的页面,减少了内核代码的 TLB 压力。内核将始终尝试使用巨页来满足内存分配。如果没有可用的巨大页面(例如由于物理连续内存不可用),内核将回退到正常的 4KB 页面。THP 也是可交换的(不像 hugetlbfs)。这是通过将大页面分成更小的 4KB 页面来实现的,然后这些页面被正常地换出。两者区别在于大页的分配机制,标准大页管理是预分配方式,而透明巨页管理则是动态分配方式。目前透明巨页与传统大页混合使用会出现一些问题,导致性能问题和系统重启。
总之,THP主动性的分配连续大页内存以及频繁的页块整理等可能会导致内存分配延迟,引发性能问题。最后我们总结一下,实际在数据库服务器上,巨大的共享内存段属于启动时的一次性分配,且大部分的启动操作都属于计划性的工作,不需要内核给我们动态分配,而数据库连接的那些server process往往内存较小也不需要用到大页,也就是强烈建议关闭THP的原因。
5、挂载磁盘建议UUID方式挂载
一般服务器都有多个硬盘分区,在重启后,这些分区的逻辑位置加载时可能会发生变动,如果使用传统的设备名称(例如:/dev/sda)方式挂载磁盘,就可能因为磁盘顺序变化而造成混乱。Linux环境中每个Block Device都有一个全局唯一的UUID,可以标识这个设备,我们可以在fstab中使用UUID替换设备名称,这样就不会产生上述混乱的情况了。
6、磁盘I/O调度算法
I/O调度程序的总结:
- 当向设备写入数据块或是从设备读出数据块时,请求都被安置在一个队列中等待完成.
- 每个块设备都有它自己的队列.
- I/O调度程序负责维护这些队列的顺序,以更有效地利用介质.I/O调度程序将无序的I/O操作变为有序的I/O操作.
- 内核必须首先确定队列中一共有多少个请求,然后才开始进行调度.
I/O调度的4种算法:
- CFQ(完全公平排队I/O调度程序)
在最新的内核版本和发行版中,都选择CFQ做为默认的I/O调度器,对于通用的服务器也是最好的选择。CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择。CFQ赋予I/O请求一个优先级,而I/O优先级请求独立于进程优先级,高优先级的进程的读写不能自动地继承高的I/O优先级。
对于很多IO压力较大的场景就并不是很适应,尤其是IO压力集中在某些进程上的场景。因为这种场景我们需要更多的满足某个或者某几个进程的IO响应速度,而不是让所有的进程公平的使用IO,比如数据库应用。
CFQ试图均匀地分布对I/O带宽的访问,避免进程被饿死并实现较低的延迟,是deadline和as调度器的折中。
工作原理:
CFQ为每个进程/线程,单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,每个队列按照上述规则进行merge和sort。各队列之间的调度使用时间片来调度,以此来保证每个进程都能被很好的分配到I/O带宽.I/O调度器每次执行一个进程的4次请求。可以调 queued 和 quantum 来优化。
- NOOP(电梯式调度程序)
在Linux2.4或更早的版本的调度程序,那时只有这一种I/O调度算法.I/O请求被分配到队列,调度由硬件进行,只有当CPU时钟频率比较有限时进行。
Noop对于I/O不那么操心,对所有的I/O请求都用FIFO队列形式处理,默认认为 I/O不会存在性能问题。这也使得CPU也不用那么操心。它像电梯的工作主法一样对I/O请求进行组织,当有一个新的请求到来时,它将请求合并到最近的请求之后,以此来保证请求同一介质.
NOOP倾向饿死读而利于写.
NOOP对于闪存设备,RAM,嵌入式系统是最好的选择.
电梯算法饿死读请求的解释:
因为写请求比读请求更容易,写请求通过文件系统cache,不需要等一次写完成,就可以开始下一次写操作,写请求通过合并,堆积到I/O队列中。读请求需要等到它前面所有的读操作完成,才能进行下一次读操作.在读操作之间有几毫秒时间,而写请求在这之间就到来,饿死了后面的读请求.
- Deadline(截止时间调度程序)
通过时间以及硬盘区域进行分类,这个分类和合并要求类似于noop的调度程序.
Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限.这样就防止了写操作因为不能被读取而饿死的现象.
Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择。
deadline实现了四个队列,其中两个分别处理正常read和write,按扇区号排序,进行正常io的合并处理以提高吞吐量.因为IO请求可能会集中在某些磁盘位置,这样会导致新来的请求一直被合并,于是可能会有其他磁盘位置的io请求被饿死。于是实现了另外两个处理超时read和write的队列,按请求创建时间排序,如果有超时的请求出现,就放进这两个队列,调度算法保证超时(达到最终期限时间)的队列中的请求会优先被处理,防止请求被饿死。由于deadline的特点,无疑在这里无法区分进程,也就不能实现针对进程的io资源控制。
- AS(预料I/O调度程序)
本质上与Deadline一样,但在最后一次读操作后,要等待6ms,才能继续进行对其它I/O请求进行调度.可以从应用程序中预订一个新的读请求,改进读操作的执行,但以一些写操作为代价.它会在每个6ms中插入新的I/O操作,而会将一些小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量.
AS适合于写入较多的环境,比如文件服务器
AS对数据库环境表现很差.
从原理上看:
- cfq是一种比较通用的调度算法,是一种以进程为出发点考虑的调度算法,保证大家尽量公平。
- deadline是一种以提高机械硬盘吞吐量为思考出发点的调度算法,只有当有io请求达到最终期限的时候才进行调度,非常适合业务比较单一并且IO压力比较重的业务,比如数据库。
- noop?思考对象如果拓展到固态硬盘,那么你就会发现,无论cfq还是deadline,都是针对机械硬盘的结构进行的队列算法调整,而这种调整对于固态硬盘来说,完全没有意义。对于固态硬盘来说,IO调度算法越复杂,效率就越低,因为额外要处理的逻辑越多。所以,固态硬盘这种场景下,使用noop是最好的,deadline次之,而cfq由于复杂度的原因,无疑效率最低。
7、limit限制
一般而言,我们很容易在 open files 上被限制,DM数据库要求如下:
我们一般尽可能地把相关参数进行一此全面的调整,我们可以临时修改和永久修改。具体相关参数解释如下:
- core - 限制内核文件的大小(kb)
- date - 最大数据大小(kb)
- fsize - 最大文件大小(kb)
- memlock - 最大锁定内存地址空间(kb)
- nofile - 打开文件的最大数目
- rss - 最大持久设置大小(kb)
- stack - 最大栈大小(kb)
- cpu - 以分钟为单位的最多 CPU 时间
- noproc - 进程的最大数目
- as - 地址空间限制
- maxlogins - 此用户允许登录的最大数目
下图是ulimit 命令参数临时修改及含义:
以修改最大文件数为例:
1、临时修改
通过-Sn/-Hn设置最大打开文件描述符数的soft/hard,注意soft必须小于hard
# ulimit -Sn 65537
# ulimit -Hn 65538
同时设置soft和hard。对于非root用户只能设置比原来小的hard。
# ulimit -n 180000
2、永久修改
/etc/security/limits.conf是linux资源限制配置文件,需要在root权限下,才能修改/etc/security/limits.conf文件。
永久修改,需要修改文件 /etc/security/limits.conf, 加上:
* soft nofile 65536
* hard nofile 65536
修改之后,还需要在 vi /etc/pam.d/login 最后加上一行:
session required pam_limits.so (用户登录即加载limit配置生效用户)。
注意:/etc/security/limits.d/90-nproc.conf 与 /etc/security/limits.conf 都是系统用户资源配置文件,两者有什么不一样呢?
/etc/security/limits.conf 配置文件可限制文件打开数,系统进程等资源,在该文件配置中写的最大用户进程数是受/etc/security/limits.d/90-nproc.conf(有些操作系统是20-nproc.conf)配置上限影响的。一般系统 Linux 系统中的各种后台daemon的调优。
Linux系统中存在各种各样的后台daemon,也就是各种service,对于DM数据库服务器来说很多没有必要的service就可以通通关闭掉。以mysql为例子,Mysql的最小化的后台服务,可以只有:crond,sshd,rsyslog,network,sysstat,如果有需要可以在增加其他服务。使用 chkconfig --level 35 servicename off; 可以进行关闭。(35表示在runlevel的level =3 和 level =5级别进行关闭。)
8、网络参数调整
网络调优分为硬件层面和TCP/IP软件层面参数的调优。
1、 网络硬件调优
①换延迟更小,throught更大的网卡;
②双网卡绑定,进行负载均衡和高可用;
2、TCP/IP参数调优
①socket buffer 参数调节
[root@localhost ~]# echo 1>/proc/sys/net/ipv4/tcp_mem TCP全局缓存,单位为内存页(4k);
对应的内核参数:net.ipv4.tcp_mem ,可以在 /etc/sysctl.conf 中进行修改;
root@localhost ~]# echo 2>/proc/sys/net/ipv4/tcp_rmem 接收buffer,单位为字节
对应的内核参数:net.ipv4.tcp_rmem, 可以在 /etc/sysctl.conf 中进行修改;
root@localhost ~]# echo 3>/proc/sys/net/ipv4/tcp_wmem 接收buffer,单位为字节
对应的内核参数:net.ipv4.tcp_wmem, 可以在 /etc/sysctl.conf 中进行修改;
root@localhost ~]# echo 4>/proc/sys/net/core/rmem_default 接收buffer默认大小,单位字节
对应内核参数:net.core.rmem_default, 可以在 /etc/sysctl.conf 中进行修改;
root@localhost ~]# echo 5>/proc/sys/net/core/rmem_max 接收buffer最大大小,单位字节
对应内核参数:net.core.rmem_max, 可以在 /etc/sysctl.conf 中进行修改;
root@localhost ~]# echo 6>/proc/sys/net/core/wmem_default 发送buffer默认大小,单位字节
对应内核参数:net.core.rmem_default, 可以在 /etc/sysctl.conf 中进行修改;
root@localhost ~]# echo 7>/proc/sys/net/core/wmem_max 发送buffer最大大小,单位字节
对应内核参数:net.core.rmem_max, 可以在 /etc/sysctl.conf 中进行修改;
②offload配置调整
a、将tso,checksum等功能交给网卡硬件来完成:
ethtool -K eth0 rx on|off
ethtool -K eth0 tx on|off
ethtool -K eth0 tso on|off
b、调大网卡的接收队列和发送队列:
接收队列:/proc/sys/net/core/netdev_max_backlog 对应内核参数:net.core.netdev_max_backlog
c、发送队列:
查看大小:ifconfig eth0 | grep txqueue
修改大小:ifconfig eth0 txqueuelen 20000
d、调大 SYN 半连接 tcp_max_syn_backlog 数量:
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
也可以在/etc/sysctl.conf文件中配置。
e、net.core.somaxconn:
该参数为完成3次握手,已经建立了连接,等待被accept然后进行处理的数量。默认为128,我们可以调整到 65535,甚至更大。也就是尅有容纳更多的等待处理的连接。
③MTU 大小调优
a、 如果TCP连接的两端的网卡和网络接口层都支持大的MTU,那么我们就可以配置网络,使用更大的mtu大小,也不会导致被 切割重新组装发送。
配置命令:ifconfig eth0 mtu 9000 up
b、TCP连接的 CLOSE_WAIT 和 TIME_WAIT
如果TCP连接的 CLOSE_WAIT 和 TIME_WAIT 状态过多时,分别需要调优TCP的keepalive相关的参数和TCP的回收相关的参数。更多详细参照系统手册进行调整。
9、文件系统类型
磁盘IO的调优,磁盘IO的调优涉及到文件系统的调优和磁盘的调优。
文件系统的调优 ( xfs > ext4 > ext3 )
1. ext3
(1)最多只能支持32TB的文件系统和2TB的文件,实际只能容纳2TB的文件系统和16GB的文件
(2)ext3目前只支持32000个子目录
(3)ext3文件系统使用32位空间记录块数量和i-节点数量
(4)当数据写入到Ext3文件系统中时,ext3的数据块分配器每次只能分配一个4KB的块
2. ext4
ext4是系统下的日志文件系统,是ext3文件系统的后继版本。
(1)ext4的文件系统容量达到1EB,而文件容量则达到16TB
(2)理论上支持无限数量的子目录
(3)ext4文件系统使用64位空间记录块数量和i-节点数量
(4)ext4的多块分配器支持一次调用分配多个数据块
3. xfs
(1)根据所记录的日志在很短的时间内迅速恢复磁盘文件内容
(2)采用优化算法,日志记录对整体文件操作影响非常小
(3) 是一个全64-bit的文件系统,它可以支持上百万T字节的存储空间
(4)能以接近裸设备I/O的性能存储数据
10、 Linux 系统中的各种后台daemon的调优。
Linux系统中存在各种各样的后台daemon,也就是各种service,对于DM数据库服务器来说很多没有必要的service就可以通通关闭掉。以mysql为例子,Mysql的最小化的后台服务,可以只有:crond,sshd,rsyslog,network,sysstat,如果有需要可以在增加其他服务。使用 chkconfig --level 35 servicename off; 可以进行关闭。(35表示在runlevel的level =3 和 level =5级别进行关闭。)
二、达梦数据库实例参数调整
例如有一个密集交易型数据库服务器配置如下:CPU:4路8核 内存:256G 磁盘阵列:1T。
参数名 | 含义 | 优化建议 | 默认值 | 建议值 |
MEMORY_POOL | 公共内存池,单位为M。 | 高并发时应调大,避免频繁向OS申请内存 | 80 | 2048 |
N_MEM_POOLS | 将公共内存池分片,减少并发访问冲突,单位为个。 | 4 | 4 | |
BUFFER | 数据缓冲区,单位为M。 | 如果数据量小于内存,则设置为数据量大小;否则设置为总内存的2/3比较合适 | 1000 | 120000 |
BUFFER_POOLS | BUFFER的分区数,一般配置为质数,取值范围为1~500,当MAX_BUFFER>BUFFER时,动态扩展的缓冲区不参与分区 | 并发较大的系统需要配置这个参数,减少数据缓冲区并发冲突,建议BUFFER=MAX_BUFFER | 1 | 101 |
MAX_BUFFER | 数据缓冲区扩展最大值 | 建议配置成=BUFFER | 1000 | 120000 |
RECYCLE | 用于缓冲临时表空间,单位为M | 高并发或大量使用with、临时表、排序等应该调大点 | 64 | 5000 |
SORT_BUF_SIZE | 排序缓存区,单位M | 建索引时调大点,平时默认 | 2 | 32 |
CACHE_POOL_SIZE | 用于缓存SQL、执行计划、结果集等 | 一般配置为1000M~4000M | 10 | 1024 |
DICT_BUF_SIZE | 数据字典缓存区,单位M | 用于缓存数据字典,默认5M,系统中对象个数较多时适当加大 | 5 | 32 |
HJ_BUF_GLOBAL_SIZE | 哈希连接使用的内存空间上限,单位M | 高并发、hash操作多应调大 | 500 | 5000 |
HJ_BUF_SIZE | 单个哈希连接使用的内存 | 有大表的hash连接应调大 | 50 | 500 |
HAGR_BUF_GLOBAL_SIZE | 聚集操作使用的内存上限,单位M | 高并发、大量的聚集操作如sum等应调大 | 500 | 5000 |
HAGR_BUF_SIZE | 单个聚集操作使用的内存 | 有大表的hash分组应调大 | 50 | 500 |
WORKER_THREADS | 工作线程的个数 | 建议设置为cpu核算或其两倍 1~64 | 4 | 32 |
ENABLE_MONITOR | 数据库系统监控的级别 | 性能优化时设置为3,运行时设为2 | 2 | 2或者3 |
OLAP_FLAG | 启用联机分析处理,0:不启用;1:启用;2: | 联机交易系统建议设置为2,联机分析系统建议设置为1 | 0 | 2 |
不启用,同时倾向于使用索引范围扫描 | ||||
OPTIMIZER_MODE | 优化器计划探测模式。设置为1时,采用了左深树方式进行探测,设置为0时,则采用的是卡特兰树方式进行探测 | 2016年以后的版本建议设置为1,采用新优化器 | 0 | 1 |
更多参数参考:CSDNhttps://mp.csdn.net/mp_blog/creation/editor/123078024
到此文章结束,请耐心阅读~
更多达梦技术资讯,请访问达梦技术社区:
达梦数据库 - 新一代大型通用关系型数据库 | 达梦云适配中心
https://eco.dameng.com/