the notebook of eyu

2015-06-07
oceanbase整理--工具

oceanbase整理--工具

去年,领导一直催让我整理一个排查性能问题和查BUG的文档,我一直拖着,因为很很想到一套体系把所有问题串连起来,而且大部分排查也是出于经验。

前一段时间翻译过一骗很好的性能排查与优化的文章:

  • 性能排查与优化综述
  • CPU性能排查与优化
  • 内存性能排查与优化
  • IO性能排查与优化

最近又读了一篇关于linux常用工具的文章linux-performance-monitoring-tools,感觉不错,结合自己的经历,描述一下,可能不全面,以后再补充。

SA

oceanbase一些重要应用上会部署sar后台运行,主要是为了分析一天的网络和磁盘性能数据,方便性能问题提成查。曾经一个合并问题,导致网络流量过大的问题,就是通过sar来辅助排查的。不过sar使用的时候,会写大量记录,所以最好选择一个单独的盘来用,不要影响正常的业务磁盘。

sar是sysstat包的一部分,sar可以做两件事情

  • 监控系统实时性能(CPU,内存,I/O)
  • 在后台收集数据,分析历史数据来查找性能瓶颈

sar详细功能说明

  • 收集cpu利用率
  • 单个cpu统计
  • 内存使用率
  • swap使用率
  • 系统的全部IO活动
  • 单个设备的IO活动
  • 上下文切换
  • 运行队列和load
  • 网络状态

sar使用实例

1
2
3
4
5
sar -b 1 3

-b: 报告io状态
1: 每一秒执行一次
3: 总共汇报3次
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-05-11
结束,新的开始

结束,新的开始

想了很多,还是选择在OB五周年的时候离开。感谢OB团队的三年,学到了很多,经历了很多。

回想三年,更多的是感恩。

感谢楚材,阳老师在我错过校招的时候,给了我面试的机会,进了这个NB的团队。

感谢郁白师兄,在我什么也不懂的情况了,耐心的给我制定学习计划。

感谢山哥,容忍我几个月不写周报,替我抗了一堆BUG。

感谢庭哥,当解决问题迷茫时,总能给我指明方法。

感谢千路,从来没遇到过像这么认真负责的领导,做离开的决定的时候,感觉对不住他。

感谢天街,舜哥,真爷给了我这么多排查线上问题的机会,这是我这三年最难忘的一次经历,每次经历,总能让我获得难得的成就感,满足感。

感谢逸鸣,总能找到一些共同的话题,让我感受到大学一起开黑打游戏的兴奋。

感谢酒满,天街,可以一起喝酒的时光是多么的快乐。

感谢符风,每天可以蹭你的车回家,可以一起去吃KFC。

感谢OB篮球队的同学们,一起打篮球,喝酒的时光是多么的快乐;感谢你们把我推荐我队长,即使目的是让我早去占场地。。。

离开,虽有些不舍,但是终究是要离开,谁又说的清楚。

先休整一段时间,再决定下一步该怎么走。一段旅程的结束,也是一段新的旅程的开始。

2015-05-11 于回杭州的火车
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-12-01
linux系统性能监控与优化--io

linux系统性能监控与优化--io

IO子系统一般是linux系统中最慢的部分。一个原因是它距离CPU的距离,另一个原因是它的物理结构。访问磁盘的时间与访问内存的时间是7天与7分钟的区别。linux kernel要尽量减少磁盘IO。

Read More

2014-12-01
linux系统性能监控与优化--network

linux系统性能监控与优化--network

latency,collisions,congestion,packet corruption

查看网卡参数

ethtool eth0

查看本地网上吞吐量

iptraf -d eth0

性能测试

netperf/iperf

分析独立的连接

tcptrace

Read More

2014-11-30
linux系统性能监控与优化--简介

linux系统性能监控与优化--简介

最近几年做了很多性能优化的事情,但是一直没有形成一套理论,也没有很好的形成一个好的排查问题的流程,每次做优化,大多是经验式的查找,最近看了一下这本书《linux system and performance monitoring》,写的太好了,仔细看了一遍,下面的是读书笔记和个人的一些体会。

性能优化

性能优化的过程就是打到系统的瓶颈,并且消除这处瓶颈的过程。对于操作系统来说,就是在4个子系统(CPU,Memory,IO,Network)之间达到平衡和取舍。
不同子系统之间会相互影响,某一个子系统过高的使用率,会导致问题:

1)大量的页调入请求会填满队列
2)网卡设备上大量的吞吐,会导致CPU load过高
3)管理空闲内存队列也会消耗CPU
4)大量的磁盘写请求,会消耗CPU和IO带宽

应用类型

要找到系统瓶颈,应该先了解应用类型:

1)IO密集型
大量消耗内存和存储系统,对CPU和网络(存储系统是基于网络的除外)要求不高。这种应用使用CPU来发起IO请求,然后进入sleep状态。比如数据库。

2)CPU密集型
需要CPU进行批处理和数学计算。比如:web servers,mail servers,rendering server

找系统性能瓶颈的方法

最好的找性能瓶颈的方法,是先对在正常满足性能要求的情况下,统计系统的各个参数,做为baseline.
然后在高压力下,当系统性能满足不了需求时,与baseline进行对比,找到性能问题。

常用的性能监控工具

Read More