【问题标题】:Many open files leading to uninterruptible sleep "D state"许多打开的文件导致不间断的睡眠“D 状态”
【发布时间】:2021-10-13 13:40:30
【问题描述】:

我创建了一个约 3TB 的二进制文件(位于 AWS EBS 卷上),旨在存储一个 MxN 的双精度矩阵,表示多天的统一财务时间序列。有 M=37932 个不同的时间序列,每个时间序列有 N=10415118 个元素。

我有一个 C++ 程序,它读取特定日期的金融市场数据,创建指向上述二进制文件中适当起始位置的 M 文件指针,然后在在处理金融市场数据时正确的文件指针。

我正在使用一个运行 Ubuntu 16.04 的 72 核 AWS EC2 实例,并且一次在 54 个进程中并行运行上述 C++ 程序(总共有数百个日期要经过)。因此,总共有大约 54*37932=2048328 个文件指针在系统上一次打开。

一段时间后,进程开始卡在不间断的睡眠“D 状态”并挂起。有谁知道为什么会这样?当我并行运行较少的上述进程时,这个问题往往会较少出现。

我在 EBS 卷上也注意到了这一点,可能是它引起了问题?我不确定它是否对 EBS 卷有意义以及是否/如何修复它。

$ sudo xfs_db -c frag -r /dev/nvme2n1 
actual 1468060, ideal 16154, fragmentation factor 98.90%

(不确定这是否更适合 ServerFault)

【问题讨论】:

    标签: linux amazon-web-services sleep blocking fragmentation


    【解决方案1】:

    当磁盘驱动程序在磁盘中寻找某些数据并且必须等待磁盘以继续该过程时,进入不间断的 D 状态。通常情况下,进程停留在 D 状态是硬件故障的结果(在您使用的平台上不应该发生这种情况),但最糟糕的是在一个文件中的日志数据量为 3 TB。这不仅很奇怪,而且会迫使您死于硬件故障,因为您将所有鸡蛋放在同一个篮子里。如果您描述您的数据并将其调整到可能包含历史数据的几个目录中的这个巨大的数据,那会更好。一组描述您的矩阵的文本文件将是存储数据的更安全和可靠的方式,如果您稍微考虑一下数据结构,您甚至可以进行良好的压缩。

    无法提供更多帮助,因为您只是描述了您订购给亚马逊服务以处理您的矩阵的绝妙系统......但您没有描述您存储在其中的东西。无法帮助您,只能建议向亚马逊索要一台更大的计算机,因为您现在拥有的计算机根本无法处理您的数据。更好地重组数据可能会改善您的网格,但您刚刚描述了一个完全未被充分利用的绝妙系统。

    【讨论】:

      猜你喜欢
      • 2013-11-01
      • 2012-02-02
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-12-16
      • 1970-01-01
      • 2021-04-12
      相关资源
      最近更新 更多