精华内容
下载资源
问答
  • linux运维之磁盘利用率100%教你做人
    千次阅读 多人点赞
    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
    
    
    更多相关内容
  • 精心总结笔记,磁盘利用率的计算,组成的磁盘数量、容量、可靠性等优缺点比较,包括RAID0、RAID1、RAID2、RAID3、RAID4、RAID5、RAID 0+1
  • 如何检查Linux中的磁盘利用率

    千次阅读 2021-05-12 15:23:23
    跟踪磁盘利用率信息是系统管理员(和其他人)的日常待办事项列表之一。Linux 有一些内置的使用程序来帮助提供这些信息。dfdf命令意思是 “disk-free”,显示 Linux 系统上可用和已使用的磁盘空间。df -h以人类可读的...

    跟踪磁盘利用率信息是系统管理员(和其他人)的日常待办事项列表之一。Linux 有一些内置的使用程序来帮助提供这些信息。

    5acd3a626bb5ee1e7d2aed72870b2ad5.png

    df

    df命令意思是 “disk-free”,显示 Linux 系统上可用和已使用的磁盘空间。

    df -h以人类可读的格式显示磁盘空间。

    df -a显示文件系统的完整磁盘使用情况,即使 Available(可用) 字段为 0。

    a1cecb9153354c82ef0e33d0b5b92cee.png

    df -T显示磁盘使用情况以及每个块的文件系统类型(例如,xfs、ext2、ext3、btrfs 等)。

    df -i显示已使用和未使用的 inode。

    90d9c059dbb9fd8ec35ba786f7b85cce.png

    du

    du显示文件,目录等的磁盘使用情况,默认情况下以 kb 为单位显示。

    du -h以人类可读的方式显示所有目录和子目录的磁盘使用情况。

    du -a显示所有文件的磁盘使用情况。

    du -s提供特定文件或目录使用的总磁盘空间。

    681f9e4c80fb076429713f5528ed3feb.png

    ls -al

    ls -al列出了特定目录的全部内容及大小。

    a38a49de1aa8ae6721090b5c4f118582.png

    stat

    stat 显示文件/目录或文件系统的大小和其他统计信息。

    96b8d22009d39a75126316a7afeee0a8.png

    fdisk -l

    fdisk -l显示磁盘大小以及磁盘分区信息。

    8cc643b953fce4cc2e2e4a99f7dfe142.png

    这些是用于检查 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

    磁盘读写延迟

    0?wx_fmt=png

    磁盘延迟图像证实了我们从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使用率

    0?wx_fmt=png

    即便我们只发起一个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.

    磁盘负载

    0?wx_fmt=png

    这个图片显示磁盘负载(或者请求队列大小),它和实际压到磁盘上线程的数量是大致匹配的。

    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压力)

    0?wx_fmt=png

    饱和度指标图上的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  

    磁盘读写延迟

    0?wx_fmt=png

    磁盘IO使用率

    0?wx_fmt=png

    磁盘负载

    0?wx_fmt=png

    饱和度(IO压力)

    0?wx_fmt=png

    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  

    磁盘读写延迟

    0?wx_fmt=png

    磁盘IO使用率

    0?wx_fmt=png

    磁盘负载

    0?wx_fmt=png

    饱和度(IO压力)

    0?wx_fmt=png

    上面的图表结果符合预期:磁盘负载和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:

    ThreadsAvg Response TimeSaturation
    10.14
    40.151.07x or 7%
    160.211.5x or 50%
    640.503.6x or 260%
    2561.9513.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.

    展开全文
  • 自己写的监控linux的linux流量,cpu利用率,磁盘利用率,内存利用率。并以每天,每周,每年4种图片报表呈现,记录了最大值和时间。具体步骤里面的文档有写
  • 环景: windows sever 2019 问题描述: 怎么开启磁盘利用率情况 解决方案: 1.CMD输入 diskperf -y 2.完成

    环景:

    windows sever 2019

    问题描述:

    怎么开启磁盘利用率情况

    在这里插入图片描述

    解决方案:

    1.CMD输入
    diskperf -y
    在这里插入图片描述

    2.完成
    在这里插入图片描述

    展开全文
  • RAID磁盘利用率详解

    万次阅读 2016-05-03 11:00:00
    RAID磁盘利用率详解 一.RAID定义   RAID(Redundant Array of Independent Disk 独立冗余磁盘阵列)技术是加州大学伯克利分校1987年提出,最初是为了组合小的廉价磁盘来代替大的昂贵磁盘,同时希望磁盘...
  • linux 磁盘利用率过高

    千次阅读 2018-03-29 17:41:14
    线上服务器磁盘利用率过高,则删除一些不用的大文件。常用的命令: df -h: 检查linux服务器的文件系统的磁盘空间占用情况 du -h: 查看当前目录下文件占用磁盘空间大小 ls -a: 查看当前目录下所以文件,包含隐藏文件
  •  * 采集磁盘IO使用  */ public class IoUsage{  private static Logger log = Logger.getLogger(IoUsage.class);  private static IoUsage INSTANCE = new IoUsage();    private IoUsage(){   ...
  • 监控多台服务器磁盘利用率脚本 SSH ssh root@192.168.1.99 "df -h" 但每次要使用密码,不推荐使用。 可以使用秘钥登录。 创建秘钥【一直回车就行】 ssh-keygen 把公钥复制到需要被控的服务器 ssh-...
  • 主要为大家分享监测windows主机IO利用率的脚本代码,需要的朋友可以参考一下
  • 利用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使用 可以使用/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 和磁盘利用率如下,请问现在可能发生了什么情况,应采取什么措施? 1) CPU 10%,磁盘 94%;此时系统可能已经出现抖动,可暂停部分运行进程; 2) CPU 55%,磁盘3%;此时系统运行正常,磁盘利用率稍低...
  • Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况,比如集群中添加新的数据节点,节点与节点之间磁盘大小不一样等等。当hdfs出现不平衡状况的时候,将引发很多问题,比如MR程序无法很好地利用本地...
  • 在qemu-2.11.0中增加获取vm根目录磁盘使用qga接口,仅供初学qemu QGA代码框架的程序猿使用。
  • 操作系统-习题磁盘空间利用率

    千次阅读 2020-09-28 09:03:41
    (1)不采用记录成组操作时磁空间的利用率为( )。 (2)采用记录成组操作且块因子为5时,磁带空间的利用率为( )。 (3)当按上述方式把文件存放到磁带上后,用户要求每次读一个逻辑记录存放到他的工作区。当对该...
  • 通过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...
  • https://jingyan.baidu.com/article/8275fc8663a82846a13cf65e.htmlhttps://blog.csdn.net/a327915304/article/details/78446039/
  • 1:封装成一个类,直接调用即可。...3:linux下CPU占用的计算非常准确,支持多核。 4:硬盘容量计算极速。进度条显示占用比例。 5:多彩数码管实时显示当前时间。 6:自定义颜色下拉框,选择即可看到效果。
  • 测得某个采用按需调页策略的系统部分状态数据为:CPU利用率为20%,对换空间的磁盘利用率为98%,其他设备的利用率为5%,由此断定系统出现异常。此种情况下( )能提高利用率。 A.安装一个更快的硬盘 B.通过扩大硬盘...
  • 磁盘压测工具

    2018-06-12 05:59:21
    DISKSPD磁盘压力分析工具可以再部署安装数据库前,做过磁盘压力测试。了解磁盘性能... 磁盘压力分析工具可以再部署安装数据库前,做过磁盘压力测试。了解磁盘性能...
  • zabbix监控windows磁盘利用率

    千次阅读 2017-08-03 10:13:38
    早上来到公司,客服的打电话说他们的录音不能打开了,马上登陆服务器发现磁盘满了,录音当然不能录音了 立马备份至其他的盘中,所以现在要在监控中增加对磁盘的监控。网上查找资料放心zabbix自带的windows模板中有对...
  • 1 需求 需要查看Elasticsearch磁盘使用,方便扩容,数据迁移 2 命令 http://127.0.0.1:9012/_cat/allocation?v&pretty

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 161,103
精华内容 64,441
关键字:

磁盘利用率