MySQL数据库InnoDB存储引擎中Adaptive hash index存在问题、Percona改进及一个bug

背景
Adaptive hash index (AHI)是MySQL数据库InnoDB存储引擎中用于加速索引查找的一个结构。InnoDB本身不支持hash索引,所有的索引检索都走B树查询。AHI可以认为是“索引的索引”。当对一个页面的访问次数满足一定条件后,将这个页面的地址存在一个hash表中,下次查询可以直接访问到页面,不需要走B树查询。

问题
天下没有免费的午餐,在加速查询的同时,AHI与其他缓存结构一样,也面临维护的问题。作为一个全局结构,在更新时必然有一个全局锁操作(btr_search_latch),一个查询里面可能会对其作多次加x_lock操作。

Percona的改进
如同Buffer Pool可以用多个instance减少锁冲突,Percona也用类似的策略来处理AHI的锁问题。由于本身就是Hash结构,这个处理既自然又方便。所有的数据节点都必然属于一个索引,AHI就用索引id来作分区的key(block->index->id).计算规则为(index_id % btr_search_index_num), 这个 btr_search_index_num 就是 Percona中引入的只读参数 innodb_adaptive_hash_index_partitions。
全局的btr_search_latch则分为btr_search_index_num 份,AHI中每个block中新增一个成员指向 btr_search_latch_part[i].

FFLIB之FFXML:极简化TinyXml 读取

摘要:

XML是结构化的标记语言,经常被用来做配置文件。由于XML的具有非常强的自描述属性,使用XML的配置文件往往直观易懂。C++中解析XML已经有一些非常成熟的类库可以使用,TinyXml是最受欢迎的解析类库之一。尽管TinyXml已经已经封装了解析细节,但是解析、遍历Xml仍然是稍显繁琐。FFXML针对如下需求对TinyXml做了轻量封装:

  • 只把XML当成配置文件,也就是说,只有对XML的读取操作,在我日工作中,都是用XML当做纯配置文件,把XML当成序列化文件或数据文件的情况少之又少。
  • XML配置文件不会太大,我们假设限制在几千行以内,通常XML配置文件不需要那么大,在这种需求下,的XML的读取效率不是问题,易用性会被放到首位,必须非常容易获取xml中的内容。

FFLIB之FFLUA——C++嵌入Lua&扩展Lua利器

摘要:

在使用C++做服务器开发中,经常会使用到脚本技术,Lua是最优秀的嵌入式脚本之一。Lua的轻量、小巧、概念之简单,都使他变得越来越受欢迎。本人也使用过python做嵌入式脚本,二者各有特点,关于python之后会写相关的文章,python对于我而言更喜欢用来编写工具,我前边一些相关的算法也是用python来实现的。今天主要讲Lua相关的开发技术。Lua具有如下特点:

MySQL数据库的字符集和copy_and_convert 字符集不同导致CPU资源额外消耗

关于copy_and_convert
在对MySQL做业务压力测试的时候,我们在perf结果中发现 copy_and_convert 是一个耗费cpu的操作。这个函数的意思,就是在字符集之间做内容转换。
如果源和目标的字符集相同,就可以直接用memcpy,这显然比做字符集转换(按字节或字长拷贝更快,和节省cpu)

当整个系统是CPU瓶颈时,我们希望能够减少这种cpu消耗。

一次查询涉及的拷贝
如果我们执行一个简单的select语句,会涉及到两部分的内容:metadata和data。MySQL的返回包是能够“自解析”的,也就是说不仅有内容,还有描述信息。这些描述信息我们称为metadata。

在将这两部分信息返回给客户端的时候,就涉及到字符串拷贝,如果源字符集和目标字符集不同,就需要作转换。

进程上下文切换 – 残酷的性能杀手(上)

对于服务器的优化,很多人都有自己的经验和见解,但就我观察,有两点常常会被人忽视 – 上下文切换 和 Cache Line同步 问题,人们往往都会习惯性地把视线集中在尽力减少内存拷贝,减少IO次数这样的问题上,不可否认它们一样重要,但一个高性能服务器需要更细致地去考察这些问题,这个问题我将分成两篇文章来写:

1)从一些我们常用的用户空间函数,到linux内核代码的跟踪,来看一个上下文切换是如何产生的

2)从实际数据来看它对我们程序的影响

另外,关于Cache Line 的测试大家可移步 http://www.cppthinker.com/cpp/9/cpu_cache/

C++ 多进程并发框架FFLIB之Tutorial

 FFLIB框架是为简化分布式/多进程并发而生的。它起始于本人尝试解决工作中经常遇到的问题如消息定义、异步、多线程、单元测试、性能优化等。基本介绍可以看这里:

      http://www.cnblogs.com/zhiranok/archive/2012/07/30/fflib_framework.html

其中之所以特意采用了Broker模式,是吸收了MPI和Erlang的思想。

FFLIB 目前处于alpha阶段,一些有用的功能还需继续添加。但是FFLIB一开始就是为了解决实际问题而生。Broker 即可以以独立进程运行,也可以集成到某个特定的进程中启动。除了这些,FFLIB中使用epoll实现的网络层也极具参考价值。网上有一些关于epoll ET 和 LT的讨论,关于哪种方式更简单,本人的答案是ET。ET模式下epoll 就是一个完全状态机。开发者只需实现FD的read、write、error 三种状态即可。

MySQL数据库中QueryCache的锁模型

有同学在问 MySQL数据库中 QueryCache(QC)的锁是 “全局锁”还是 “表锁”。这里简要说明一下。

1、  QC基本概念

这个是实现在MySQL层(非引擎层)的一个内存结构,基本规则是将满足一定条件的查询结果缓存在内存中,若同样的查询再执行第二次,而且缓存没有失效,则可以直接返回查询结果,无需到引擎获取数据。

几个说明:

a) QC的结构是hash,key为查询字符串的原文,因此若想命中QC,要求查询语句与之前的一模一样,包括大小写必须一致、不能增减空格等等。