-
2021-10-16 00:00:58
文章目录
磁盘空间满的情况都有哪些???
第一种情况: 是磁盘空间block剩余量不够了(df -h)
第二种情况: 是磁盘空间inode剩余量不够了(df -i)
显示磁盘空间不足(no space left on device)
block空间满了 ,存储的数量过大
inode空间满了 ,产生了大量小文件一、索引节点信息—inode与blockde
inode与blockde的区别:
1、inode与blockde干什么用?
inode:(index node)索引节点信息 用于存储数据的---文件或目录的一些属性 (文件的权限 所属用户 所属组) block: 块 用于存储数据的---文件的真实数据信息
2、inode与blockde他们是如何出现的?
只有在磁盘做好格式化之后,产生了文件系统,才会有inode和block(收纳袋) 创建一个文件至少占用占用一个inode和一个block
3、inode与blockde如何查询到相应信息
inode信息查看方法: [root@VM-0-3-centos ~]# df -i Filesystem Inodes IUsed IFree IUse% Mounted on devtmpfs 232347 329 232018 1% /dev tmpfs 235251 7 235244 1% /dev/shm tmpfs 235251 422 234829 1% /run tmpfs 235251 16 235235 1% /sys/fs/cgroup /dev/vda1 3276800 81268 3195532 3% / tmpfs 235251 1 235250 1% /run/user/0
block信息查看方法: [root@VM-0-3-centos ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 908M 0 908M 0% /dev tmpfs 919M 24K 919M 1% /dev/shm tmpfs 919M 476K 919M 1% /run tmpfs 919M 0 919M 0% /sys/fs/cgroup /dev/vda1 50G 3.5G 44G 8% / tmpfs 184M 0 184M 0% /run/user/0
4、为什么df -h 和df -i都是显示磁盘使用情况,而两者有这么大的区别呢?
df -h 是去删除比较大无用的文件 --- 大文件占用大量的磁盘容量。 df -i 则去删除数量过多的小文件 --- 过多的文件占用了大量的inode号。 PS:如果df查看磁盘空间任何一个满了,都需要删除文件内的文件,清理空间
二、磁盘空间block剩余量不够了(df -h)
通过df- h命令查看磁盘容量,发现/dev/vda1的容量比较大
[root@VM-0-3-centos /]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 908M 0 908M 0% /dev tmpfs 919M 24K 919M 1% /dev/shm tmpfs 919M 468K 919M 1% /run tmpfs 919M 0 919M 0% /sys/fs/cgroup /dev/vda1 50G 3.5G 44G 8% / tmpfs 184M 0 184M 0% /run/user/0
进入/(根)目录下,利用du -sh *查看/(根)目录下所有目录的容量大小
[root@VM-0-3-centos ~]# cd / [root@VM-0-3-centos /]# du -sh * 0 bin 123M boot 4.0K data 0 dev 37M etc 4.0K home 0 lib 0 lib64 16K lost+found 4.0K media 4.0K mnt 127M opt 0 proc 72K root 476K run 0 sbin 4.0K srv 0 sys 19M tmp 2.7G usr 408M var
发现usr目录占用容量较大,进入usr目录内继续du -sh *排查
[root@VM-0-3-centos /]# cd /usr [root@VM-0-3-centos usr]# du -sh * 277M bin 4.0K etc 8.0K ftp 4.0K games 33M include 774M lib 345M lib64 98M libexec 504M local 79M mpi 55M sbin 394M share 184M src 0 tmp
继续进入占用容量较大的目录src下查看容量
[root@VM-0-3-centos usr]# cd src [root@VM-0-3-centos src]# du -sh * 8.8M debug 77M kernels 8.0K mlnx-ofa_kernel 4.0K mulu 62M ofa_kernel 37M ofa_kernel-5.1 4.0K wenjian
PS:此操作是模拟目录或文件已经很大需要清理的情况下
此时已经可以排查到是哪些文件占用较大的内存,我们以我自己模拟创建的mulu(目录)和wenjian(文件)作为测试对象.
1.清理/usr/src/mulu目录下的文件。[root@VM-0-3-centos src]# rm -r /usr/src/mulu/* rm: remove directory ‘/usr/src/mulu/fu’? y
2.清理/usr/src/wenjian的src目录下wenjian文件
利用重定向的命令清空文件内的内容(还有其他方式清空文件内的内容就不一一演示)[root@VM-0-3-centos src]# echo " " >> /usr/src/wenjian
三、磁盘空间inode剩余量不够了(df -ih)
加上h是因为它可以直接输出人们可以直接看出容量的单位
通过df -ih 查看了下inode,发现根目录下的inode值使用率为100%了
[root@VM-0-3-centos ~]# df -ih Filesystem Inodes IUsed IFree IUse% Mounted on devtmpfs 227K 329 227K 1% /dev tmpfs 230K 7 230K 1% /dev/shm tmpfs 230K 420 230K 1% /run tmpfs 230K 16 230K 1% /sys/fs/cgroup /dev/vda1 3.2M 3.2M 0 100% / tmpfs 230K 1 230K 1% /run/user/0
解决方法:通过下列命令查看较大的目录
[root@VM-0-3-centos ~]# find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n
发现哪个目录内小文件较多,进入到小文件较多的目录中,进行删除小文件;如下命令:cd到/xx/xx/xx目录下进行目录下文件筛选后删除
[root@VM-0-3-centos ~]# cd /xx/xx/xx && find -type f |xargs rm -f
更多相关内容 -
RAID磁盘阵列利用率计算.txt
2019-12-01 11:08:53精心总结笔记,磁盘利用率的计算,组成的磁盘数量、容量、可靠性等优缺点比较,包括RAID0、RAID1、RAID2、RAID3、RAID4、RAID5、RAID 0+1 -
如何检查Linux中的磁盘利用率?
2021-05-12 15:23:23跟踪磁盘利用率信息是系统管理员(和其他人)的日常待办事项列表之一。Linux 有一些内置的使用程序来帮助提供这些信息。dfdf命令意思是 “disk-free”,显示 Linux 系统上可用和已使用的磁盘空间。df -h以人类可读的...跟踪磁盘利用率信息是系统管理员(和其他人)的日常待办事项列表之一。Linux 有一些内置的使用程序来帮助提供这些信息。
df
df命令意思是 “disk-free”,显示 Linux 系统上可用和已使用的磁盘空间。
df -h以人类可读的格式显示磁盘空间。
df -a显示文件系统的完整磁盘使用情况,即使 Available(可用) 字段为 0。
df -T显示磁盘使用情况以及每个块的文件系统类型(例如,xfs、ext2、ext3、btrfs 等)。
df -i显示已使用和未使用的 inode。
du
du显示文件,目录等的磁盘使用情况,默认情况下以 kb 为单位显示。
du -h以人类可读的方式显示所有目录和子目录的磁盘使用情况。
du -a显示所有文件的磁盘使用情况。
du -s提供特定文件或目录使用的总磁盘空间。
ls -al
ls -al列出了特定目录的全部内容及大小。
stat
stat 显示文件/目录或文件系统的大小和其他统计信息。
fdisk -l
fdisk -l显示磁盘大小以及磁盘分区信息。
这些是用于检查 Linux 文件空间的大多数内置实用程序。有许多类似的工具,如Disks(GUI 工具),Ncdu等,它们也显示磁盘空间的利用率。
-
磁盘利用率和饱和度
2018-06-21 11:36:24导读如何观察磁盘的IO利用率以及饱和度?看文本文给你解药!翻译团队:知数堂藏经阁项目 - 菜鸟盟团队成员:菜鸟盟–hades、菜鸟盟-bruce、菜鸟盟-冰焰译文校稿:叶师傅原文出处:...导读
如何观察磁盘的IO利用率以及饱和度?
看文本文给你解药!
翻译团队:知数堂藏经阁项目 - 菜鸟盟
团队成员:菜鸟盟–hades、菜鸟盟-bruce、菜鸟盟-冰焰
译文校稿:叶师傅
原文出处:https://www.percona.com/blog/2017/08/28/looking-disk-utilization-and-saturation/
原文作者:Peter Zaitsev (Percona CEO)
在这篇文章里,会介绍磁盘利用率和饱和度相关的知识。
In this blog post, I will look at disk utilization and saturation.
在之前的博客里面,我写了一些关于CPU使用率和饱和度之间有什么实质性不同,以及CPU使用率、饱和度如何从不同维度影响响应时间(RT)的文章。
现在我们来看另一个影响数据库性能重要因素:存储子系统。在下面文章里,我会用“磁盘”代替存储子系统。In my previous blog post, I wrote about CPU utilization and saturation, the practical difference between them and how different CPU utilization and saturation impact response times.
Now we will look at another critical component of database performance: the storage subsystem. In this post, I will refer to the storage subsystem as “disk” (as a casual catch-all).
监控IO性能最常用的工具是iostat,会显示如下的信息:
The most common tool for command line IO performance monitoring is iostat, which shows information like this:
root@ts140i:~# iostat -x nvme0n1 5 Linux 4.4.0-89-generic (ts140i) 08/05/2017 _x86_64_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 0.51 0.00 2.00 9.45 0.00 88.04 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util nvme0n1 0.00 0.00 3555.57 5887.81 52804.15 87440.73 29.70 0.53 0.06 0.13 0.01 0.05 50.71 avg-cpu: %user %nice %system %iowait %steal %idle 0.60 0.00 1.06 20.77 0.00 77.57 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util nvme0n1 0.00 0.00 7612.80 0.00 113507.20 0.00 29.82 0.97 0.13 0.13 0.00 0.12 93.68 avg-cpu: %user %nice %system %iowait %steal %idle 0.50 0.00 1.26 6.08 0.00 92.16 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util nvme0n1 0.00 0.00 7653.20 0.00 113497.60 0.00 29.66 0.99 0.13 0.13 0.00 0.12 93.52
第一行(avg-cpu)显示的是自系统启动之后平均的性能。某些情况下,用当前系统的压力和平均性能作对比是很有用的。这篇文章的案例是测试环境,所以可以忽略对比这两种情况。
第二行(Device)显示的当前5秒钟的性能指标(在命令行中指定了每5秒输出一次)。The first line shows the average performance since system start. In some cases, it is useful to compare the current load to the long term average. In this case, as it is a test system, it can be safely ignored. The next line shows the current performance metrics over five seconds intervals (as specified in the command line).
iostat命令用%util列显示利用率的信息,可以通过观察平均请求队列大小(the avgqu-sz 列)或者通过r_await和w_await列(显示平均的读和写的等待)来观察IO饱和度。如果超过正常值,设备就会过度饱和了。
The iostat command reports utilization information in the %util column, and you can look at saturation by either looking at the average request queue size (the avgqu-sz column) or looking at the r_await and w_await columns (which show the average wait for read and write operations). If it goes well above “normal” then the device is over-saturated.
和之前的文章一样,我们会执行Sysbench,然后观察iostat命令、Percona PMM的输出。
As in my previous blog post, we’ll perform some system Sysbench runs and observe how the iostat command line tool and Percona Monitoring and Management graphs behave.
我们用Sysbench测试文件IO,以便观察磁盘的变化。我创建了一个100GB的文件,因为用了DirectIO方式所以所有的请求都会直接打到磁盘。我也会用"sync”刷新模式以便更好的控制IO请求的并发度。
To focus specifically on the disk, we’re using the Sysbench fileio test. I’m using just one 100GB file, as I’m using DirectIO so all requests hit the disk directly. I’m also using “sync” request submission mode so I can get better control of request concurrency.
在这个实验中我用了一个Intel 750 NVME固态硬盘(虽然这并不重要)。
I’m using an Intel 750 NVME SSD in this test (though it does not really matter).
Sysbench FileIO 1线程
root@ts140i:/mnt/data# sysbench --threads=1 --time=600 --max-requests=0 fileio --file-num=1 --file-total-size=100G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run File operations: reads/s: 7113.16 writes/s: 0.00 fsyncs/s: 0.00 Throughput: read, MiB/s: 111.14 written, MiB/s: 0.00 General statistics: total time: 600.0001s total number of events: 4267910 Latency (ms): min: 0.07 avg: 0.14 max: 6.18 95th percentile: 0.17
单线程测试结果通常可以作为基线,通常只有一个请求时的响应时间通常也最快(不过一般也不是最佳吞吐量)。
A single thread run is always great as a baseline, as with only one request in flight we should expect the best response time possible (though typically not the best throughput possible).
Iostat Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util nvme0n1 0.00 0.00 7612.80 0.00 113507.20 0.00 29.82 0.97 0.13 0.13 0.00 0.12 93.68
磁盘读写延迟
磁盘延迟图像证实了我们从iostat命令看到的磁盘IO延迟,它指定了特定设备。我们用它作为基线和更高并发做对比。
The Disk Latency graph confirms the disk IO latency we saw in the iostat command, and it will be highly device-specific. We use it as a baseline to compare changes to with higher concurrency.
磁盘IO使用率
即便我们只发起一个IO请求(队列深度),但磁盘IO使用率已很接近100%。这个是linux磁盘使用率显示的问题,它不像CPU利用率,由于IO设备的特殊设计机制linux不能直接显示其利用率。它真正有多少可执行单元?他们是怎么被使用的?当做了raid后,每个物理磁盘都可以被视为单独的执行单元,而SSD磁盘以及云存储(比如EBS)则可能有更多执行单元。
Disk IO utilization is close to 100% even though we have just one outstanding IO request (queue depth). This is the problem with Linux disk utilization reporting: unlike CPUs, Linux does not have direct visibility on how the IO device is designed. How many “execution units” does it really have? How are they utilized? Single spinning disks can be seen as a single execution unit while RAID, SSDs and cloud storage (such as EBS) are more than one.
磁盘负载
这个图片显示磁盘负载(或者请求队列大小),它和实际压到磁盘上线程的数量是大致匹配的。
This graph shows the disk load (or request queue size), which roughly matches the number of threads that are hitting disk as hard as possible.
饱和度(IO压力)
饱和度指标图上的IO负载几乎显示了相同的数值。唯一的不同是不像磁盘IO统计信息一样,它显示了整个系统的概要。
The IO load on the Saturation Metrics graph shows pretty much the same numbers. The only difference is that unlike Disk IO statistics, it shows the summary for the whole system.
Sysbench FileIO 4线程
现在让我们把IO提高到四个并发线程,再来看看磁盘的情况:
Now let’s increase IO to four concurrent threads and see how disk responds:
root@ts140i:/mnt/data# sysbench --threads=4 --time=600 --max-requests=0 fileio --file-num=1 --file-total-size=100G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run File operations: reads/s: 26248.44 writes/s: 0.00 fsyncs/s: 0.00 Throughput: read, MiB/s: 410.13 written, MiB/s: 0.00 General statistics: total time: 600.0002s total number of events: 15749205 Latency (ms): min: 0.06 avg: 0.15 max: 8.73 95th percentile: 0.21
我们看到请求数量线性增加,而请求延迟变化却很小:0.14ms vs 0.15ms。这表明设备内部有足够的执行单元并行处理负载,而且不存在其他瓶颈(如连接接口)。
We can see the number of requests scales almost linearly, while request latency changes very little: 0.14ms vs. 0.15ms. This shows the device has enough execution units internally to handle the load in parallel, and there are no other bottlenecks (such as the connection interface).
Iostat Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util nvme0n1 0.00 0.00 28808.60 0.00 427668.00 0.00 29.69 4.05 0.14 0.14 0.00 0.03 99.92
磁盘读写延迟
磁盘IO使用率
磁盘负载
饱和度(IO压力)
Sysbench FileIO 16线程
root@ts140i:/mnt/data# sysbench --threads=16 --time=600 --max-requests=0 fileio --file-num=1 --file-total-size=100G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run File operations: reads/s: 76845.96 writes/s: 0.00 fsyncs/s: 0.00 Throughput: read, MiB/s: 1200.72 written, MiB/s: 0.00 General statistics: total time: 600.0003s total number of events: 46107727 Latency (ms): min: 0.07 avg: 0.21 max: 9.72 95th percentile: 0.36
从4个线程到16个线程,我们再次看到吞吐量有较大提升而响应时间只轻微变大。如果你仔细观察结果,你将注意到一个更有趣的事情:平均响应时间从0.15ms增加到0.21ms(增加了40%),而95%的响应时间从0.21ms增加到0.36 ms(增加了71%)。我还进行了一个单独的测试来测量99%的响应时间,发现差异甚至更大:0.26ms vs 0.48ms(增加了84%)。
Going from four to 16 threads, we again see a good throughput increase with a mild response time increase. If you look at the results closely, you will notice one more interesting thing: the average response time has increased from 0.15ms to 0.21ms (which is a 40% increase), while the 95% response time has increased from 0.21ms to 0.36ms (which is 71%). I also ran a separate test measuring 99% response time, and the difference is even larger: 0.26ms vs. 0.48ms (or 84%).
这是一个重要的观察:一旦趋于饱和,方差可能会增加,而且其中一些请求会受到不同程度的影响(不仅仅只是我们看到的平均响应时间)。
This is an important observation to make: once saturation starts to happen, the variance is likely to increase and some of the requests will be disproportionately affected (beyond what the average response time shows).
Iostat Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util nvme0n1 0.00 0.00 82862.20 0.00 1230567.20 0.00 29.70 16.33 0.20 0.20 0.00 0.01 100.00
磁盘读写延迟
磁盘IO使用率
磁盘负载
饱和度(IO压力)
上面的图表结果符合预期:磁盘负载和IO负载从基本饱和增长到约为16,磁盘IO利用率则保持在100%。
The graphs show an expected figure: the disk load and IO load from saturation are up to about 16, and utilization remains at 100%.
需要注意的是图形中的抖动有所增加。IO利用率飙到100%以上,磁盘IO负载峰值上升到18,而请求队列却并不是很大。这就需要先从这些信息如何去收集的角度去考虑问题。尝试每秒对这些数据进行采样,但是在有实际负载的系统中,这个采集进程也需要费些时间:我们本来希望每秒采集一次数据,而实际上间隔则是1.05 ~ 0.95秒。当数学应用于数据采集时,我们所看到的图表中就可能会有本不应该出现的波峰、波谷(或刺点)。所以从大的角度来看,是可以忽略这些波动的。
One thing to notice is increased jitter in the graphs. IO utilization jumps to over 100% and disk IO load spikes to 18, when there should not be as many requests in flight. This comes from how this information is gathered. An attempt is made to sample this data every second, but with the loaded system it takes time for this process to work: sometimes when we try to get the data for a one-second interval but really get data for 1.05- or 0.95-second intervals. When the math is applied to the data, it creates the spikes and dips in the graph when there should be none. You can just ignore them if you’re looking at the big picture.
Sysbench FileIO 64 Threads
最后,让我们用sysbench跑64个并发线程的情况:
Finally, let’s run sysbench with 64 concurrent threads hitting the disk:
root@ts140i:/mnt/data# sysbench --threads=64 --time=600 --max-requests=0 fileio --file-num=1 --file-total-size=100G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run File operations: reads/s: 127840.59 writes/s: 0.00 fsyncs/s: 0.00 Throughput: read, MiB/s: 1997.51 written, MiB/s: 0.00 General statistics: total time: 600.0014s total number of events: 76704744 Latency (ms): min: 0.08 avg: 0.50 max: 9.34 95th percentile: 1.25
我们可以看到平均响应耗时从0.21ms上升到0.50ms(两倍多),此外95%的响应时间从0.36ms跃升到1.25ms。实际上,我们可以看到IO负载开始饱和了,以前我们看到随着CPU饱和度的增加,并发线程数越多则响应耗时也越久,但这次随着并发线程数的增加,我们并未看到响应耗时随着线性增加。猜测是因为我们测试IO设备有不错的内部IO并行能力,所以响应请求效率很高(即便并发线程从16增加到64)。
We can see the average has risen from 0.21ms to 0.50 (more than two times), and 95% almost tripped from 0.36ms to 1.25ms. From a practical standpoint, we can see some saturation starting to happen, but we’re still not seeing a linear response time increase with increasing numbers of parallel operations as we have seen with CPU saturation. I guess this points to the fact that this IO device has a lot of parallel capacity inside and can process requests more effectively (even going from 16 to 64 concurrent threads).
在这个测试中,当我们将并发性从1个增加到64个时,我们看到响应耗时从0.14ms增加到0.5ms(约三倍)。此时95%的响应耗时从0.17ms增加到1.25ms(约七倍)。实际上,从这时开始看到IO设备趋于饱和了。
Over the series of tests, as we increased concurrency from one to 64, we saw response times increase from 0.14ms to 0.5ms (or approximately three times). The 95% response time at this time grew from 0.17ms to 1.25ms (or about seven times). For practical purposes, this is where we see the IO device saturation start to show.
Iostat Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util nvme0n1 0.00 0.00 138090.20 0.00 2049791.20 0.00 29.69 65.99 0.48 0.48 0.00 0.01 100.24
我们将略过相关图表,因为它们基本雷同,只是在64并发线程下有更高的延迟。
We’ll skip the rest of the graphs as they basically look the same, just with higher latency and 64 requests in flight.
Sysbench FileIO 256线程
root@ts140i:/mnt/data# sysbench --threads=256 --time=600 --max-requests=0 fileio --file-num=1 --file-total-size=100G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run File operations: reads/s: 131558.79 writes/s: 0.00 fsyncs/s: 0.00 Throughput: read, MiB/s: 2055.61 written, MiB/s: 0.00 General statistics: total time: 600.0026s total number of events: 78935828 Latency (ms): min: 0.10 avg: 1.95 max: 17.08 95th percentile: 3.89
Iostat Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util nvme0n1 0.00 0.00 142227.60 0.00 2112719.20 0.00 29.71 268.30 1.89 1.89 0.00 0.0
最后,当并发256个线程时,从平均响应耗时的线性增长结果表明了设备已经过载,且IO请求开始排队。这里没有简单的办法判断它是由于IO总线饱和(此时IO读速率为2GB/sec),还是由于设备内部处理能力所限导致的。
With 256 threads, finally we’re seeing the linear growth of the average response time that indicates overload and queueing to process requests. There is no easy way to tell if it is due to the IO bus saturation (we’re reading 2GB/sec here) or if it is the internal device processing ability.
正如我们所见,并发数从16个到64个时,响应耗时小于线性增长,当从64到256则是线性增长,我们可以看到这个设备最佳的并发是介于16个和64之间。这时的吞吐量可以达到峰值,且没有大量的请求排队。
As we’ve seen a less than linear increase in response time going from 16 to 64 connections, and a linear increase going from 64 to 256, we can see the “optimal” concurrency for this device: somewhere between 16 and 64 connections. This allows for peak throughput without a lot of queuing.
在总结之前,我想对这次特别的测试先做一个重要的说明。这是个随机读的测试,对于很多数据库来说是个重要的工作负载模式,但可能不是最主要负载场景。可能是写为主,或者顺序IO读 (则会有相应不同的表现)。对于其它的工作负载模式,我希望本文可以帮助你在分析时提供些参考、思路。
Before we get to the summary, I want to make an important note about this particular test. The test is a random reads test, which is a very important pattern for many database workloads, but it might not be the dominant load for your environment. You might be write-bound as well, or have mainly sequential IO access patterns (which could behave differently). For those other workloads, I hope this gives you some ideas on how to also analyze them.
另一种思考饱和度的方法
Another Way to Think About Saturation
当我问起他Percona的同学对本文的反馈意见时,Yves Trudeau同学提供了另外一种思考饱和度的方法:与单线程模式相比,平均响应耗时的增长百分比作为饱和度的衡量指标 。例如:
When I asked the Percona staff for feedback on this blog post by, my colleague Yves Trudeau provided another way to think about saturation: measure saturation as percent increase in the average response time compared to the single user. Like this:
Threads Avg Response Time Saturation 1 0.14 – 4 0.15 1.07x or 7% 16 0.21 1.5x or 50% 64 0.50 3.6x or 260% 256 1.95 13.9x or 1290% 总结
Summary
我们可以看到如何理解磁盘利用率和饱和度要比CPU复杂的多;
We can see how understanding disk utilization and saturation is much more complicated than for the CPU:
利用率指标(由iostat和PMM输出的%Util)对理解真实的IO设备利用率是没啥作用。因为它只是衡量在运行中至少有一个请求时的耗时。如果是CPU的这个指标,它将相当于运行在至少一个核上(对于高度并发系统不是很有用);
The Utilization metric (as reported by iostat and by PMM) is not very helpful for showing true storage utilization, as it only measures the time when there is at least one request in flight. If you had the same metric for the CPU, it would correspond to something running on at least one of the cores (not very useful for highly parallel systems).
不同于CPU,Linux工具不给我们提供关于存储设备的底层结构和在不饱和的情况下还可以处理多少并行负载的信息。更甚的是,存储设备可能有不同的底层源头会导致饱和。例如,它可能是网络连接,SATA总线,甚至是老内核的内核IO栈去处理高速存储设备(译者注:跟不上时代发展啦)。
Unlike a CPU, Linux tools do not provide us with information about the structure of the underlying storage and how much parallel load it should be able to handle without saturation. Even more so, storage might well have different low-level resources that cause saturation. For example, it could be the network connection, SATA BUS or even the kernel IO stack for older kernels and very fast storage.
根据运行中的请求数量来测量饱和有助于判断是否饱和,但是由于我们不知道设备可以高效的并发处理多少请求,只看基础指标我们不能确定设备是否过载;
Saturation as measured by the number of requests in flight is helpful for guessing if there might be saturation, but since we do not know how many requests the device can efficiently process concurrently, just looking the raw metric doesn’t let us determine that the device is overloaded
平均响应耗时对于观察饱和度是一个很好的指标,但是和响应耗时一样,您无法判断这个设备的响应耗时是高是低。您需要在上下文中查看它并将其与基线进行比较。当你查看平均响应耗时时,确保你分别查看读响应时间和写响应时间,并且记下平均请求队列大小以确保是相同角度的比较。
Avg Response Time is a great metric for looking at saturation, but as with the response time you can’t say what response time is good or bad for this device. You need to look at it in context and compare it to the baseline. When you’re looking at the Avg Response Time, make sure you’re looking at read request response time vs. write request response time separately, and keep the average request size in mind to ensure we are comparing apples to apples.
-
php监控linux流量,cpu利用率,磁盘利用率,内存利用率
2013-10-21 20:58:45自己写的监控linux的linux流量,cpu利用率,磁盘利用率,内存利用率。并以每天,每周,每年4种图片报表呈现,记录了最大值和时间。具体步骤里面的文档有写 -
Windows Server 2019 开启磁盘利用率情况
2022-01-21 11:19:51环景: windows sever 2019 问题描述: 怎么开启磁盘利用率情况 解决方案: 1.CMD输入 diskperf -y 2.完成展开全文 -
RAID磁盘利用率详解
2016-05-03 11:00:00RAID磁盘利用率详解 一.RAID定义 RAID(Redundant Array of Independent Disk 独立冗余磁盘阵列)技术是加州大学伯克利分校1987年提出,最初是为了组合小的廉价磁盘来代替大的昂贵磁盘,同时希望磁盘... -
linux 磁盘利用率过高
2018-03-29 17:41:14线上服务器磁盘利用率过高,则删除一些不用的大文件。常用的命令: df -h: 检查linux服务器的文件系统的磁盘空间占用情况 du -h: 查看当前目录下文件占用磁盘空间大小 ls -a: 查看当前目录下所以文件,包含隐藏文件 -
java获取linux的磁盘空间,磁盘利用率
2019-05-23 11:18:47* 采集磁盘IO使用率 */ public class IoUsage{ private static Logger log = Logger.getLogger(IoUsage.class); private static IoUsage INSTANCE = new IoUsage(); private IoUsage(){ ... -
企业级-Shell案例7——监控多台服务器磁盘利用率脚本
2020-01-18 17:16:17监控多台服务器磁盘利用率脚本 SSH ssh root@192.168.1.99 "df -h" 但每次要使用密码,不推荐使用。 可以使用秘钥登录。 创建秘钥【一直回车就行】 ssh-keygen 把公钥复制到需要被控的服务器 ssh-... -
磁盘IO利用率监控VBS脚本(windows)
2020-08-25 12:19:35主要为大家分享监测windows主机IO利用率的脚本代码,需要的朋友可以参考一下 -
利用shell脚本监控linux中CPU、内存和磁盘利用率。(centos7)
2018-08-31 09:21:29利用shell脚本监控linux中CPU、内存和磁盘利用率。(centos7) 2017年11月21日 11:42:00 阅读数:182 这篇博客中所写的,在实际工作中并没有什么卵用,工作中并不会用到这种脚本去监控。不过自己写一遍,可以让... -
开VM虚拟机导致内存和磁盘利用率高
2019-05-11 22:27:00现象:在虚拟机上运行...打开任务管理器,发现内存利用率80%以上 磁盘几乎100% ,最后发现是虚拟机的问题 百度,有优化虚拟机的解答, 特此记录一下 转载于:https://www.cnblogs.com/xuzhaoping/p/10850367.html... -
总结记录一下如何统计CPU使用情况、磁盘利用率
2019-03-17 18:00:00一、.cpu使用率 可以使用/proc/stat命中查看 举例:cat /proc/stat | grep cpu cpu 1391321772 178 2524194226 33711208592 1046582 6540 3886726 0 0 0 cpu0 43138144 6 ... -
关于开启虚拟机磁盘利用率100%问题
2018-11-02 11:15:00从vm10开始,默认每个虚拟机运行时,自动在硬盘上生成一个内存实时镜像文件。这样一旦虚拟机打开,这个文件就不停写入(虚拟机内存的改变),配合win8/10的硬盘使用方式改变,效果无比呵呵。这简直就是个脑残设计,... -
【操作系统】若检测到 CPU 和磁盘利用率如下,请问现在可能发生了什么情况,应采取什么措施?
2018-06-17 12:57:15若检测到 CPU 和磁盘利用率如下,请问现在可能发生了什么情况,应采取什么措施? 1) CPU 10%,磁盘 94%;此时系统可能已经出现抖动,可暂停部分运行进程; 2) CPU 55%,磁盘3%;此时系统运行正常,磁盘利用率稍低... -
Hadoop集群datanode磁盘不均衡的解决方案
2021-01-29 22:11:39Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况,比如集群中添加新的数据节点,节点与节点之间磁盘大小不一样等等。当hdfs出现不平衡状况的时候,将引发很多问题,比如MR程序无法很好地利用本地... -
qemu-2.11.0增加获取vm根目录磁盘使用率qga接口
2018-08-17 18:41:22在qemu-2.11.0中增加获取vm根目录磁盘使用率qga接口,仅供初学qemu QGA代码框架的程序猿使用。 -
操作系统-习题磁盘空间利用率
2020-09-28 09:03:41(1)不采用记录成组操作时磁空间的利用率为( )。 (2)采用记录成组操作且块因子为5时,磁带空间的利用率为( )。 (3)当按上述方式把文件存放到磁带上后,用户要求每次读一个逻辑记录存放到他的工作区。当对该... -
通过snmp的OID获取对方主机的内存利用率及CPU的使用率
2019-10-31 16:50:41通过snmp的OID获取对方主机的内存利用率及CPU的使用率 -
linux iostat 查看磁盘io利用率
2020-05-26 13:11:11平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少 I/O 操作率 (%util)类似于收款台前有人排队的时间比例。 我们可以根据这些数据分析出 I/O 请求的模式,以及 I/O 的速度和响应时间。 参数输出的分析 # iostat -x... -
win10装完系统后解决磁盘利用率很高的问题
2018-06-04 09:19:08https://jingyan.baidu.com/article/8275fc8663a82846a13cf65e.htmlhttps://blog.csdn.net/a327915304/article/details/78446039/ -
qt 获取磁盘空间大小,cpu利用率,内存使用率
2019-12-13 15:39:091:封装成一个类,直接调用即可。...3:linux下CPU占用率的计算非常准确,支持多核。 4:硬盘容量计算极速。进度条显示占用比例。 5:多彩数码管实时显示当前时间。 6:自定义颜色下拉框,选择即可看到效果。 -
【题集】测得某个采用按需调页策略的系统部分状态数据为:CPU利用率为20%,对换空间的磁盘利用率为98%,...
2019-07-08 20:07:10测得某个采用按需调页策略的系统部分状态数据为:CPU利用率为20%,对换空间的磁盘利用率为98%,其他设备的利用率为5%,由此断定系统出现异常。此种情况下( )能提高利用率。 A.安装一个更快的硬盘 B.通过扩大硬盘... -
磁盘压测工具
2018-06-12 05:59:21DISKSPD磁盘压力分析工具可以再部署安装数据库前,做过磁盘压力测试。了解磁盘性能... 磁盘压力分析工具可以再部署安装数据库前,做过磁盘压力测试。了解磁盘性能... -
zabbix监控windows磁盘利用率
2017-08-03 10:13:38早上来到公司,客服的打电话说他们的录音不能打开了,马上登陆服务器发现磁盘满了,录音当然不能录音了 立马备份至其他的盘中,所以现在要在监控中增加对磁盘的监控。网上查找资料放心zabbix自带的windows模板中有对... -
查看Elasticsearch磁盘使用率
2022-04-12 13:07:171 需求 需要查看Elasticsearch磁盘使用率,方便扩容,数据迁移 2 命令 http://127.0.0.1:9012/_cat/allocation?v&pretty