Galera集群server.cnf参数调整--Innodb存储引擎内存相关参数(一)

在innodb引擎中,内存的组成主要有三部分:缓冲池(buffer pool),重做日志缓存(redo log buffer),额外的内存池(additional memory pool)。

【参数1:innodb_buffer_pool_size】

主要用来缓存innodb表的索引、数据,是插入数据时的缓冲。

/*Innodb存储引擎的缓存机制和Myisam最大的区别就在于他不紧可以缓存索引,还会缓存实际的数据。所以相同的物理环境,Innodb对磁盘IO的优化会优于Myisam。*/

当系统上线后,我们可以通过Buffer Pool实时状态,来做进一步的分析:

从这里我们能看出Read命中的情况:

Read命中率=(Innodb_buffer_pool_read_requests-Innodb_buffer_pool_reads)/Innodb_buffer_pool_read_requests

配图是默认的情况,根据公式就是(该db很空闲,但参考机器性能,及mysql手册推荐值,仍可对该参数进行调整。)

Innodb_buffer_pool_reads的数值统计是通过物理读来获取的数据。

Innodb_buffer_pool_pages_free这个数值需要关注,空闲页的大小。

Innodb_buffer_pool_pages_flushed刷新页请求数量。

Innodb_buffer_pool_read_ahead预读入缓存的页数量。

Innodb_buffer_pool_wait_free等待空闲页的次数(关注)。

/*当用户需要读取一个页面,或者请求分配一个新页面进行插入,需要调用buf0flu.cc工程中的buf_LRU_get_free_block函数进行页面的分配。

首先尝试从buffer pool中的free list分配新页面,若free list中没有空闲页,同时当前系统正在进行flush,等待flush结束后进行分配;若free list中没有空闲页,不在flush,遍历LRU链表,寻找非脏页面置换到free list,然后刷新Innodb引擎统计,实现pages的释放。*/

innodb_buffer_pool_size

Innodb_buffer_pool_size默认为128M,若该物理机为mysql服务器,若使用的引擎只有innodb,可以考虑配置为物理内存的50%-70%。

在mysql的conf中进行修改

# vim /etc/my.cnf.d/server.cnf

innodb_buffer_pool_size=80G

这个值如果调整过大,带来的IO性能上的优化将不会很明显,反而会造成cpu的压力过高。

【参数2:Innodb_buffer_pool_instances】

Innodb_buffer_pool_instances将Innodb_buffer_pool划分到不同的instance中,每个instance独立进行LRU Flush,有独立的mutex控制会避免内存锁的争用(大的并发状态下优化效果明显)。

/*注:与Innodb_buffer_pool_size参数相结合,每个instance的size确保不小于1G。一般设置也参考cpu个数(小于或等于cpu个数即可)。*/

【参数3:Innodb_additional_mem_pool_size】

这个参数用来设置Innodb存储的数据的目录信息和其他内部数据结构的内存池。

/*一般来讲,应用程序常用的业务表越多,这里配的内存就应该越大,对于稳定的程序,这个参数的大小是稳定的,可以关注错误日志来进行调整。从mysql 5.6.3开始,不再需要这个参数了。

(错误日志[Warning] option ‘innodb_additional_mem_pool_size‘: signed value 512000 adjusted to 524288)。*/

在示例中走的是默认配置,默认配置是8M。

Mysql手册中对于2G内存时推荐设置为20M。一般,设置过大会造成物理内存浪费,可以在上线一段时间内密切关注日志,进行参数调整。

在db中进行调整,调整为20M。

时间: 2024-11-09 00:22:12

Galera集群server.cnf参数调整--Innodb存储引擎内存相关参数(一)的相关文章

Mysql技术内幕——InnoDB存储引擎

一.mysql体系结构和存储引擎 1.1.数据库和实例的区别 数据库:物理操作系统或其他形式文件类型的集合.在mysql下数据库文件可以是frm,myd,myi,ibd结尾的文件. 数据库实例:由数据库后台进程/线程以及一个共享内存区组成.数据库实例才是真正用来操作数据库文件的. mysql数据库是单进程多线程的程序,与sql server比较类似.也就是说,Mysql数据库实例在系统上的表现就是一个进程. 1.2.mysql的体系结构 mysql由连接池组件.管理服务和工具组件.sql接口组建

MySQL InnoDB存储引擎之锁

概念: 锁是用来管理对共享文件的并发访问.innodb会在行级别上对数据库上锁.不过innodb存储引擎会在数据库内部其他多个地方使用锁,从而允许对不同资源提供并发访问.例如操作缓冲池中的LRU列表,删除,添加,移动LRU列表中的元素,为了保证一致性,必须有锁的介入.MyISAM引擎是表锁,而InnoDB提供一致性的非锁定读.行级锁,且行级锁没有相关额外的开销. 锁 table-level locking(表级锁) 整个表被客户锁定.根据锁定的类型,其他客户不能向表中插入记录,甚至从中读数据也受

MySQL InnoDB 存储引擎探秘

在MySQL中InnoDB属于存储引擎层,并以插件的形式集成在数据库中.从MySQL5.5.8开始,InnoDB成为其默认的存储引擎.InnoDB存储引擎支持事务.其设计目标主要是面向OLTP的应用,主要特点有:支持事务.行锁设计支持高并发.外键支持.自动崩溃恢复.聚簇索引的方式组织表结构等. 体系架构 InnoDB存储引擎是由内存池.后台线程.磁盘存储三大部分组成. 线程 InnoDB 使用的是多线程模型, 其后台有多个不同的线程负责处理不同的任务 Master Thread Master T

Innodb 存储引擎

Innodb体系结构 单进程,多线程模式. 一块innodb内存池+多个后台线程,管理着innodb存储引擎. 1. 后台线程 10个IO线程 1个master thread 1个lock监控线程 1个错误监控线程 IO线程相关配置参数 innodb_file_io_threads innodb_read_io_threads innodb_write_io_threads 2. 内存 innodb存储引擎内存由一下几个部分组成 缓冲池 重做日志缓冲池 额外的内存池 参数 innodb_buff

MySQL InnoDB存储引擎undo redo解析

本文是介绍MySQL数据库InnoDB存储引擎重做日志漫游 00 – Undo Log Undo Log 是为了实现事务的原子性,在MySQL数据库InnoDB存储引擎中.还用Undo Log来实现多版本号并发控制(简称:MVCC). - 事务的原子性(Atomicity) 事务中的所有操作,要么所有完毕,要么不做不论什么操作.不能仅仅做部分操作. 假设在运行的过程中发生 了错误,要回滚(Rollback)到事务開始前的状态,就像这个事务从来没有运行过. - 原理 Undo Log的原理非常ea

mariadb galera集群配置

最近在看一些关于数据库的资料,从最开始的mysql的主从复制到mysql的双主+heartbeat实现mysql的高可用再到mysql+drbd+heartbeat实现底层数据同步的双主高可用再到mysql_mmm+amoeba实现双主多从的高可用和负载均衡以及读写分离,再到后来发现mysql自从被Oracle收购后已经越来越走向了封闭,更新也不如以前频繁,并且新版的mysql已经不支持GPL协议了...感觉mysql已经在Oracle手中渐渐没落了...后来发现了一个更好的替代方案那就是mar

MariaDB Galera集群部署--技术流ken

Galera集群介绍 MariaDB集群是MariaDB同步多主机集群.它仅支持XtraDB/ InnoDB存储引擎. 主要功能 同步复制 真正的multi-master,即所有节点可以同时读写数据库 自动的节点成员控制,失效节点自动被清除 新节点加入数据自动复制 真正的并行复制,行级 用户可以直接连接集群,使用感受上与MySQL完全一致 优势 因为是多主,所以不存在Slavelag(延迟) 不存在丢失事务的情况 同时具有读和写的扩展能力 更小的客户端延迟 节点间数据是同步的,而Master/S

使用GTID给Galera集群做数据库异步复制

一.为什么要做Galera集群异步复制 Galera集群解决了数据库高可用的问题,但是存在局限性,例如耗时的事务处理可能会导致集群性能急剧下降,甚至出现阻塞现象.而不幸的是,类似报表等业务需求就需要做数据大批量的数据查询操作,为了不影响Galera的集群效率,需要做数据异步复制,产生一个从库来适配耗时的数据操作需求. 由于Galera集群的特殊性,我们不能使用一般的主从复制来实现数据异步复制的要求.集群中每台mariadb都会单独的记录binlog,使得一般的主从配置只能获取到单台数据的变更事件

Consul集群Server模式

Consul集群Server模式 架构示意图 Consul在生产环境下运行模式分为两种:Server模式和Client模式(dev模式属于开发模式不在这里讨论),我们先用Server模式搭建一个Consul集群,示意图如下: Consul Server A.B.C是启动的三个Consul服务运行于Server模式下,其中Consul Server C 是"总指挥",他们的Leader,Consul Server A和B是Follower当"替补",他们都可以提供注册