云服务器内容精选

  • 开启BackwardIndexScan 表1 参数说明 参数名称 级别 描述 optimizer_switch Global,Session 查询优化的总控制开关。 其中,BackwardIndexScan子控制开关为backward_index_scan,控制是否能使用BackwardIndexScan特性,默认值为ON。 ON:优化器能选用BackwardIndexScan。 OFF:优化器不能选用BackwardIndexScan。 除了使用上述开关来控制BackwardIndexScan特性,还可以使用HINT来实现,语法如下。 在SQL语句执行期间开启Backward Index Scan特性 /*+ set_var(optimizer_switch='backward_index_scan=on') */ : 在SQL语句执行期间关闭Backward Index Scan特性 /*+ set_var(optimizer_switch='backward_index_scan=off') */ :
  • 使用示例 创建表,准备数据。 CREATE TABLE test.hotspot1 ( `id` int NOT NULL primary key, `c` int NOT NULL DEFAULT '0' ) ENGINE=InnoDB; INSERT INTO test.hotspot1 VALUES (1, 1); 打开热点行更新开关。 SET GLOBAL rds_hotspot = ON; 修改隔离级别,AUTOCOMMIT。 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; SET SESSION AUTOCOMMIT = ON; 发起带HOTSPOT关键字的更新。 UPDATE test.hotspot1 SET c=c+1 WHERE id=1 HOTSPOT; 检查热点行更新状态。 SHOW STATUS like "%hotspot%"; 性能测试 测试环境 实例规格:8U32GB、32U128GB E CS 规格:32U64GB 测试环境:华北-北京四 测试工具:sysbench-1.0.18 数据模型: 1张表,1条数据。 8张表,每张表1条数据。 参数配置: rds_hotspot=ON transaction_isolation=READ-COMMITTED max_prepared_stmt_count=1048576 rds_global_sql_log_bin=OFF 测试方法 测试所需数据表定义: CREATE TABLE sbtest (id int NOT NULL AUTO_INCREMENT,k int NOT NULL DEFAULT '0',PRIMARY KEY (id)); 测试语句: UPDATE sbtest%u SET k=k+1 WHERE id=1 hotspot; 测试场景和测试结果 测试场景1:8U32GB实例单个热点行更新 测试结果:所有并发均有不同程度提升,64并发及以下并发提升不明显,128并发及以上并发提升明显,最高提升9.26倍。 测试场景2:32U128GB实例单个热点行更新 测试结果:128并发及以上并发提升明显,最高提升639倍。 测试场景3:32U 128GB实例8个热点行更新 测试结果:256及以下并发无提升,512及以上并发提升效果明显,最高提升78倍。
  • 新增关键字 新增标记语句的关键字如下: 表3 新增关键字 关键字 描述 HOTSPOT 表示开启热点更新功能。 NOT_MORE_THAN 可选项。表示目标值不大于某值。 NOT_LESS_THAN 可选项。表示目标值不小于某值。 上述关键字放置在SQL语句末尾。HOTSPOT必须在最前面,NOT_MORE_THAN和NOT_LESS_THAN没有位置前后的要求。 例如:假设id是主键列,c是int类型列,那么支持以下语法: UPDATE c=c+1 where id=10 HOTSPOT; UPDATE c=c+1 where id=10 HOTSPOT NOT_MORE_THAN 100; // c值不大于100 UPDATE c=c-1 where id=10 HOTSPOT NOT_LESS_THAN 0; // c值不小于0 UPDATE c=c+1 where id=10 HOTSPOT NOT_MORE_THAN 100 NOT_LESS_THAN 0; // c值不大于100,不小于0 UPDATE c=c+1 where id=10 HOTSPOT NOT_LESS_THAN 0 NOT_MORE_THAN 100; // c值不大于100,不小于0 当超过NOT_MORE_THAN或者NOT_LESS_THAN的限制时,会向客户端报如下错误: HOTSPOT field value exceeds limit
  • 参数说明 表1 参数说明 参数名称 参数说明 rds_hotspot 热点行更新优化开关。将其设置为ON将启用热点行更新优化。 rds_hotspot_follower_wait_commit_interval 热点行更新follower事务等待leader事务日志持久化时,进入阻塞前的睡眠时间。单位:微秒。对日志持久化速度慢的实例,建议调大。对于持久化快速的实例,建议设置为0,不休眠直接阻塞。 rds_hotspot_leader_wait_follower_interval 热点行更新leader事务等待follower更新记录的时间单位。单位:微秒。低并发适当调低可以避免性能下降。高并发适当调高可以提升性能。当QPS超过20w时,建议将该值设置为100或者更大。 rds_hotspot_auto_detection_threshold 热点行更新的自动识别功能开关。设置为0表示不启用自动识别功能。设置为非0表示热点行更新的识别阈值。当某个符合热点行要求的行每秒更新次数超过阈值时将启动热点行更新功能。 rds_hotspot_batch_size_lower_limit 每批热点事务大小的建议最小值。每个batch尽可能达到该大小。但是,这并不是严格保证的。当leader发现所有需要等待的follower都已经到达时,batch就进入提交状态。 rds_hotspot_max_memory_size 热点行更新中group和counter占用的内存上限。当group占用的内存超过限制时,将清空group所占用的内存。当counter占用的内存超过限制时,将清空counter所占用的内存。申请新的内存时才会尝试清空旧内存。 rds_hotspot_enable_time_statistics 是否开启热点行更新的时间相关的状态统计功能。将其设置为ON以启用该功能。
  • 原理介绍 GaussDB (for MySQL)热点行更新的架构如下图所示:分为Counter_hash,Group_hash两部分。其中Counter_hash主要用于实现热点行的自动判断。Group_hash是热点行的实际实现部分,由多个Hotspot group组成。每个Hotspot group对应一个热点行,每个Hotspot group由多个batch组成,交替为热点行提供批量提交服务。
  • 约束与限制 GaussDB(for MySQL)实例的内核版本为2.0.54.240600及以上时支持使用该功能。 功能使用约束如下: where条件中只能使用主键或唯一索引的等值匹配,并且只能更新单条记录。否则将绕过优化正常更新。 不允许修改索引列,否则将绕过优化正常更新。 只对修改列为整数的更新生效,否则将绕过优化正常更新。 只允许对热点行记录进行两个元素的加减操作,且第一个元素与等号左侧相等并满足唯一索引等约束,不允许赋值操作。假设c列为待修改列,d为记录的普通列,那么只允许进行类似c=c+1,或者c=c-1的操作,不允许进行c=d+1,c=1+c,c=c+1+1,c=1+c+1等操作。否则将绕过优化正常更新。 只允许对隐式事务生效。即要求AUTOCOMMIT为ON,并且不在BEGIN,COMMIT显示开启的事务中使用。否则将绕过优化正常更新。 需要使用HOTSPOT显式标记热点行更新事务,或者将rds_hotspot_auto_detection_threshold设置为非0,开启热点行更新自动识别功能。否则将绕过优化正常更新。rds_hotspot_auto_detection_threshold的详细用法请见参数说明。 只对RC级别生效。数据库处于其他隔离级别时将绕过优化正常更新。 无法在stored function, trigger以及event中使用,否则将对客户端报如下错误: HOTSPOT hints can not be used in stored function, trigger or event 行为变更: 一个hotspot事务组内,除了执行失败或者在更新阶段killed的事务外,其他事务被按批次集中提交,集中记录redo log和undo log,只能集中提交或者回滚,无法单独回滚。每个批次提交的事务个数为几十到几百个不等。
  • 状态说明 表2 状态说明 状态 说明 Hotspot_total_trx 使用hotspot总事务数 Hotspot_update_errors 更新阶段出错的热点行更新事务,这些出错的事务只会自己更新失败,不会影响其他热点行更新事务的提交。 Hotspot_trx_rollbacked 更新成功,但是由于最终回滚的热点行更新事务数量。当队长(leader)决定回滚时,所有组员(follower)跟着一起回滚。 Hotspot_trx_committed 提交成功的热点行更新事务数量。 Hotspot_batch_size 热点行更新事务分批次提交。该值表示当前批次热点行更新事务的数量。 Hotspot_batch_wait_time 热点行更新按批次持有锁和提交事务。此时间为当前热点行更新批次等待上一批次释放锁的时间,单位微秒。 Hotspot_leader_wait_follower_time 在一个批次中leader需要等待follower完成记录更新,此时间为当前批次leader等待follower的时间,单位微秒。 Hotspot_leader_total_time 当前批次leader的热点行更新事务总时间,单位微秒。 Hotspot_follower_total_time 当前批次某一个follower的热点行更新事务总时间,单位微秒。 Hotspot_follower_wait_commit_time 在一个批次中follower需要等待leader持久化日志,此时间为当前批次某一个follower等待leader持久化日志的时间,单位微秒。 Hotspot_group_counts 每个热点行更新对应一个组,组内事务分批次提交。该值为使用热点行更新的组数。 Hotspot_counter_counts counter用于自动判断热点行更新。当counter中的统计值满足要求时,将会创建group使用热点行更新。该值为counter的总数。
  • warning Warning是操作系统在运行时,检测到需要立即注意的内核问题(issue),而采取的上报动作,打印发生时的调用栈信息。上报后,系统继续运行。 原理 Warning是通过调用WARN、WARN_ON、WARN_ON_ONCE等宏来触发的。 导致Warning的原因有多种,需要根据调用栈回溯,找到调用Warning宏的具体原因。Warning宏并不会导致系统运行状态发生改变,也不提供处理Warning的指导。 触发方法 根据系统调用构造Warning条件。
  • panic Kernel panic是指操作系统在监测到内部的致命错误,并无法安全处理此错误时采取的动作。内核触发到某种异常情况,运行kernel_panic函数,并尽可能把异常发生时获取的全部信息打印出来。 原理 导致异常的原因多种多样,通过异常打印的调用信息,找到调用kernel_panic的原因。常见的原因包括内核堆栈溢出、内核空间的除0异常、内存访问越界、内核陷入死锁等。 触发方法 内核态读0地址。
  • I/O error Linux I/O error报错通常表示输入/输出操作失败,在网卡、磁盘等IO设备驱动异常,或文件系统异常都可能打印这个错误。 原理 错误原因取决于代码执行失败的条件。常见的触发异常的原因是硬件故障、磁盘损坏、文件系统错误、驱动程序问题、权限问题等。例如当系统尝试读取或写入磁盘上的数据时,如果发生错误,就会出现I/O错误。 触发方法 系统读写磁盘过程,拔出磁盘,导致磁盘数据损坏。
  • EXT4-fs error EXT4-fs error是由于ext4格式的文件系统中,文件节点的错误导致。 原理 文件储存的最小存储单位叫做“扇区”(sector),连续多个扇区组成“块”(block)。inode节点储存文件的元信息,包括文件的创建者、创建日期、大小、属性、实际存储的数据块(block number)。EXT4格式的inode信息校验失败会触发EXT4-fs error。 内核ext4校验使用checksum校验inode信息,当出现分区表错误、磁盘硬件损坏时,内核返回-EIO错误码,系统上报EXT4-fs error checksum invalid错误。 触发方法 使用磁盘过程中强行拔盘,重新接入读盘。
  • MCE (Machine Check Exception) Machine Check Exception (MCE) 是CPU发现硬件错误时触发的异常(exception),上报中断号是18,异常的类型是abort。 原理 导致MCE的原因主要有:总线故障、内存ECC校验错、cache错误、TLB错误、内部时钟错误等。不仅硬件故障会引起MCE,不恰当的BIOS配置、firmware bug、软件bug也有可能引起MCE。 MCE中断上报,操作系统检查一组寄存器称为Machine-Check MSR,根据寄存器的错误码执行对应的处理函数(函数实现依赖不同的芯片架构实现)。 触发方法 无人为触发方法,当总线故障、内存ECC校验错、cache错误、TLB错误、内部时钟错误等时会触发MCE。
  • hung task 当内核检测到进程处于D状态超过设定的时间时,上报hung task异常。 原理 进程其中一个状态是TASK_UNINTERRUPTIBLE,也叫D状态,处于D状态的进程只能被wake_up唤醒。内核引入D状态时,是为了让进程等待IO完成。正常情况下,IO正常处理,进程不应该长期处于D状态。 hung task检测进程长期处于D状态的原理,内核会创建一个线程khungtaskd,用来定期遍历系统中的所有进程,检查是否存在处于D状态超过设置时长(默认120秒)的进程。如果存在这样的进程,则打印并上报相关警告和进程堆栈。如果配置了hung_task_panic(通过proc或内核启动参数配置),则直接发起panic。 触发方法 创建内核线程,设成D状态,scheduler释放时间片。
  • page allocation failure page allocation failure是申请空闲页失败时,系统上报的错误。当程序申请某个阶数(order)的内存,但系统内存中,没有比申请阶数高的空闲页,即触发内核报错。 原理 Linux使用伙伴系统(buddy system)内存分配算法。将所有的空闲页表(一个页表的大小为4K)分别链接到包含了11个元素的数组中,数组中的每个元素将大小相同的连续页表组成一个链表,页表的数量为1、2、4、8、16、32、64、128、256、512、1024,所以一次性可以分配的最大连续内存为1024个连续的4k页表,即4MB的内存。 假设申请一个包括256个页表的内存,指定阶数order为6,系统会依次查找数组中的第9、10、11个链表,上一个为空,表示没有此阶数的空闲内存,查找下一个,直到最后一个链表。 如果所有链表均为空,申请失败,则内核上报错误page allocation failure。输出报错信息,描述申请阶数为6的内存页失败: page allocation failure:order:6 触发方法 用alloc_pages连续申请高阶数内存页(例如order=10),不释放,直到申请失败。
  • 背景说明 HCE运行时,不可避免的会出现一些内核事件,例如soft lockup、RCU(Read-Copy Update) stall、hung task、global OOM、cgroup OOM、page allocation failure、list corruption、Bad mm_struct、I/O error、EXT4-fs error、MCE (Machine Check Exception)、fatal signal、warning、panic。本节为您介绍这些内核事件的原理及触发方法。