the notebook of eyu

2016-06-28
青海湖骑行

青海湖骑行

记得大学生就打算去青海湖骑行,只是经济上不允许,最终也没成行,这次也只是一次偶然的机会向几个朋友提起,然后大家的想法不谋而合,一次说走就走的旅行。

4天骑完全程,共360公理,经历过冰雹,大雨,强风,暴晒,一日四季,无数个上坡,下坡,不得不说,青海是我唯一一个来了,而没有后悔的地方。

Read More

2016-06-21
数据库自增列

数据库自增列

简介

自增列的主要目的是自动生成行的唯一ID,对于不同的数据库或是存储引擎,还有一些特别的意义。

大部分数据库的使用者会使用自增列做为聚簇索引,以innodb为例,在内存中数据存放到B+Tree的一个页子结点上,数据按照主键顺序存放,每次插入数据时,会根据主键插入适当的位置。如果使用自增ID,数据插入相当于顺序插入,不会移动现有数据的位置;如果不使用自增ID,则有可能为了插入数据而移动数据,如果内存页已经回写的磁盘,则需要从磁盘上读回来,同时,频繁的移动和分页,会带来大量的碎片。

自增ID,一般使用一个整数来表示,而其它的一些方案,如UUID等一般会使用一个长字符串来表示(一般为16字节),存储空间和网络都会有一些浪费。

现在业务中接触到的很多客户,可能是习惯或是方便,一般不指定与某个有实际意义的字段为主键,而是使用自增列,其它维度查询列建索引,如果存储系统接口不支持的话,它们就会用UUID来代替,不会考虑与之相关的一些问题。

本文主要是了解一下自增列的实现原理

Read More

2016-04-11
golang的map的元素遍历为什么是随机的

golang的map的元素遍历为什么是随机的

golang的map的元素遍历是随机的?为什么这样做?怎么做的?

为什么这样做

大部分的编程语言,对于固定的数据集合,map的元素遍历是顺序,但是golang为什么要搞成随机的呢?

golang的设计哲学是:没有过于灵活地允许马马虎虎的代码,Go强迫你从一开始就把事情弄得直接一点。Go程序员参考里面说如果他们的程序可以编译(而且代码符合Go的风格),那么代码有很大的可能可以像预期的那样工作,这种模模糊糊却不错的感觉也有Go严谨性的贡献。没有诡异的类型bug,丢失分号等等错误。

尤其是,在Andrew的参考文章中,他指出这是Go的设计者们所作出的改变。他们不再允许人们依赖于那些破破烂烂的假设。我最痛恨的一点就是那些破烂的,到处是bug的功能(这发生在交付的产品中,或者是编程语言,等等很多地方),通过权衡,接受,从而变成了一个特性,另外尝试修复这些”特性”真的是很恶心。

怎么实现

如果每输出一个元素都随机的话,一是性能问题,而且还要标记某个元数是否访问到。所以很可能是随机生成一个访问点然后,先将当前桶便历完,然后顺序扫描下一个桶(猜测的,没有看源码,不一定正确),看下面程序的运行结果:

Read More

2016-03-10
大学毕业后的第三次室友聚会

大学毕业后的第三次室友聚会

大学毕业后的第三次室友聚会

Read More

2015-06-05
oceanbase整理--ssd使用

oceanbase整理--ssd使用

在0.3版本的时候,线上的系统还是大部分用的sata,sas盘,后来由于读写速度的问题(主要是每日合并的要求),到0.5版本的时候,大部分线上系统已经采用了SSD。

大部分系统是这样的情况,如果使用sata盘,那么性能瓶颈在磁盘,如果使用ssd,性能瓶颈在CPU(性能优化还没做的足够好的表现)
关于SSD的基础知识的介绍,见以前的博客:

  • linux优化使用ssd的方法
  • SSD基础知识
  • SSD顺序写对随机读的影响
  • IO调度算法
Read More

2015-06-04
oceanbase整理--每日合并

oceanbase整理--每日合并

oceanbase本质上还是基于lsm-tree(http://www.trueeyu.com/?p=138),简单的说就是将数据的更改hold内存中,当达到指定的阈值后,再批量写到磁盘与已有的数据做合并。

这个设计是基于这个假设:写入远远大于读取,insert量大,update量小,这种方法可以优化写,但没有显著降低读,因为大部分最新的数据都在内存里面,读取速度会非常快。
理论上是很简单的,但是一旦用在实际的场景中确出了很多问题,夸张的说,做为存储组的同学,1/3的时间应该都花在处理合日合并相关的问题上。

基础架构

1.0之前的oceanbase架构,都是分为4个server,chunkserver(存储静态数据),updateserver(存储动态数据),mergeserver(sql处理,并发查询等),rootserver(元数据管理),这个4个server都可以分别部署在不同的机器上,写入是一个单点。

每日合并的过程实际上就是chunkserver(简写为cs)的老版本的静态数据与updateserver(简写为ups)的动态数据进行合并,生成新版本的静态数据,写到cs。

下面就基于这个架构引发的一系列问题来描述。

ups内存不足

ob所有数据的更改都是要写到ups的,所以ups的内存一旦用完,则会阻塞应用的写入,这是不可以接受的。所以当ups内存到达一定程度后,就要触发每日合并,将动态数据与静态数据进行合并,合并完成后将相应的内存释放。

Read More

2015-04-15
find_vma性能问题分析

find_vma性能问题分析

这个问题去年线上系统发生的一个严重的性能问题,导致了大量用户的访问超时。今天花了点时间又看了下,linux内核线性地址空间相关的知识,再复盘下这个问题,温故而知新。

现像

业务做活动期间,系统访问请求很大时,系统load非常高,其中几台机器的load到达70。

磁盘没有成为瓶颈,而分析CPU load时,发现find_vma()这个函数占用了很大的CPU性能。

Read More

2015-03-18
gettimeofday优化

gettimeofday优化

介绍

很多应用(数据库)频繁执行gettimeofday或是其它类似的函数调用,优化这此函数可以提升性能。

Virtual Dynamic Shared Object(VDSO),是一个允许应用在用户空间执行一些kernel活动(不需要通过系统调用),VDSO可以加速gettimofday的执行

原理

VDSO使用自己的getimeofday的定义覆盖glibc的定义(需要通过系统调用访问内核),从而避免了系统调用。

glibc运行库里有VDSO的实现。VDSO复制了一些内核代码(gettimeofday需要的)。rehat5.5允许gettimeofday完全在用户空间执行,不执行系统调用。

VDSO boot参数值:

  • 0 提供精确的时间间隔(微秒),但是会产生大量负载(调用系统调用)
  • 1 稍微有点不精确,但仍是微秒级,负载小。
  • 2 最不精确,毫秒级,负载最小

使gettimeofday with VDSO 生效

默认VDSO是打开的,如果没有打开,可以通过下面这个方式打开:

echo 1 > /proc/sys/kernel/vsyscall64

补充

这个gettimeofday的优化只在64位架构上有(AMD64,Intel64),在x86上没 有

Currently the gettimeofday speed up is implemented only for 64 bit architectures (AMD64 and Intel 64) and is not available

参考资料

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-gettimeofday_speedup.html

Read More

2015-03-12
ext4 dealloc机制

ext4 dealloc机制

ext4引入的一个新技术:延迟磁盘数据块分配

delalloc: ext4在实际将数据库写到磁盘的时候,才会从磁盘上分配块。

nodelalloc: 数据从用户空间复制到page cache时,就会从磁盘上分配块。

XFS,ZFS,btrfs,Reiser4,Ext4都支持这项优化。

Ext3,reiser3不支持。

原理

Delayed allocation plays very nicely with the two previous features mentioned, extents and multiblock allocation, because in many workloads when the file is written finally to the disk it will be allocated in extents whose block allocation is done with the mballoc allocator.

extents(An extent is a contiguous area of storage reserved for a file in a file system, represented as a range)

Read More

2014-11-28
数据库行存储格式

数据库行存储格式

调研的几种数据库的行格式,代码没看,查的文档,可能具体实现并不一致。
几种格式的优缺点,还有待分析。
在oceanbase0.5中,实现的格式太简单,在一些场景下性能差,或是不太方便。
在oceanbase1.0中,现在我打算是写成一个通用的接口,可以以表为单位选择需要的格式,这个有待讨论。

Read More