IO 资源作为目前服务器中最昂贵的资源之一,是目前绝大部分业务系统主要的瓶颈资源,原因就在于服务器相关的硬件资源中IO资源的性能提升是难度最大的。存储的发展步伐远低于内存和CPU的发展。

在数据库管理系统中,IO是十分宝贵的,所以在数据库管理系统中我们希望操作尽可能在内存中完成,如果在一次事务中发生过多的IO就意味着性能的下降。

所以如何保证IO资源的性能最大化也是数据库管理系统优化的重中之重。目前数据库IO调优的主要思路是1、延迟IO,降低频繁IO到来的资源 ,包括使用缓冲池资源等 一次IO中代价最高的部分是寻址所以通过延迟IO可以减少寻址的次数从而提升性能。2、并发,提高一次IO写入的数据量,减少了IO次数,但是总的需要写入的数据量没有减少,这就要求在一次IO中尽可能对的写入数据保证该落盘的落盘。

Kinbase ES 提供了多种IO 资源的优化手段包括:

• 优化数据库内存参数

• 调整 IO 调度策略

• 利用多 IO 设备分担压力

• 优化文件系统挂载方式

• 配置预读 IO 请求队列

优化数据库 I/O 相关参数

fsync

原理:用来设置日志缓冲区刷盘时, 需要确认已经将其写入了磁盘。

如果关闭该功能,那么由操作系统调度 磁盘写的操作, 能更好利用缓存机制, 提高 IO 性能。该性能的提高伴随了数据丢失的风险, 当操作系统或主机 崩溃时, 不保证刷出的日志是否真正写入了磁盘。 应用范围:应依据操作系统和主机的稳定性来配置,一般在追求极限性能是修改。

full_page_writes

原理:full_page_writes (boolean),打开这个选项的时候, 数据库服务器在检查点 (checkpoint) 之后对页面的第 一次写入时将整个页面写到 WAL 里面。这么做是因为在操作系统崩溃过程中可能只有部分页面写入磁盘,

从而导致在同一个页面中包含新旧数据的混合。在崩溃后的恢复期间, 由于在 WAL 里面存储的信息不够完 整, 无法完全恢复该页。把完整的页面影像保存下来就可以保证正确存储页面, 代价是增加了写入 WAL 的数 据量。因为 WAL 重放总是从一个检查点开始的, 所以在检查点后每个页面第一次改变的时候做 WAL 备份就 足够了。因此, 一个减小全页面写开销的方法是增加检查点的间隔参数值。把这个选项关闭会加快正常操作 的速度, 但是可能导致系统崩溃或者掉电之后的数据库损坏, 它的危害类似关闭 fsync , 只是比较小而已。 应用范围:关闭可以改善性能,但是需要一定条件,如果有减小部分页面写入风险的硬件支持 (比如电池供 电的磁盘控制器) 或者文件系统支持 (比如 ReiserFS 4), 并且他们可以把风险降低到一个可以接受的低范畴, 那 么可以关闭这个选项。如果为了极限性能,并且是 IO 的问题,可以考虑使用。

commit_delay

原理:事务提交和日志刷盘的时间间隔,

应用范围:如果并发的非只读事务数目较多, 可以适当增加该值, 使日志缓冲区一次刷盘可以刷出较多的事 务, 减少 IO 次数, 提高性能。需要和 commit_sibling 配合使用。

commit_siblings

原理:触发 commit_delay 的并发事务数, 只有系统的并发活跃事务数达到了该值, 才会等待 commit_delay 的时 间将日志刷盘, 如果系统中并发活跃事务达不到该值,commit_delay 将不起作用, 防止在系统并发压力较小的 情况下, 事务提交后空等其他事务造成时间的浪费。 应用范围:应根据系统写的负载配置,并发越大就配置越大,和 commit_delay 一起使用。

checkpoint_timeout

原理:两个相邻检查点之间的时间间隔,用于刷数据到磁盘。 应用范围:根据系统写的负载设置, 一般不要太频繁。可以和后台写线程配置相关参数配合使用,一般 pk 测 试过程中会设置的很长(如果内存够的话),可以不用频繁刷。

bgwriter_delay

原理:后台写线程的自动执行时间, 后台写线程的作用是将 shared_buffer 里的脏页面写回到磁盘, 减少

checkpoint 的压力。默认是 200ms。 应用范围:如果系统数据修改的压力一直很大, 建议将该时间间隔设置小一些, 以免积累的大量的脏页面到

checkpoint, 使 checkpoint 时间过长 (checkpoint 期间系统响应速度较慢)。tpcc 一般设置 10ms 可以减少压力;

bgwriter_lru_maxpages

原理:后台写线程一次写出的脏页面数,默认 100 个页面。 应用范围:依据系统写的负载修改,比如 tpcc,因为时间间隔短,一次写入的少页面少,比如设置 75。

bgwriter_lru_multiplier

原理:后台写线程根据最近服务线程需要的 buffer 数量乘上这个比率估算出下次服务线程需要的 buffer 数量,

再使用后台写进程写回脏页面, 使缓冲区能使用的干净页面达到这个估计值。默认是 2.0

应用范围:应根据系统写负载来配置。

调整 IO 调度策略

采用合适的磁盘调度算法,IO 调度策略一般包括:CFQ,Deadline,NOOP 和 Anticipatory 。 对于机械磁盘来说,deadline 是数据库的最佳选择,比如 tpcc 一般采用 deadline。固态硬盘一般可以不做调整。

调度算法包括

1. CFQ

原理:公平算法原则,对于通用服务器来说通常是最好的选择。它试图均匀地分布对 I/O 带 宽的访问。在多媒体应用, 总能保证 audio、video 及时从磁盘读取数据。同时对于其他各类应 用表现也很好。每个进程一个 queue,每个 queue 按照上述规则进行 merge 和 sort。进程之间

round robin 调度,每次执行一个进程的 4 个请求。 应用范围:默认算法,适用于大部份系统应用,适用于 io 大小非常均匀的场景

2. Deadline

原理:这个算法试图把每次请求的延迟降至最低。该算法重排了请求的顺序来提高性能。使 用轮询的调度器, 简洁小巧, 提供了最小的读取延迟和高的吞吐量。 应用范围:适合小文件读写,跳跃式读写,零散读写,特别适合于读取较多的环境,稍微复 杂点的 OLTP 最好更换为 Deadline

3. NOOP

原理:这个算法实现了一个简单 FIFO 队列。他假定 I/O 请求由驱动程序或者设备做了优化 或者重排了顺序 (就像一个智能控制器完成的工作那样)。 应用范围:在有些 SAN 环境下,这个选择可能是最好选择。适用于随机存取设备, no seek cost,非机械可随机寻址的磁盘。I/O 性能不是瓶颈的时候使用 NOOP,也适用于带有 TCQ

的磁盘。

4. Anticipatory

原理:这个算法推迟 I/O 请求,希望能对它们进行排序,获得最高的效率。同 deadline 不同 之处在于每次处理完读请求之后, 不是立即返回, 而是等待几个微秒,在这段时间内, 任何来 自临近区域的请求都被立即执行. 超时以后, 继续原来的处理. 基于下面的假设: 几个微妙内,

程序有很大机会提交另一次请求. 调度器跟踪每个进程的 io 读写统计信息, 以获得最佳预期.

应用范围:适合大文件读写,整块式,重复读写 (web server),适用于文件服务器 ftp/samba 等, 不适用数据库场景。

磁盘调度算法的设置:

echo deadline >/sys/block/sda/queue/scheduler

将 sda 的调度策略设置为 deadline。 我们也可以直接在/etc/grub.conf 的 kernel 行最后添 elevator=deadline 来永久生效。

总结下来, 机械盘的调度算法建议配置为deadline, 固态盘的调度算法建议配置为NOOP

多 IO 设备分担压力

把数据、日志、索引放到不同的 I/O 设备上,或者使用 RAID 设备,以此来利用多个设备的 IO 能力来分担IO 压力。

优化文件系统挂载

优化挂载文件系统的参数,推荐使用 xfs 和 ext4 文件系统。 挂载 XFS 参数:

(rw, noatime,nodiratime,nobarrier)

挂载 ext4 参数:

ext4 (rw,noatime,nodiratime,nobarrier,data=ordered)

比如:noatime 和 nodiratime ,去掉更新访问的时间。

nobarrier:现在的很多文件系统会在数据提交时强制底层设备刷新 cache,避免数据丢失,称之为 write barriers。 但是,其实我们数据库服务器底层存储设备要么采用 RAID 卡,RAID 卡本身的电池可以掉电保护;要么采 用 Flash 卡,它也有自我保护机制,保证数据不会丢失。所以我们可以安全的使用 nobarrier 挂载文件系统。

• data=ordered:(默认) 文件系统日志区仅存放元数据

• data=journal:把数据与元数据都先写入日志区(安全,慢)

• data=writeback:不按日志区元数据顺序来写数据(不安全,快)

配置预读和 IO 请求队列

主要是指操作系统的预读和排队的大小的调整,主要包括:

1. readahead 预读扇区数调整,预读是提高磁盘性能的有效手段,目前对顺序读比较有效,主要利用数据 的局部性特点。比如在笔者的系统上,通过实验设置通读 256 块扇区性能较优。 调整命令:

echo 256 /sys/block/sdb/queue/read_ahead_kb

2. I/O 请求队列长度(调大能增加硬盘吞吐量,但要占用更多内存):

/sys/block/sdb/queue/nr_requests

调整情况: 比如:随机读取修改 减少预读:/sys/block/sdb/queue/read_ahead_kb,默认 128,调整为 16

增大队列:/sys/block/sdb/queue/nr_requests,默认 128,调整为 512

比如:顺序读取修改 增大预读:/sys/block/sdb/queue/read_ahead_kb,默认 128,调整为 256/512

减少队列:/sys/block/sdb/queue/nr_requests,默认 128,调整为 64/32

优化数据库内存参数

KingbaseES 的内存主要包括共享内存和私有内存两大类,不合理的内存使用可能会带来 IO 问题:如

shared_buffers 过小导致数据换进换出,work_mem 过小导致排序使用临时文件。合理的使用内存参数可以较 好的发挥硬件的能力。 在做内存调整时也需要考虑 KingbaseES 使用的内存不要过大导致 swap。

KingbaseES 使用内存总大小为:

shared_buffers(数据) + wal_buffers(日志)+ maintenance_work_mem(创建索引排序时使用)+ n*work_mem(n 为并发做排序的连接数) + 服务进程上下文使用的内存 (无法精确估计大小) + m*thread_stack_size (thread_stack_size 为进程栈的大小, KingbaseES 默认为 1MB; m 为当前连接数);

在进行内存调整时首先要清楚是哪个部分的内存出现了问题,有针对性的进行参数调整。

共享内存参数

shared_buffers

原理:数据库服务器使用的共享内存缓冲区的数量,主要用于缓存数据,根据需求一般不能设置超过 80% 的 内存,但至少是 20%。 应用范围:数据库本身, 查询的数据量比较大,比较频繁使用到。

wal_buffers

原理:日志缓冲区大小, 共享内存里用于 WAL 数据(日志)的磁盘页面缓冲区的数目。 应用范围:如果单位时间事务的数据修改数据量较大,也就是事务的写比较多的情况,如果 IO 是瓶颈,可 以调整这个值到很大,有很多的缓存后,就不会频繁的写磁盘,降低 IO。缺省值为 8 ,8 个页面是 64k。当 然也可以很小,这个设置只需要大到能保存下一次事务生成的 WAL 数据即可, 因为这些数据在每次事务提 交时都会写入磁盘。

私有内存区参数

work_mem

原理:内部排序和哈希操作可使用的工作内存大小。该内存是在开始使用临时磁盘文件之前使用的内存数目。 应用范围:数据比较多大的情况,主要排序的数据有关系,排序数据越大,设置的就越大,比如 16g 内存,

tpch 测试,单用户 10g 规模数据,设置 2g 的 work_mem。数值以 kB 为单位的, 缺省是 1024(1MB),比如 tpcc 1000warehouse,并发 50 个,设置 20mb 即可。

Note: 对于复杂的查询, 可能会同时并发运行好几个排序或者哈希操作, 每个都会使用这个参数声明的这么多 内存, 然后才会开始求助于临时文件。同样, 好几个正在运行的会话可能会同时进行排序操作。因此使用的总 内存可能是 work_mem 的好几倍。ORDER BY, DISTINCT 和 mergejoin 都要用到排序操作, 而哈希操作在哈希 连接、哈希聚集和以哈希为基础的 IN 子查询处理中都会用到。

maintenance_work_mem

原理:在维护性操作 (比如 VACUUM, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY 等) 中使用的最 大的内存数。 应用范围:在维护性操作 (比如 VACUUM, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY 等)调整 大小,默认是 16MB,比如创建索引的索引数据很大,比如 10g,如果内存允许就可以调整这个参数,一般在 需要创建索引的时候调大,创建完之后再调小。

Note: 因为在一个数据库会话里, 任意时刻只有一个这样的操作可以执行, 并且一个数据库安装通常不会有太 多这样的工作并发执行, 把这个数值设置得比 work_mem 更大是安全的,更大的设置可以改进清理和恢复数 据的速度,但是要避免内存用尽的情况。

KinbaseES 优化之IO优化的更多相关文章

  1. Linux优化之IO子系统监控与调优

    Linux优化之IO子系统 作为服务器主机来讲,最大的两个IO类型 : 1.磁盘IO 2.网络IO 这是我们调整最多的两个部分所在 磁盘IO是如何实现的 在内存调优中,一直在讲到为了加速性能,linu ...

  2. Linux 性能优化之 IO 子系统 系列 图

    http://blog.sina.com.cn/s/articlelist_1029388674_11_1.html Linux 性能优化之 IO 子系统(一) 本文介绍了对 Linux IO 子系统 ...

  3. linux io优化

    场景:xml文件解析入库:并备份 问题:磁盘io异常,经常100%busy: linux io优化方法: 1.修改磁盘挂着参数,修改为writeback模式:对于文件读取频繁的可以设置noatime: ...

  4. Innodb IO优化-配置优化

    作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究. 对于数据库来讲 ...

  5. OpenStack入门篇(五)之KVM性能优化及IO缓存介绍

    1.KVM的性能优化,介绍CPU,内存,IO性能优化 KVM CPU-->qemu进行模拟ring 3-->用户应用 (用户态,用户空间)ring 0-->操作系统 (内核态,内核空 ...

  6. kvm磁盘io优化以及性能测试以及与物理机对比

    ubuntu下kvm的磁盘io性能优化步骤 1.virsh shutdown wcltest2 2.virsh edit wcltest2 <driver name='qemu' type='q ...

  7. Mysql 5.7.18:主从复制,io优化

    #目录 #挂盘#时间同步#master节点,进行如下操作: #下载安装 #初始化 #配置文件 #开机启动 #服务启动 #初始数据库#slave节点,进行如下操作: #下载安装 #初始化 #配置文件 # ...

  8. nginx 的磁盘IO优化

    磁盘IO优化的几个方面 优化读取 Sendfile 零拷贝.内存盘.SSD盘 减少写入 AIO 增大error_log级别的日志 关闭access_log  压缩access_log 是否启用prox ...

  9. IO优化

    Linux性能优化之CPU.内存.IO优化 https://blog.csdn.net/zyc88888/article/details/79027944 iOS的I/O操作 https://www. ...

  10. ACdream OJ 1099 瑶瑶的第K大 --分治+IO优化

    这题其实就是一个求数组中第K大数的问题,用快速排序的思想可以解决.结果一路超时..原来要加输入输出优化,具体优化见代码. 顺便把求数组中第K大数和求数组中第K小数的求法给出来. 代码: /* * th ...

随机推荐

  1. ORACLE查询优化及gather_plan_statistics hint

    查询优化手段和gather_plan_statistics hint: 在10g以后我们可以通过利用gather_plan_statistics提示来了解更多的SQL执行统计信息,具体使用方法如下: ...

  2. 虚拟机ubuntu配置静态IP

    手头搭建了几天虚拟机ubuntu用来做微服务环境的搭建,目前使用的是DHCP分配的网络,每次启动各台服务器的ip都是随机的 管理起来有点乱,所以就要把他们配置成静态的ip.具体操作步骤如下: 我直接用 ...

  3. EnumColorProfiles WcsGetDefaultColorProfile WcsSetDefaultColorProfile的使用

    #include <Windows.h> #include <Icm.h> #include <iostream> #include <string> ...

  4. 硬件开发笔记(十): 硬件开发基本流程,制作一个USB转RS232的模块(九):创建CH340G/MAX232封装库sop-16并关联原理图元器件

    前言   有了原理图,可以设计硬件PCB,在设计PCB之间还有一个协同优先动作,就是映射封装,原理图库的元器件我们是自己设计的.为了更好的表述封装设计过程,本文描述了CH340G和MAX232芯片封装 ...

  5. live555开发笔记(一):live555介绍、windows上msvc2017编译和工程模板

    前言   在pc上搭建流媒体服务器软件,打开视频接受推流,使用live555方案.   live555介绍   Live555是一个为流媒体提供解决方案的跨平台的C++开源项目,它实现了标准流媒体传输 ...

  6. 【Azure 存储服务】存储在Azure Storage Table中的数据,如何按照条件进行删除呢?

    问题描述 如何按条件删除 Storage Table 中的数据,如果Table中有大量的条记录需要删除,Java代码如何按条件删除 Table中的数据(Entity)? (通过Azure Storag ...

  7. 【Azure 服务总线】有何办法可以把原来老环境的Azure Service Bus 配置快速复制到新环境配置,而且原环境不删除

    问题描述 有何办法可以把原来老环境的Azure Service Bus 配置快速复制到新环境配置,而且原环境不删除 问题解答 在通常的做法中,是可以在Service Bus所在的资源组中,通过&quo ...

  8. Nginx-负载均衡系列

    综合架构-负载均衡系列 目录 综合架构-负载均衡系列 一个新的开始 一 代理模块 proxy 2.1 概述 2.2 正向代理用户 2.3 反向代理 2.4 反向代理环境准备 2.5 反正代理指令 二 ...

  9. mybatis查询大批量数据的几种方式

    问题背景 公司里有很多需要跑批数据的场景,这些数据几十万到几千万不等,目前我们采用的是分页查询,但是分页查询有个深度分页问题,上百万的数据就会查询的很慢 常规解决方案 全量查询 分页查询 流式查询 游 ...

  10. inner join on 1=1 在查询中的高级用法

    最近在项目中看到一个查询语句,让我有兴趣去研究.研究.查询语句如下: 重点分析第二个INNER JOIN  ON 1 = 1 这个语句:内连接表示查询两个表的交集,而且ON的条件为 1=1 就表示连接 ...