来自 技术 2019-03-15 的文章

Percona-Toolkit系列之pt-ioprofile数据文件IO监控利器

1.pt-ioprofile

做数据库运维的兄弟们常常遇到这样的问题,iostat -x 1看到某块盘的%util为100%,老大下命令了,立刻给我降下来。其实这个时候我们是很蒙逼的,虽然知道是IO子系统不行,但是不知道从何下手,到底是数据库的那部分操作使IO这么忙,或者说到底是哪个表,哪个数据文件的IO动作最频繁,以及他到底是什么样的系统调用。

pt-ioprofile就是解救大家的神器,pt-ioprofile主要做了两件事情,1.lsof+strace每秒2.对输出结果做聚合计算。输出的内容正是我们想要的,可以帮我们清晰的定位出数据库IO问题所在。输出内容如下:

[mysql@hpc02mysqldata1]$pt-ioprofileSunOct2312:03:06CST2016TracingprocessID3156totalpreadreadpwritewritefdatasyncfsyncopencloselseekfcntlfilename0.8591260.0000000.0000000.0000000.0000000.0000000.8591260.0000000.0000000.0000000.000000/data/mysqldata1/ib_logfile00.7024150.0000000.0000000.0622070.0000000.0000000.6402080.0000000.0000000.0000000.000000/data/mysqldata1/ib_logfile10.0467380.0000000.0000000.0001110.0000000.0000000.0464330.0000740.0000490.0000000.000071/data/mysqldata1/ib_814_837_trunc.log0.0454820.0000000.0000000.0000000.0000000.0000000.0454820.0000000.0000000.0000000.000000/data/mysqldata1/mysql/innodb_index_stats.ibd0.0449660.0420280.0000000.0000000.0000000.0000000.0027060.0000410.0000540.0001080.000029/data/mysqldata1/test/example3.ibd0.0211460.0000000.0000000.0000000.0001240.0210220.0000000.0000000.0000000.0000000.000000/data/mysqldata1/mysql-bin.0000530.0160220.0154860.0000000.0000000.0000000.0000000.0005360.0000000.0000000.0000000.000000/data/mysqldata1/undo0010.0053850.0000000.0000000.0019270.0000000.0000000.0034580.0000000.0000000.0000000.000000/data/mysqldata1/xb_doublewrite0.0021020.0000000.0000000.0000000.0000000.0000000.0021020.0000000.0000000.0000000.000000/data/mysqldata1/ibdata10.0007140.0000000.0000000.0000000.0000000.0000000.0007140.0000000.0000000.0000000.000000/data/mysqldata1/mysql/innodb_table_stats.ibd0.0006120.0000000.0000000.0000000.0000000.0000000.0006120.0000000.0000000.0000000.000000/data/mysqldata1/undo0020.0005000.0000500.0001840.0000000.0000000.0000000.0000000.0000760.0000640.0001260.000000/data/mysqldata1/test/example3.frm0.0000960.0000000.0000520.0000000.0000000.0000000.0000000.0000280.0000160.0000000.000000/dev/urandom0.0000920.0000000.0000000.0000000.0000920.0000000.0000000.0000000.0000000.0000000.000000/data/mysqldata1/mysql_general.log

是不是很棒,列表中的数字的单位都是时间s(后面给大家介绍其他输出单位)。这些输出都是底层系统调用,我们一列一列的来看。

total:该列是对后面所有列相加得到的和。

read/write:read系统调用从文件描述符fd所代指的打开文件中读取/写入数据,通常会配合lseek系统调用来使用,首先使用lseek来定位偏移量,然后进行read/write操作。

ssize_tread(intfd,void*buf,size_tcount);ssize_twrite(intfd,void*buf,size_tcount);

pread/pwrite:

ssize_tpread(intfd,void*buf,size_tcount,off_toffset);ssize_tpwrite(intfd,constvoid*buf,size_tcount,off_toffset);

该系统调用让我们在fd文件的offset处开始读取/写入,读取count个字节,并将这些数据放入*buf中,但是不改变文件文件的当前偏移量。那么pread和read,pwrite和write有何区别呢?

上图中我们假设文件偏移量刚开始敲好就在offset处,也就是说pread不改变文件原由的偏移量。那么write和pwrite的区别也是类似的,pwrite主要使用在多线程并发读写文件的场景,多个线程同时读写文件彼此不受影响。

fdatasync/fsync:

1.fsync=数据+元数据(属主,属组,文件权限文件大小,文件链接) #include int fsync(int fd); fsync的功能是确保文件fd所有已修改的内容已经正确同步到硬盘上,该调用会阻塞等待直到设备报告IO完成。 除了同步文件的修改内容(脏页),fsync还会同步文件的描述信息(metadata,包括size、访问时间st_atime & st_mtime等等),因为文件的数据和metadata通常存在硬盘的不同地方,因此fsync至少需要两次IO写操作,变向随机IO.

2.fdatasync=数据fdatasync,放宽了同步的语义以提高性能:#include int fdatasync(int fd);

fdatasync的功能与fsync类似,但是仅仅在必要的情况下才会同步metadata,因此可以减少一次IO写操作。举例来说,文件的尺寸 (st_size)如果变化,是需要立即同步的,否则OS一旦崩溃,即使文件的数据部分已同步,由于metadata没有同步,依然读不到修改的内容。而最后访问时间(atime)/修改时间(mtime)是不需要每次都同步的,只要应用程序对这两个时间戳没有苛刻的要求,基本无伤大雅。

open/lose/seek:这是最基本的三种文件系统调用,分别是openda打开文件描述符,close是关闭文件描述符,lseek是改变文件偏移量。这里不再赘述,毕竟不是讲系统编程.

fcntl:函数可以改变已打开的文件性质,较复杂,有兴趣可自行研究。

filename:对应的数据文件。

根据以上采集的信息,我们可以很快分析出数据库到底在哪部分造成了IO子系统瓶颈

2.常用配置

1.60s内数据库有IO活动的文件产生的各种系统调用次数[ampmon@vq23ucmd02~]$pt-ioprofile--profile-process=mysqld--run-time=60--save-samples=/app/ampmon/mysql_ioprofile.txt--group-by=filename--cell=count--aggregate=sumSunOct2314:14:33CST2016TracingprocessID16676totalpreadreadpwritewritefsynclseekftruncatefilename23164000115812115810/data/smp/mysql/data/master.info1991703949012018139490/data/smp/mysql/data/vq23ucmd02-relay-bin.0000633755023002670317385/tmp/ML23MkEh24590002459000/data/smp/mysql/data/mysql-bin.000021166700160506200/data/smp/mysql/data/ib_logfile265900327033200/data/smp/mysql/data/ibdata1183200018100/data/smp/mysql/data/snc_amp/trends_uint.ibd171300016800/data/smp/mysql/data/snc_amp/history_uint.ibd121000012100/data/smp/mysql/data/snc_amp/history_str.ibd1710001600/data/smp/mysql/data/snc_amp/history.ibd1500001500/data/smp/mysql/data/snc_amp/events.ibd1400001400/data/smp/mysql/data/snc_amp/trends.ibd80000800/data/smp/mysql/data/ib_logfile070000700/data/smp/mysql/data/snc_amp/item_discovery.ibd50000500/data/smp/mysql/data/snc_amp/last_uint.ibd20000200/data/smp/mysql/data/snc_amp/last.ibd20000200/data/smp/mysql/data/snc_amp/items.ibd10000100/data/smp/mysql/data/snc_amp/last_str.ibd10000100/data/smp/mysql/data/snc_amp/hosts.ibd2.60s内数据库中有IO活动的文件,各种系统调用平均每秒产生的数据量[ampmon@vq23ucmd02~]$pt-ioprofile--profile-process=mysqld--run-time=60--save-samples=/app/ampmon/mysql_ioprofile.txt--group-by=filename--cell=sizes--aggregate=avgSunOct2314:11:15CST2016TracingprocessID16676totalpreadreadpwritewritefsynclseekftruncatefilename11551132903711077107867565640/data/smp/mysql/data/vq23ucmd02-relay-bin.0000631638416384000000/data/smp/mysql/data/snc_amp/history_uint.ibd1638416384000000/data/smp/mysql/data/snc_amp/history.ibd1638416384000000/data/smp/mysql/data/snc_amp/events.ibd1380300144440000/data/smp/mysql/data/ib_logfile26501026136023221032010/tmp/ML23MkEh38160003816000/data/smp/mysql/data/mysql-bin.00002164000130000/data/smp/mysql/data/master.info

以上两份信息我是从一个生产库的备库上采集的, 很显然,现在relay-log是系统中IO消耗最大部分。

更多组合请自行研究,解释下参数:

--aggregate:sum|avg。可以算平均值和总和

--cell:count|sizes:times。可以算系统调用次数,系统调用传输数据量,系统调用耗费的时间

--group-by:all|filename|pid。聚合方式,所有聚合在一起还是按照文件聚合

--profile-process:mysqld进程名

--run-time:采集时间

--save-samples:将输出保存到文件,供后续分析。

标签:   vb编程语言代码      asp销售单价   
上一篇:程序员的自我修养系列(四):图形化表达 - 敏
下一篇:没有了