在专栏之前的几篇文章中,我们总结了缓冲池,缓存页,redo log,undo log,以及数据页和数据行在底层是如何进行存储的,后续介绍了表空间,段,区等概念。这一节比较特殊,讲述的是和Linux有关的交互原理,因为多数的mysql都是部署在linux的服务器上面,本节会简单介绍一下linux是如何处理mysql的请求的,以及linux系统会带来哪些问题
之前文章《Linux服务器性能评估与优化(一)》太长,阅读不方便,因此拆分成系列博文:
相信今天很多的软件工程师使用的都是 Linux 或者 macOS 系统,与 Windows 不同,我们很难看到磁盘碎片整理这一概念,从个人的经验来看,作者在过去七八年没有在 macOS 中整理过磁盘的碎片,你在今天的磁盘工具中也找不到相关的操作,只能通过 diskutil 命令设置某一块磁盘是否开启或者关闭碎片整理。
小文件读写的性能瓶颈是磁盘的寻址(随机读写性能更差),评估的标准是tps。大文件读写的性能瓶颈是带宽,评估的标准是持续的读写速度。Linux可以利用空闲内存作文件系统访问的cache,因此系统内存越大存储系统的性能也越好。
Kafka是大数据领域无处不在的消息中间件,目前广泛使用在企业内部的实时数据管道,并帮助企业构建自己的流计算应用程序。Kafka虽然是基于磁盘做的数据存储,但却具有高性能、高吞吐、低延时的特点,其吞吐量动辄几万、几十上百万,这其中的原由值得我们一探究竟。本文属于Kafka知识扫盲系列,让我们一起掌握Kafka各种精巧的设计。
有关Windows磁盘性能压测,笔者还是强烈推荐使用微软自己开源的压测工具DiskSpd。当然,如果要使用其他磁盘性能压测工具也是可以的,比如:IOMeter(老牌经典)、FIO(更适合Linux)等。
广义上Cache的同步方式有两种,即Write Through(写穿)和Write back(写回). 从名字上就能看出这两种方式都是从写操作的不同处理方式引出的概念(纯读的话就不存在Cache一致性了,不是么)。对应到Linux的Page Cache上所谓Write Through就是指write(2)操作将数据拷贝到Page Cache后立即和下层进行同步的写操作,完成下层的更新后才返回。而Write back正好相反,指的是写完Page Cache就可以返回了。Page Cache到下层的更新操作是异步进行的。
项目需要使用的主板有很多性能需要经过测试之后才能用于开发使用,因此将Linux上一些常用的tools移植进板子进行测试。
背景 计算机硬件性能在过去十年间的发展普遍遵循摩尔定律,通用计算机的CPU主频早已超过3GHz,内存也进入了普及DDR4的时代。然而传统硬盘虽然在存储容量上增长迅速,但是在读写性能上并无明显提升,同时SSD硬盘价格高昂,不能在短时间内完全替代传统硬盘。传统磁盘的I/O读写速度成为了计算机系统性能提高的瓶颈,制约了计算机整体性能的发展。 硬盘性能的制约因素是什么?如何根据磁盘I/O特性来进行系统设计?针对这些问题,本文将介绍硬盘的物理结构和性能指标,以及操作系统针对磁盘性能所做的优化,最后讨论下基于磁盘I/O
通过讲解如何优雅扩容云硬盘,我们了解了云盘连接到服务器上的具体操作过程。那么,如何进一步了解已挂载硬盘的实际性能呢?你或许会疑惑,测试硬盘性能,为什么不能用Linux系统自带的dd工具呢?而且不少人之前都这么用的:
几年以前,我被派去厦门上门去分析一个用户的手机卡顿问题,该用户的手机经常莫名无响应,刷机,恢复出厂都没有用,经过一通分析,原来该用户从熟人店里买到了一张盗版的SD卡(这年头坑的就是朋友),该SD卡读写速度很慢,顺序读写只有20MB/s。那为什么SD卡的读写性能对手机性能影响那么大?当时我的知识水平,只能从对比测试中发现这个问题,然后更换SD卡解决了这个问题,但是无法从原理上解释这种现象。经过那么多年的学习积累,我现在终于可以解释这个问题。
前面系列已经讲完了硬件选型、部署、调优,在上线之前呢需要进行性能存储测试,本章主要讲述下测试Ceph的几种常用工具,以及测试方法。
很多使用过 Kafka 的网友都在鼓吹,Kafka 可以吊打一切其它 MQ。也造成了很多网友都觉得 Kafka 才是牛逼哄哄的存在,给很多在技术选型方面的人造成了误导。
如果你觉得这些问题都很简单,都能很明确的回答上来。那么很遗憾这篇文章不是为你准备的,你可以关掉网页去做其他更有意义的事情了。如果你觉得无法明确的回答这些问题,那么就耐心地读完这篇文章,相信不会浪费你的时间。受限于个人时间和文章篇幅,部分议题如果我不能给出更好的解释或者已有专业和严谨的资料,就只会给出相关的参考文献的链接,请读者自行参阅。
合成测试程序根据统计的真实负载发生规律,如请求的读写比例,大小,频率和分布等信息。建立响应的io存取模型。在测试时产生符合存取模型的io请求序列。发送给存储系统。这类程序包括 IOMeter,IOZone 和 Bonnie++。
应为原文:http://www.ilsistemista.net/index.php/linux-a-unix/6-linux-filesystems-benchmarked-ext3-vs-ext4
计算机的文件系统是一种存储和组织计算机数据的方法,它使得对其访问和查找变得容易,文件系统使用文件和树形目录的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念,用户使用文件系统来保存数据不必关心数据实际保存在硬盘(或者光盘)的地址为多少的数据块上,只需要记住这个文件的所属目录和文件名。在写入新数据之前,用户不必关心硬盘上的那个块地址没有被使用,硬盘上的存储空间管理(分配和释放)功能由文件系统自动完成,用户只需要记住数据被写入到了哪个文件中。
在我之前的文章:《探讨 Linux 的磁盘 I/O》中,我谈到了 Linux 磁盘 I/O 的工作原理,我们了解到 Linux 存储系统 I/O 栈由文件系统层(file system layer)、通用块层( general block layer)和设备层(device layer)构成。
dd 也是我们经常使用到的磁盘测试工具,Linux服务器装好系统之后,想要知道硬盘的读写是否能满足服务的需要,如果不满足硬盘的IO就是服务的一个瓶颈。我们可以使用dd命令简单进行测试,更为专业的测试可以使用上面描述的fio 工具:
最近一位小伙伴去某滴面试,在第二面的时候遇到了这个问题:说”请你简单说一下,Kafka为什么这么快?“,然后,这位小伙伴努力在大脑里检索了很久,没有回答上来。
在Linux环境中,了解存储/磁盘I/O性能对于评估系统性能和优化存储子系统非常重要。通过测试存储/磁盘I/O性能,我们可以确定磁盘的读写速度、延迟和吞吐量等指标。本文将介绍几种常用的方法来测试Linux机器中的存储/磁盘I/O性能。
记得十几年前还在用早期 Windows 系统的时候,每用一段时间系统都会变得很卡顿,这时候需要打开系统提供的下面的磁盘碎片整理程序,当碎片整理完成后会感觉到系统变得稍微流畅了一些。
导言:运维工作中除了要维持平台的稳定运行以外,还得对服务器的性能进行优化,让服务器发挥出良好的工作性能是稳定运行的基础。腾讯互娱DBA团队的汪伟(simon)在这一领域里整理出了一套性能优化的资料为大家在性能优化提供充足的方向。
概述 什么是性能? 性能最通俗的衡量指标就是“时间”,CPU的使用率指的是CPU用于计算的时间占比,磁盘使用率指的是磁盘操作的时间占比,当CPU使用率100%时,意味着有部分请求来不及计算,响应时间
AUFS是一种Union File System,所谓UnionFS就是把不同物理位置的目录合并mount到同一个目录中。UnionFS的一个最主要的应用是,把一张CD/DVD和一个硬盘目录给联合 mount在一起,然后,你就可以对这个只读的CD/DVD上的文件进行修改(当然,修改的文件存于硬盘上的目录里)。
无论 kafka 作为 MQ 也好,作为存储层也罢,无非就是两个功能(好简单的样子),一是 Producer 生产的数据存到 broker,二是 Consumer 从 broker 读取数据。那 Kafka 的快也就体现在读写两个方面了,下面我们就聊聊 Kafka 快的原因。
Flash 性能与实际使用物料有关,受不同存储介质、不同厂家、不同型号甚至不同老化程度的影响,所以经验值仅供参考。
LevelDB是一个C++语言编写的高效键-值嵌入式数据库,目前对亿级的数据也有着非常好的读写性能。虽然LevelDB有着许多键-值数据库所不具备的优秀特性,但是与Redis等一些主流键-值数据库相比也有缺陷。本节将对LevelDB的优缺点进行具体阐述。
FIO是测试IOPS的非常好的工具,用来对硬件进行压力测试和验证。磁盘IO是检查磁盘性能的重要指标,可以按照负载情况分成照顺序读写,随机读写两大类。
在存储设备中,使用分层技术,将冷热数据自动分层存放在具有不用读写性能的存储介质上,已经是很普遍的做法,比如 IBM 的 DS8K 中使用的 Easy Tier。这些功能都需要存储设备固件的支持,如何在 Linux 主机上,使用 Linux 现有的机制,实现数据的分层存储?本文主要介绍了 Linux 平台上两种不同的实现分层存储的方案。 背景介绍 随着固态存储技术 (SSD),SAS 技术的不断进步和普及,存储介质的种类更加多样,采用不同存储介质和接口的存储设备的性能出现了很大差异。SSD 相较于传统的机械硬
硬盘中一般会有多个盘片组成,每个盘片包含两个面,每个盘面都对应地有一个读/写磁头。受到硬盘整体体积和生产成本的限制,盘片数量都受到限制,一般都在5片以内。盘片的编号自下向上从0开始,如最下边的盘片有0面和1面,再上一个盘片就编号为2面和3面。
Kafka是分布式消息系统,需要处理海量的消息,Kafka的设计是把所有的消息都写入速度低容量大的硬盘,以此来换取更强的存储能力,但实际上,使用硬盘并没有带来过多的性能损失 kafka主要使用了以下几个方式实现了超高的吞吐率 顺序读写 kafka的消息是不断追加到文件中的,这个特性使kafka可以充分利用磁盘的顺序读写性能 顺序读写不需要硬盘磁头的寻道时间,只需很少的扇区旋转时间,所以速度远快于随机读写 Kafka官方给出了测试数据(Raid-5,7200rpm): 顺序 I/O: 600MB/
Kafka是大数据领域无处不在的消息中间件,目前广泛使用在企业内部的实时数据管道,并帮助企业构建自己的流计算应用程序。
一、通常服务器的性能会卡在三个地方: cpu 网络IO 磁盘IO 二、在优化性能的时候,首先要判断性能的瓶颈在上述的哪个地方。然后对症下药,按照下面的方法来优化: 1、提高CPU性能的方法 并发。利用多线程、进程。老的线程库效率太低,需要升级用nptl 。进(线)程数不要大于cpu个数 (请参考:http://www.ibm.com/developerworks/cn/linux/l-threading.html) 谨慎用锁。改善架构,尽量不用锁。 慎用字符串操作,比如sprintf,snprintf,因为
已经过去的中间件性能挑战赛,和正在进行中的 第一届 PolarDB 数据性能大赛 都涉及到了文件操作,合理地设计架构以及正确地压榨机器的读写性能成了比赛中获取较好成绩的关键。正在参赛的我收到了几位公众号读者朋友的反馈,他们大多表达出了这样的烦恼:“对比赛很感兴趣,但不知道怎么入门”,“能跑出成绩,但相比前排的选手,成绩相差10倍有余”…为了能让更多的读者参与到之后相类似的比赛中来,我简单整理一些文件IO操作的最佳实践,而不涉及整体系统的架构设计,希望通过这篇文章的介绍,让你能够欢快地参与到之后类似的性能挑战赛之中来。
上篇文章 「什么?相同型号物理机 容器性能不如虚拟机?」 ,给我们的经验教训,就是上线前,基准测试的重要性,这篇文章着重介绍一下「Linux 性能基准测试工具及测试方法」
云硬盘是一种高可用、高可靠、低成本、可定制化的网络块存储,可作为云服务器的独立可扩展硬盘使用。它提供数据块级别的数据存储,采用三副本的分布式机制,为云服务器提供数据可靠性保证。云硬盘提供以下 SSD 云硬盘、高性能云硬盘及普通云硬盘三种云硬盘类型,不同的硬盘类型、性能、特点和价格均不同。
Fio(Flexible I/O Tester) 是一款由 Jens Axboe 开发的用于测评和压力/硬件验证的自由开源的软件。它支持 19 种不同类型的 I/O 引擎 (sync、mmap、libaio、posixaio、SG v3、splice、null、network、 syslet、guasi、solarisaio,以及更多), I/O 优先级(针对较新的 Linux 内核),I/O 速度,fork 的任务或线程任务等等。它能够在块设备和文件上工作。
Java 在 JDK 1.4 引入了 ByteBuffer 等 NIO 相关的类,使得 Java 程序员可以抛弃基于 Stream ,从而使用基于 Block 的方式读写文件,另外,JDK 还引入了 IO 性能优化之王—— 零拷贝 sendFile 和 mmap。但他们的性能究竟怎么样? 和 RandomAccessFile 比起来,快多少? 什么情况下快?到底是 FileChannel 快还是 MappedByteBuffer 快……
CPU使用率:CPU的使用率 平均负载:单位时间内的活跃线程数 用户时间:CPU在用户进程上的实际百分比 系统时间:CPU在内核上花费的实际百分比 空闲时间:系统处于在等待IO操作上的时间总和 等待:CPU花费在等待IO操作上的时间总和 Nice时间:CPU优先执行的时间百分比
近年来,随着中国新基建、中国制造2025规划的持续推进,单ARM处理器越来越难胜任工业现场的功能要求,特别是如今能源电力、工业控制、智慧医疗等行业,往往更需要ARM + FPGA架构的处理器平台来实现例如多路/高速AD采集、多路网口、多路串口、多路/高速并行DI/DO、高速数据并行处理等特定功能,因此ARM + FPGA架构处理器平台愈发受市场欢迎。
上一篇文章大概介绍了I/O的一些基本原理和技术,这篇我们主要介绍基于Linux系统的I/O的一些运行原理、监控方式。
领取专属 10元无门槛券
手把手带您无忧上云