内存数据库专题之数据库性能瓶颈分析之IO

简介: 1. 概述   常言道:有数据,有真相。数据库的性能瓶颈分析也是需要拿出具体的数据来的,否则单纯的说谁比谁性能强弱,都是没有说服力和根据的。关于内存数据库和磁盘数据库的性能对比也是如此。内存数据库通过读取内存中的数据来实现读写加速,磁盘数据库通过硬盘IO实现数据读写。

1. 概述

  常言道:有数据,有真相。数据库的性能瓶颈分析也是需要拿出具体的数据来的,否则单纯的说谁比谁性能强弱,都是没有说服力和根据的。关于内存数据库和磁盘数据库的性能对比也是如此。内存数据库通过读取内存中的数据来实现读写加速,磁盘数据库通过硬盘IO实现数据读写。Linux平台提供了专门的工具来时先磁盘IO性能的获取,该工具为hdparm,本文就该工具的使用做一个详细的介绍。

2.命令格式

Usage:  hdparm  [options] [device] ..

3.示例结果

[root@localhost zhangzl]# hdparm -Tt /dev/sda

/dev/sda:

 Timing cached reads:   3820 MB in  2.00 seconds = 1910.72 MB/sec

 Timing buffered disk reads:   42 MB in  3.05 seconds =  13.78 MB/sec

在这里我们就能看到差距来了,1910.72/13.78=138.66,一百多倍的读取差距,还是相当可观的。以上数据是我在虚拟机环境下测试的结果,具体的性能指标因机器配置、性能不同,会有不同,需要自行测试。

4.参数详解

Options:

 -a   get/set fs readahead

 -A   set drive read-lookahead flag (0/1)

 -b   get/set bus state (0 == off, 1 == on, 2 == tristate)

 -B   set Advanced Power Management setting (1-255)

 -c   get/set IDE 32-bit IO setting

 -C   check IDE power mode status

 -d   get/set using_dma flag

 --direct  use O_DIRECT to bypass page cache for timings

 -D   enable/disable drive defect management

 -E   set cd-rom drive speed

 -f   flush buffer cache for device on exit

 -g   display drive geometry

 -h   display terse usage information

 -i   display drive identification

 -I   detailed/current information directly from drive

 --Istdin  read identify data from stdin as ASCII hex

 --Istdout write identify data to stdout as ASCII hex

 -k   get/set keep_settings_over_reset flag (0/1)

 -K   set drive keep_features_over_reset flag (0/1)

 -L   set drive doorlock (0/1) (removable harddisks only)

 -M   get/set acoustic management (0-254, 128: quiet, 254: fast) (EXPERIMENTAL)

 -m   get/set multiple sector count

 -n   get/set ignore-write-errors flag (0/1)

 -p   set PIO mode on IDE interface chipset (0,1,2,3,4,...)

 -P   set drive prefetch count

 -q   change next setting quietly

 -Q   get/set DMA tagged-queuing depth (if supported)

 -r   get/set device  readonly flag (DANGEROUS to set)

 -R   register an IDE interface (DANGEROUS)

 -S   set standby (spindown) timeout

 -t   perform device read timings

 -T   perform cache read timings

 -u   get/set unmaskirq flag (0/1)

 -U   un-register an IDE interface (DANGEROUS)

 -v   defaults; same as -mcudkrag for IDE drives

 -V   display program version and exit immediately

 -w   perform device reset (DANGEROUS)

 -W   set drive write-caching flag (0/1) (DANGEROUS)

 -x   tristate device for hotswap (0/1) (DANGEROUS)

 -X   set IDE xfer mode (DANGEROUS)

 -y   put IDE drive in standby mode

 -Y   put IDE drive to sleep

 -Z   disable Seagate auto-powersaving mode

 -z   re-read partition table

 --security-help  display help for ATA security commands


作者:张子良
出处:http://www.cnblogs.com/hadoopdev
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

相关文章
|
29天前
|
存储 关系型数据库 OLAP
TiDB适用场景解析:海量数据存储与高并发读写的利器
【2月更文挑战第25天】随着大数据时代的到来,海量数据存储和高并发读写成为众多企业面临的挑战。TiDB作为一种高性能、分布式的关系型数据库,以其独特的架构和强大的功能,在多个场景中展现出了卓越的性能。本文将详细探讨TiDB在海量数据存储、高并发读写等场景下的适用情况,分析其在不同业务场景中的优势与应用价值。
|
7月前
|
存储 缓存 NoSQL
数据库性能优化中的缓存优化
数据库性能优化中的缓存优化
|
SQL 运维 监控
【巡检问题分析与最佳实践】MongoDB 磁盘IO高问题
阿里云数据库MongoDB的IOPS使用率是一个非常重要的监控指标,IOPS使用率达到或接近100%后容易引起业务响应缓慢,甚至导致业务不可用的情形。一般云数据库厂商为了避免宿主机出现IO争抢,会使用Cgroup等技术进行实例间的IO隔离和IOPS限制,即不同规格的实例配置对应不同的IOPS使用上限。
【巡检问题分析与最佳实践】MongoDB 磁盘IO高问题
|
存储 Cloud Native 测试技术
【数据库】存算分离之minio IO测试(一)
【数据库】存算分离之minio IO测试(一)
252 0
【数据库】存算分离之minio IO测试(一)
|
存储 监控 AliSQL
RDS AliSQL 面向 Binlog 的性能优化大揭密(上)—— 极致 IO 优化
RDS MySQL使用AliSQL内核,为用户提供了MySQL所有的功能,同时提供了企业级的安全、备份、恢复、监控、性能优化、只读实例、Serverless等高级特性
3300 3
RDS AliSQL 面向 Binlog 的性能优化大揭密(上)—— 极致 IO 优化
|
SQL JSON 关系型数据库
扩展我们的分析处理服务(Smartly.io):使用 Citus 对 PostgreSQL 数据库进行分片
扩展我们的分析处理服务(Smartly.io):使用 Citus 对 PostgreSQL 数据库进行分片
277 0
扩展我们的分析处理服务(Smartly.io):使用 Citus 对 PostgreSQL 数据库进行分片
|
存储 SQL 缓存
内核干货 | 数据库存储引擎如何利用好CPU缓存?
本文探讨如何优化X-Engine中DataBlock内部的记录编码格式,以降低在DataBlock中查找单条记录时的CPU cache miss次数,最终目标是提升DataBlock点查询性能。
797 0
内核干货 | 数据库存储引擎如何利用好CPU缓存?
|
SQL 运维 关系型数据库
MySQL运维系列 之 如何快速定位IO瓶颈
MySQL的瓶颈,一般分为IO密集型和CPU密集型 CPU出问题的情况比较少,最近就遇到过一次比较大的故障,这个话题后面会有一篇专题介绍 今天主要聊聊IO密集型的应用中,我们应该如何快速定位到是谁占用了IO资源比较多 背景 环境1.
6169 0
|
canal 缓存 关系型数据库
高并发先操作数据库,还是先操作缓存?5 个方案告诉你!
在分布式系统中,缓存和数据库同时存在时,如果有写操作的时候,先操作数据库还是先操作缓存呢? 先思考一下,可能会存在哪些问题,再往下看。下面我分几种方案阐述。
高并发先操作数据库,还是先操作缓存?5 个方案告诉你!
|
关系型数据库 分布式数据库 数据库