内存数据库专题之数据库性能瓶颈分析之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
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

相关文章
|
6月前
|
存储 关系型数据库 OLAP
TiDB适用场景解析:海量数据存储与高并发读写的利器
【2月更文挑战第25天】随着大数据时代的到来,海量数据存储和高并发读写成为众多企业面临的挑战。TiDB作为一种高性能、分布式的关系型数据库,以其独特的架构和强大的功能,在多个场景中展现出了卓越的性能。本文将详细探讨TiDB在海量数据存储、高并发读写等场景下的适用情况,分析其在不同业务场景中的优势与应用价值。
|
存储 缓存 NoSQL
数据库性能优化中的缓存优化
数据库性能优化中的缓存优化
|
SQL 运维 监控
【巡检问题分析与最佳实践】MongoDB 磁盘IO高问题
阿里云数据库MongoDB的IOPS使用率是一个非常重要的监控指标,IOPS使用率达到或接近100%后容易引起业务响应缓慢,甚至导致业务不可用的情形。一般云数据库厂商为了避免宿主机出现IO争抢,会使用Cgroup等技术进行实例间的IO隔离和IOPS限制,即不同规格的实例配置对应不同的IOPS使用上限。
【巡检问题分析与最佳实践】MongoDB 磁盘IO高问题
|
1月前
|
Oracle 关系型数据库 Java
数据库的 IO 到底有多慢?
本文通过对比Java程序从Oracle、MySQL数据库读取数据与读取文本文件的性能,揭示数据库IO速度远低于文件读取的现状。在相同硬件环境下,读取3000万行记录,Oracle耗时280秒,MySQL耗时380秒,而文本文件仅需42秒。此外,通过SPL实现并行处理,可显著提升读取速度,尤其是在处理大规模数据时。实验还探讨了数据库接口慢的问题及其对性能的影响,提出在追求高性能计算时应尽量避免从数据库读取数据的建议。
|
3月前
|
SQL 关系型数据库 MySQL
(十六)MySQL调优篇:单机数据库如何在高并发场景下健步如飞?
在当前的IT开发行业中,系统访问量日涨、并发暴增、线上瓶颈等各种性能问题纷涌而至,性能优化成为了现时代中一个炙手可热的名词,无论是在开发、面试过程中,性能优化都是一个常谈常新的话题。而MySQL作为整个系统的后方大本营,由于是基于磁盘的原因,性能瓶颈往往也会随着流量增大而凸显出来。
439 0
|
5月前
|
缓存 NoSQL Java
高并发场景下缓存+数据库双写不一致问题分析与解决方案设计
高并发场景下缓存+数据库双写不一致问题分析与解决方案设计
|
6月前
|
SQL 关系型数据库 MySQL
Mysql高可用,索引,事务与调优:提高数据库性能的关键技术
在当今互联网时代,高可用性、稳定性和性能是数据库的三大关键要素。本文将深入探讨Mysql高可用、索引、事务和调优等方面的技术,为读者提供实用的解决方案和经验。
68 0
|
存储 Cloud Native 测试技术
【数据库】存算分离之minio IO测试(一)
【数据库】存算分离之minio IO测试(一)
329 0
【数据库】存算分离之minio IO测试(一)
|
SQL 运维 关系型数据库
MySQL运维系列 之 如何快速定位IO瓶颈
MySQL的瓶颈,一般分为IO密集型和CPU密集型 CPU出问题的情况比较少,最近就遇到过一次比较大的故障,这个话题后面会有一篇专题介绍 今天主要聊聊IO密集型的应用中,我们应该如何快速定位到是谁占用了IO资源比较多 背景 环境1.
6445 0
|
缓存 关系型数据库 MySQL