2016-08-01 27 views
8

我注意到一些云托管解决方案的磁盘IO确实很差。这会导致一些问题,可以通过让脚本等待直到磁盘不太忙来解决。我该如何检查硬盘在PHP上的繁忙程度?

使用PHP可以监控文件系统的忙碌状态(或不忙),而不会让事情变得更糟?

+1

那么,你当然可以启动各种系统工具并评估他们的输出以获取任何信息,你也可以作为一个人来绘制。不过,我怀疑这在你描述的场景中确实有帮助。 您在虚拟化系统中看到的“硬盘”仅被模拟。所以公用事业可能会显示一些信息,但问题在于有多少真相。在这种情况下,性能不佳并不在系统硬件中(它无论如何都是虚拟的),但是在提供所有服务的整个网络集群内,这是您无法控制或预测的。 – arkascha

+1

我想说,如果您遇到目前的解决方案问题,可以选择更好的提供商或更好的优惠。不同提供商之间存在着巨大的差异。通常不太知名的提供商比知名公司提供更好的性能。 – arkascha

+0

我应该补充一点,我已经不在这个项目上了(并且非常感谢)。该系统在硬盘读取上存在不合理的延迟。缓存到HDD而不是数据库实际上导致连接超时。这是我曾经工作过的最糟糕的平台。我最终将配置变量存储在数据库中,因为以这种方式获得它们会更快。 –

回答

17

如果这是一个Linux系统,您可以自己计算磁盘使用情况 - 您选择实施它的语言将使用相同的概念。

您的内核很可能使用sysfs,这会在/sys上提供大量有关您的系统的信息;我们可以定期获取有关所需磁盘的信息,并根据它们之间的差异计算使用情况。

在我的系统上,我将查看磁盘,sda,你可能会有所不同。

$ cat /sys/class/block/sda/stat 
    42632  25 2045318 247192 6956543 7362278 123236256 23878974  0 3703033 24119492 

现在,如果我们看一下the Kernel documentation/sys/class/block/<dev>/stat我们可以看到下面的说明为输出的每一列。

Name   units   description 
----   -----   ----------- 
read I/Os  requests  number of read I/Os processed 
read merges  requests  number of read I/Os merged with in-queue I/O 
read sectors sectors  number of sectors read 
read ticks  milliseconds total wait time for read requests 
write I/Os  requests  number of write I/Os processed 
write merges requests  number of write I/Os merged with in-queue I/O 
write sectors sectors  number of sectors written 
write ticks  milliseconds total wait time for write requests 
in_flight  requests  number of I/Os currently in flight 
io_ticks  milliseconds total time this block device has been active 
time_in_queue milliseconds total wait time for all requests 

如果我们在一个cron日程安排,diff的一些等待时间的运行,我们可以看到我们是多么漫长的等待每个操作。您还将获得有关总IOPS和RW带宽的其他统计信息。这些文档在每个领域更深入。

无论语言选择,文件描述符打开,以获取有关磁盘信息

/sys/class/block/<dev>/stat 

如果我们做到这一点的时间表,我们可以得出看上图)

enter image description here

+7

这个答案非常好,我几乎很抱歉没有机会尝试一下。然后我想起我有多幸福不再参与这个项目。 –

+3

很抱歉重新发帖;在Meta上看到它,并且不得不分享我的图表:D但是无论项目如何,图形总是能够识别问题的好东西!祝你好运! (我使用[Grafana](https:// grafana。com /))对不起,我没有更快看到帖子! –

+2

嘿,没问题。你解决了我对如何处理这个问题的担忧。现在很有用,这是一个胜利。 –

相关问题