1

我已经使用numpy.memmap实现了一个文件支持的 HashTable 。它似乎运行正常，但是，我注意到在 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)

以下是应用哈希函数后将单个条目写入表的代码：

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。

如果有人能帮我解决这个问题，我将不胜感激。谢谢你。

4

1 回答 1

1

memmap通过映射虚拟内存中的页面（通常映射到物理内存页面或存储设备页面，如您的情况）来工作。在大多数平台上，页面大小至少为 4 KiB。因此，页面中的任何写入都可能导致整个页面被更新。

SSD 和更普遍的闪存也使用块工作，但它们通常使用更大的块。实际上，闪存使用写入次数非常有限的单元（例如 1000 次）。当单元格被过多覆盖时，它们会变得不稳定并且可能无法正确读取/写入。因此，闪存设备避免了对单元的任何直接写入访问，并将写入的数据块移动到新位置以保存单元，同时速度相对较快。一旦写入，块就不能被改变：需要分配和写入一个新块来替换旧块。因此，仅在闪存设备上随机写入几个字节会导致它分配大量新块并复制大量（未更改的）数据块。这也会显着影响目标存储设备的寿命。这可以解释为什么 SMART 信息会报告如此大量的 IO 写入。

请注意，HDD 没有这个问题，但与 SSD 相比，随机写入非常慢（由于移动磁头的时间）。铁电 RAM 或磁阻 RAM 等替代非易失性 RAM 可以正确解决此问题。不幸的是，这种 RAM 目前还处于相对实验阶段。

一种可能的解决方法是将修改后的数据块存储在 RAM 中，按位置对块进行排序，然后一次将它们全部写入。如果数据集庞大，写入分布非常均匀，那么目前主流硬件上没有解决方案。

于 2021-07-28T12:23:34.063 回答