使用 numpy.memmap 时磁盘写入过多
Excessive disk writes when using numpy.memmap
我已经使用 numpy.memmap 实现了一个文件支持的哈希表。它似乎运行正常,但是,我注意到在 Linux 上,KSysGuard 和 SMART 都报告了荒谬的 IO 写入量。大约是应该写入的数据量的 50 倍。我没有在其他操作系统上测试过。
这是创建内部内存映射的代码
self.data = np.memmap(self.filename,
shape=(self.nbuckets, self.bucket_size),
dtype=[('key', 'u8'), ('time', 'u2'), ('flags', 'u2'), ('id', 'i4')], mode=mode)
下面是在应用散列函数后将单个条目写入 table 的代码:
def store(self, id_, time_, key, i):
bucket = self.data[i]
head = bucket[0]
if bucket[1]['flags'] & HashTable.FLAG_INUSE == 0:
free = bucket[1]
head['id'] = 1 #we use the first entry in the bucket to count how full it is
self.written += 4 #4 bytes written to set that counter to 1
elif head['id'] < self.bucket_size:
free = bucket[head['id'] ]
else:
return False
free['key'] = key
free['time'] = time_
free['flags'] |= HashTable.FLAG_INUSE
free['id'] = id_
head['id'] += 1
self.dirty = True
self.written += 20 #16 bytes for the entry, +4 bytes for updating bucket usage counter
return True
我添加了 self.written
变量来跟踪写入了多少字节,并确定该函数是否被调用了太多次。
对于大约 300 万个条目,self.written
最后报告了大约 60 MiB,根据我的计算这是合理的,这意味着存储函数没有被过度调用。然而,KSysGuard 和 SMART (data_units_written) 报告程序总共写入了 3 GiB。我正在使用的 HashTable 设置为 100 MiB 并且没有损坏或任何东西,所以我怀疑它只是一遍又一遍地将相同的数据写入相同的位置。但我无法弄清楚代码中的哪个位置可能会发生这种情况。
我不是 100% 确定 HashTable 文件正在发生写入,但是当我将它放入 ramdisk (tmpfs) 时,KSysGuard 和 SMART 没有报告磁盘写入。
我在 Debian Bullseye 上使用 Python 3.9.2 和 numpy 1.21.0。
如果有人能帮我解决这个问题,我将不胜感激。
谢谢。
memmap
通过在虚拟内存中映射 页 来工作(通常映射到物理内存页面或存储设备页面,如您的情况)。在大多数平台上,页面大小至少为 4 KiB。因此,在一个页面中的任何写入都可能导致整个页面被更新。
SSD 和更普遍的闪存也使用块,但它们通常使用更大的块。实际上,闪存使用写入次数非常有限的单元(例如 1000)。当单元格被过多覆盖时,它们会变得不稳定并且可能无法 read/written 正确。结果,闪存设备避免了对单元的任何直接写入访问,并且将写入的数据块移动到新位置以保存单元,同时相对较快。 一旦写入,块就不能改变:需要分配并写入一个新块来替换旧块。因此,在闪存设备上随机写入几个字节会导致它分配大量新块并复制大量(未更改的)数据块。这也会显着影响目标存储设备的寿命。
这可以解释为什么 SMART 信息报告如此大量的 IO 写入。
请注意,HDD 没有此问题,但与 SSD 相比,随机写入非常慢(由于移动磁头的时间)。替代非易失性 RAM,如铁电 RAM 或磁阻 RAM 可以正确解决这个问题。不幸的是,目前此类 RAM 还处于试验阶段。
一种可能的修复方法是将修改后的数据块存储在 RAM 中,按位置对块进行排序,然后一次写入所有数据。如果数据集很大,写的很均匀,那么目前主流硬件上没有解决方案。
我已经使用 numpy.memmap 实现了一个文件支持的哈希表。它似乎运行正常,但是,我注意到在 Linux 上,KSysGuard 和 SMART 都报告了荒谬的 IO 写入量。大约是应该写入的数据量的 50 倍。我没有在其他操作系统上测试过。
这是创建内部内存映射的代码
self.data = np.memmap(self.filename,
shape=(self.nbuckets, self.bucket_size),
dtype=[('key', 'u8'), ('time', 'u2'), ('flags', 'u2'), ('id', 'i4')], mode=mode)
下面是在应用散列函数后将单个条目写入 table 的代码:
def store(self, id_, time_, key, i):
bucket = self.data[i]
head = bucket[0]
if bucket[1]['flags'] & HashTable.FLAG_INUSE == 0:
free = bucket[1]
head['id'] = 1 #we use the first entry in the bucket to count how full it is
self.written += 4 #4 bytes written to set that counter to 1
elif head['id'] < self.bucket_size:
free = bucket[head['id'] ]
else:
return False
free['key'] = key
free['time'] = time_
free['flags'] |= HashTable.FLAG_INUSE
free['id'] = id_
head['id'] += 1
self.dirty = True
self.written += 20 #16 bytes for the entry, +4 bytes for updating bucket usage counter
return True
我添加了 self.written
变量来跟踪写入了多少字节,并确定该函数是否被调用了太多次。
对于大约 300 万个条目,self.written
最后报告了大约 60 MiB,根据我的计算这是合理的,这意味着存储函数没有被过度调用。然而,KSysGuard 和 SMART (data_units_written) 报告程序总共写入了 3 GiB。我正在使用的 HashTable 设置为 100 MiB 并且没有损坏或任何东西,所以我怀疑它只是一遍又一遍地将相同的数据写入相同的位置。但我无法弄清楚代码中的哪个位置可能会发生这种情况。
我不是 100% 确定 HashTable 文件正在发生写入,但是当我将它放入 ramdisk (tmpfs) 时,KSysGuard 和 SMART 没有报告磁盘写入。
我在 Debian Bullseye 上使用 Python 3.9.2 和 numpy 1.21.0。
如果有人能帮我解决这个问题,我将不胜感激。 谢谢。
memmap
通过在虚拟内存中映射 页 来工作(通常映射到物理内存页面或存储设备页面,如您的情况)。在大多数平台上,页面大小至少为 4 KiB。因此,在一个页面中的任何写入都可能导致整个页面被更新。
SSD 和更普遍的闪存也使用块,但它们通常使用更大的块。实际上,闪存使用写入次数非常有限的单元(例如 1000)。当单元格被过多覆盖时,它们会变得不稳定并且可能无法 read/written 正确。结果,闪存设备避免了对单元的任何直接写入访问,并且将写入的数据块移动到新位置以保存单元,同时相对较快。 一旦写入,块就不能改变:需要分配并写入一个新块来替换旧块。因此,在闪存设备上随机写入几个字节会导致它分配大量新块并复制大量(未更改的)数据块。这也会显着影响目标存储设备的寿命。 这可以解释为什么 SMART 信息报告如此大量的 IO 写入。
请注意,HDD 没有此问题,但与 SSD 相比,随机写入非常慢(由于移动磁头的时间)。替代非易失性 RAM,如铁电 RAM 或磁阻 RAM 可以正确解决这个问题。不幸的是,目前此类 RAM 还处于试验阶段。
一种可能的修复方法是将修改后的数据块存储在 RAM 中,按位置对块进行排序,然后一次写入所有数据。如果数据集很大,写的很均匀,那么目前主流硬件上没有解决方案。