fio

一、分析总结 系统是应用的运行环境，系统的瓶颈会导致应用的性能下降； 而应用的不合理设计，也会引发系统资源的瓶颈。 （1）CPU 性能分析 （2）内存性能分析 （3）磁盘和文件系统 I/O 性能分析 （4）网络性能分析 （5）应用程序瓶颈分析 1）strace，观察系统调用； 2）perf 和火焰图，分析热点函数； 3）动态追踪技术，来分析进程的执行状态。     二、优化总结 （1）CPU 优化 核心在于排除所有不必要的工作、充分利用 CPU 缓存并减少进程调度对性能的影响。 1）把进程绑定到一个或者多个 CPU 上，充分利用 CPU 缓存的本地性，并减少进程间的相互影响。 2）为中断处理程序开启多 CPU 负载均衡，以便在发生大量中断时，可以充分利用多 CPU 的优势分摊负载。 3）使用 Cgroups 等方法，为进程设置资源限制，避免个别进程消耗过多的 CPU。同时，为核心应用程序设置更高的优先级，减少低优先级任务的影响。 （2）内存优化 核心是解决内存使用的问题，如 可用内存不足、内存泄漏、Swap 过多、缺页异常过多以及缓存过多等。 1）除非有必要，Swap 应该禁止掉。这样就可以避免 Swap 的额外 I/O ，带来内存访问变慢的问题。 2）使用 Cgroups 等方法，为进程设置内存限制。这样就可以避免个别进程消耗过多内存，而影响了其他进程。对于核心应用，还应该降低

HDD和SSD磁盘的util指标问题 LInux环境中，在排查磁盘问题时，我们经常使用到iostat工具，这确实是一款非常优秀的工具。但是最近遇到了这么一个问题- ssd做缓存盘，发现业务量稍微上去，utils使用率就高于90%，是不是意味着磁盘出现慢盘了呢？ 比如以下两组数据： Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz sdd 0.00 0.00 13823.00 0.00 55292.00 0.00 8.00 avgqu-sz await r_await w_await svctm %util 0.78 0.06 0.06 0.00 0.06 78.40 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz sdd 0.00 0.00 72914.67 0.00 291658.67 0.00 8.00 avgqu-sz await r_await w_await svctm %util 15.27 0.21 0.21 0.00 0.01 100.00 读io 13k，util使用率78% 读io 73k，util使用率100% 这里理论计算读io 18k就会打满磁盘。其实这里牵扯一个问题，就是ssd固态磁盘是支持并发IO的，这里util只能代表磁盘的繁忙程度

k8s数据存储的方式很多：临时存储（emptyDir），半持久化存储（hostpath），持久化存储（文件、块、对象存存储等）。公有云各厂商几乎都支持云存储服务集成k8s托管，k8s系统本身通过两个概念PersistentVolume（PV）和 PersistentVolumeClaim(PVC)实现存储持久化的生命周期管理（申请、保留、删除、废弃等），pod根据需求向集群系统申请数据卷并使用，如果pod一旦释放，应用消失，数据卷相应分离解绑，数据会保留下来，在使用中pod以及应用对存储的后端基础架构并无感知。 这种设计很好地把应用和数据做了解藕。 至于存储资源的底层是选择ceph、portwx、弹性云存储、云对象存储等等，这就取决于业务具体需求和厂商的支持了。 闲话少说，切入今天的主题，既然有很多后端选择，用户在试用一款k8s集群产品，存储持久化以及应用层面的读写能力是必测一关，这里我们以ibm cloud kubernetes service为例，看看IBM云上的三种常见外挂存储的测试方法以及性能比较。 大致分为三个步骤： 创建K8S集群并通过kubectl连接使用 (部署在日本东京) 确认和安装IBM云存储k8s供应插件(CFS、CBS、COS部署在东京) dbench(fio)测试上述三种存储卷 1. k8s集群创建、连接和使用 登陆cloud.ibm.com,

参考文档： https://www.cnblogs.com/yuhaohao/p/9770701.html 命令： fio --filename=/mnt/test_rw --bs=16K --rw=randwrite --size=20G --runtime=300 --time_based --ioengine=libaio --iodepth=16 --numjobs=2 --group_reporting --name=test --direct=1 结果： test: (g=0): rw=randwrite, bs=16K-16K/16K-16K/16K-16K, ioengine=libaio, iodepth=16 test: (g=0): rw=randwrite, bs=16K-16K/16K-16K/16K-16K, ioengine=libaio, iodepth=16 fio-2.0.13 Starting 2 processes Jobs: 2 (f=2): [ww] [100.0% done] [0K/329.9M/0K /s] [0 /21.2K/0 iops] [eta 00m:00s] test: (groupid=0, jobs=2): err= 0: pid=26607: Tue May 26 13:57:43 2020 write: io

https://www.micron.com/about/blog/2018/may/ceph-bluestore-vs-filestoreblock-performance-comparison-when-leveraging-micron-nvme-ssds BlueStore 是 Ceph 的新存储引擎 ，是社区版的默认配置。 BlueStore性能数字不包含在我们当前的 Micron Accelerated Ceph存储解决方案 参考架构中，因为 Red Hat Ceph 3.0 目前不支持它 。 我在 Ceph参考架构硬件上 对社区版 Ceph Luminous（12.2.4） 进行了 性能测试， 并将结果与​​我们在此博客中在RHCS 3.0中实现的FileStore性能进行比较。 4KB随机写入IOPS性能提高18％，平均延迟降低15％，尾部延迟降低99.99％高达80％。 使用BlueStore，在更高的队列深度下，4KB随机读取性能更好。 该解决方案针对块性能进行了优化。 使用Linux中的Rados Block Driver进行随机小块测试 ，在2插槽存储节点 中使铂级8168 Intel Purley 处理器 饱和 。 每个存储节点有10个驱动器，该架构具有232TB的可用存储容量，可通过添加额外的1U存储节点进行扩展。 参考设计 - 硬件 测试结果和分析

1. PG介绍 这次主要来分享Ceph中的PG各种状态详解，PG是最复杂和难于理解的概念之一，PG的复杂如下： 在架构层次上，PG位于RADOS层的中间。 a. 往上负责接收和处理来自客户端的请求。 b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务。 是组成存储池的基本单位，存储池中的很多特性，都是直接依托于PG实现的。 面向容灾域的备份策略使得一般而言的PG需要执行跨节点的分布式写，因此数据在不同节点之间的同步、恢复时的数据修复也都是依赖PG完成。 2. PG状态表 正常的PG状态是 100%的active + clean， 这表示所有的PG是可访问的，所有副本都对全部PG都可用。 如果Ceph也报告PG的其他的警告或者错误状态。PG状态表： 3.1 Degraded 3.1.1 说明 降级：由上文可以得知，每个PG有三个副本，分别保存在不同的OSD中，在非故障情况下，这个PG是active+clean 状态，那么，如果PG 的 副本osd.4 挂掉了，这个 PG 是降级状态。 3.1.2 故障模拟 a. 停止osd.1 $ systemctl stop ceph-osd@1 b. 查看PG状态 $ bin/ceph pg stat 20 pgs: 20 active+undersized+degraded; 14512 kB data, 302 GB used

目录 文章目录 目录 前文列表 RBD RBD Pool 的创建与删除 块设备的创建与删除 块设备的挂载与卸载 新建客户端 块设备的扩缩容 RBD 块设备的 Format 1 VS Format 2 块设备的快照、克隆、恢复 块设备的 I/O 模型 RBD QoS Token bucket algorithm（令牌桶算法） dmClock algorithm 块设备性能测试 使用 RADOS bench 进行基准测试 使用 fio 进行 IO 测试 前文列表 《 Ceph 分布式存储架构解析与工作原理 》 《 手动部署 Ceph Mimic 三节点 》 RBD RBD: Ceph’s RADOS Block Devices , Ceph block devices are thin-provisioned, resizable and store data striped over multiple OSDs in a Ceph cluster. Ceph RBD 是企业级的块设备存储解决方案，支持扩缩容、支持精简置备，具有 COW 特性，一个块设备（Volume）在 RADOS 中会被分割为若干个 Objects 储存。 CEPH BLOCK DEVICE Thin-provisioned Images up to 16 exabytes Configurable

前言 刚开始做Microsemi FPGA+SoC开发时，会用到几个ARM专用的IP Core，功能一复杂起来，就会遇到某些信号如rst_n不能分配到指定的引脚上的情况，IO类型为CLKBUF，并不是普通的INBUF，而且，这些引脚既不是MSS_FIO，也不是属于Cortex-M3专用的GPIO，怎么会就不能分配呢？曾经一度怀疑是软件的BUG问题。最近在一个FPGA工程中也遇到了这个问题，搜索了一些资料，算是彻底明白了，记录一下。 问题描述 最近在一个FPGA工程中分配rst_n引脚时，发现rst_n引脚类型为CLKBUF，而不是常用的INBUF，在分配完引脚commit检查报错，提示需要连接到全局网络引脚上。 Running Global Checker... Error:PLC002:No legal assignment exists for global net rst.n_c. Info:Uhlocking the driver or removing the region constraint for net rst nc may help to satisfy Error:PLC005:Automat ic global net placement failed. 尝试忽略这个错误，直接进行编译，在布局布线时又报错。 Error: PLC002: No legal

最新需要使用硬盘做一些测试，需要使用到hdparm工具，并进行了解，并进行简要记录； hdparm、dd、fio、都是很好的硬盘测试软件；通常使用其对硬盘信息做基本了解； 关闭硬盘写Cache用例： hdparm -W /dev/ sdh # 查看写缓存状态； hdparm -W 0 /dev/ sdh # 关闭Cache,保证数据强一致性；放置断电时数据未落盘； hdparm -W 1 /dev/sdh # 打开 测试磁盘和磁盘缓存读取速度： 查看磁盘信息： fdisk -l /dev/ sdh hdparm /dev/sdh 评估磁盘读取速度： hdparm -t /dev/sdh 评估磁盘缓存读取速度： hdparm -T /dev/sdh 直接测试硬盘的读性能(绕过内核页缓存)： hdparm -tT --direct /dev/sdh 顺序写测试： time -p bash -c "dd if=/dev/urandom of=./dd.log bs=1M count=50000" 随机写测试： fio -filename=randw-singlethread -fallocate=none -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=libaio -bs=32k -size=1000M -runtime=30s

基础架构性能测试主要包含如下关键参数 磁盘读写性能 磁盘iops 网络带宽 CPU与内存性能一般需要进行业务压测。根据业务使用场景进行测量 工具名称 用途 dd 磁盘写入性能测试 hdparm 磁盘读性能测试 iperf3 网络性能测试 fio 磁盘IOPS性能测试 网络性能测试 安装iperf3if 安装gcc yum install -y gcc 下载iperf3 源码包 wget https://iperf.fr/download/source/iperf-3.1.3-source.tar.gz 编译iperf3 tar -xvf iperf-3.1.3-source.tar.gz -C /opt/ cd /opt/iperf-3.1.3 ./configure make && make install 编译成功后,同操作系统/架构下可以 直接拷贝如下文件到对应目录使用。 /usr/local/bin/iperf3 /usr/local/lib/libiperf.so.0 使用iperf3进行网速测试 iperf3 进行测试时候，不受磁盘I/O影响。 tcp测试 开启iperf3服务端 iperf3 -s 客户端访问测试 iperf3 -c 192.168.1.1 结果: [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0