问题标签 [gdbm]

我在 macOS 上为 Python 3.6.8 使用 dbm.gnu 时遇到了一些问题。我已经使用 conda 在我的 Python 虚拟环境中安装了 gdbm...但是在尝试调用 dbm.gnu 时收到以下错误消息：

有什么可靠的方法可以让它工作吗？cache = False从 astropy调用时，我可以通过设置来关闭缓存download_file......但我真的很想设置cache = True. 任何帮助将非常感激。

做一个简单shelve.open的会出现以下错误：

我只遇到了一个与此问题相关的搜索结果：https ://github.com/pydanny/cookiecutter-django/issues/1793#issuecomment-440406112

我在 Vagrant 开发环境中遇到了完全相同的错误。Celery 使用 dbm 进行持久存储，它建立在 gdbm C 库之上。一些测试表明，这在本地文件系统上创建或打开文件时有效，但在已挂载的文件系统上无效。

我在 MacOS 的 Vagrant Ubuntu 机器下运行它，所以它是有道理的。我也在 Windows 10 下运行了同一个盒子，这个问题没有出现。任何修复的线索？

我是 gdbm 的新手，我想在 Perl 中使用它。我知道 Perl 默认附带一个模块（GDBM_File）。现在，当我尝试最简单的示例时，即：

并执行它我收到以下警告：

我阅读了perl 文档（请参阅提供的链接中的“untie gotcha”），但该解释似乎不适用于此处，因为很明显%db代码中没有任何引用指向它。

尽管如此，代码似乎仍然有效，因为当我检查数据库文件时，我得到了正确的结果：

为什么会出现此警告，我该如何摆脱它？

我们正在使用 astropy 来执行在 Dask 中在单个节点或集群上运行的大型 SKA 模拟。我们在计算中同时使用 Time 和 astroplan.Observer。在某些情况下，我们会看到访问 IERS 数据时出现错误。例如：

我们的解释是，这是由多个 Dask 工作人员试图访问同一个缓存文件引起的。每当在同一节点上使用多个进程或跨集群访问共享挂载点的进程时，都会发生这种情况。串行执行的相同功能不会导致此错误。

对于解决方法，我们尝试了以下方法：

这些都没有帮助。我们仍然看到相同的 gdbm 错误。你能提供什么建议吗？

谢谢。

我正在尝试将存储在非哑搁置中的数据转换为哑搁，以便能够在未安装非哑库的位置访问我的数据。

我用于转换数据库数据的测试代码如下所示：

输出如下：

我在这里做错了什么？

我有一些使用旧的 32 位 (i686) 版本的 Perl (5.8.6) 创建的 GDBM 文件，我想与 x86_64 Perl 5.28.0 一起使用，但它不起作用。这是我的测试代码：

如果我使用较旧的 i686 Perl 运行此代码并$dbmfile指向最近由同一 i686 Perl 创建的 GDBM 文件，它会正确读取 GDBM 文件并打印出其内容。

但是，如果我使用 x86_64 Perl 5.28.0 运行此代码，它就会默默地失败。没有错误。根本没有输出。

如果我使用 x86_64 Perl 5.10.1 运行此代码，则会eval捕获“错误状态”错误，然后我得到Error: Could not open /path/to/gdbm_test_file.

如果我使用 x86_64 Perl 5.28.0 创建一个新的GDBM 文件并尝试使用旧的 i686 Perl 读取它，i686 Perl 就会死掉read error。foreach

平台：CentOS 6.8

gdbm.i686 和 gdbm.x86_64 软件包均已安装且版本相同：1.8.0-39

有什么建议么？这不可能吗？

做的时候

在适用于 Windows 的标准 Python 3.7.6 (64) 上，我得到：

文件“C:\Python37\lib\dbm\gnu.py”，第 3 行，in
from _gdbm import *
ModuleNotFoundError: No module named '_gdbm'

Windows不dbm.gnu支持开箱即用？

• 同样的问题发生在：

  文件“C:\Python37\lib\dbm\ndbm.py”，第 3 行，
  从 _dbm 导入 *
  ModuleNotFoundError：没有名为 '_dbm' 的模块

• 我在另一个 Python 3.6.8 上进行了测试，结果是一样的。

您好，我正在尝试开发带有嵌入式数据库的 3 层服务器。

我的问题是我能够将数据保存在 gdbm 数据库中，但是当我尝试从其他函数检索数据时，它总是返回空值。我还指出了一个问题，即在我保存数据时键值的空终止（通过 gdb 输出验证）不以 \0 结尾，但在检索数据时它以 \0 终止我不太确定这一点理论不知道怎么解决。

我尝试过的事情：

• 尝试手动添加空字符但没有奏效
• 厌倦了从键中删除空字符，但它仍然不起作用。
• 试图从相同的结构中获取密钥，希望问题可能是由于格式不同但没有奏效
• 试图替换空字符但没有帮助，因为我不知道我做错了什么以及为什么在保存数据时没有空字符。

我附上了重现相同错误希望的最少代码，因此有人会指出我的错误，同时我仍会尝试解决此问题，但您的指南可能会有所帮助。

源代码

我刚刚将 2 台机器从 Fedora 31 升级到 33，通过升级，Perl 从 5.30.3 升级到 5.32.1。

我注意到的第一件事是 GDBM_File.pm 不再包含在 Perl Core 中，但这没问题。

我注意到的第二件事是在 fc33/perl5.32.1 中写入 GDBM非常慢。那是个问题。

我注意到第一台机器上有些问题，所以在升级之前我在第二台机器上用 fc31/perl5.30.3 运行了一个小基准测试。

gdbm1.pl 正在从一个 ascii 文本文件重建一个 db 文件，大约 33M 条目。gdbm0.pl 正在读取相同的 ascii 文本文件，并且所做的一切都与 gdbm1.pl 完全相同，除了不执行实际的哈希分配“$db{...} = ...”。这是唯一的区别。（ascii 文件大约 11GB。）

FC31/Perl5.30.3：

FC33/Perl5.32.1：

显然，写数据库比不写数据库需要更长的时间：我总是希望 gdbm0.pl 比 gdbm1.pl 快。但是 gdbm0 和 gdbm1 唯一的差异是写入数据库，所以时间差异都是由于这个原因。在 fc31/perl5.30.3 上，该差异低于 7m。在 fc33/perl5.32.1 上，时间差异是惊人的 550m - 超过 9 小时，而之前是 7 分钟。

我已经在 perl5.32.1 中搜索了有关 GDBM_File 缓慢的任何内容，但我什么也没找到。我什至不知道 Perl 是否是问题所在，可能是 fc33，或者两者兼而有之。

或者可能是 fc33 中缺少某些 C 库，而 GDBM_File 正在本机 perl 中执行所有操作。我不知道从这里去哪里。

更新：

@davem：好的，我有 3 台机器：a、b、c。“a”是最旧和最慢的，“c”是最新和最快的。机器“a”运行 ubuntu，另外两个都运行 fedora：

Linux a 5.8.0-50-generic #56~20.04.1-Ubuntu SMP Mon Apr 12 21:46:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Linux b 5.11.18-200.fc33.x86_64 #1 SMP Mon May 3 15:05:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Linux c 5.11.18-200.fc33.x86_64 #1 SMP Mon May 3 15:05:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

我在每台机器上运行了两个基准测试，首先使用内存内哈希，然后使用 gdbm 哈希。内存中的哈希结果给出了每台机器的相对单线程性能的一个非常粗略的概念：

machine_a：

machine_b：

machine_c:

更新 2：

我花了一段时间摆弄 Perl-DB_File 和 Perl-BerkeleyDB 作为 Perl-GDBM_File 的可能替代品。因为我懒得去想如何提交错误。

当然是虚假的懒惰。我终于在 2 天前提交了一个错误，并且已经有一个已签入的修复程序和待发布的版本。

@davem 完全正确，问题不在于 Perl 本身，而在于底层的 gdbm 库。从修复提交评论：

“提交 4fb2326a4a 引入了内存映射区域的预读取。在加快搜索速度的同时，它对写入操作有负面影响，因为每次重新映射都会有效地重新读取整个数据库。”

我正在测试来自dbm模块的 gdbm 数据库。有两种子模式可以打开f，s. 我最感兴趣的是快速模式（f）将所有数据保存在内存中

f, 以快速模式打开数据库。不会同步对数据库的写入。

并发现 python 以某种方式刷新磁盘上的数据。
我已经尝试过smode 并没有发现与f.

我做了什么：
python 3.8.7
GDBM 版本 1.14.1

1. 运行文件事件监控
   inotifywait -m --format '%e => %w%f' -e close -e open -e create -e delete -e modify new.gdbm
2. 打开的数据库
3. 添加数据一条记录
4. 在循环中添加了许多记录
5. 被调用sync()
6. 被调用close()

我得到的s模式：

并使用f模式：

观察：
当 python 必须同步每个修改（s 模式）时，它不会这样做。当它必须将数据保存在内存中时，它只会进行同步。同步调用不起作用，close()在这两种情况下调用后数据都会刷新到磁盘上。

如何让事情变得正确？我需要将所有数据保存在内存中，并且在关闭数据库对象时甚至不将其刷新到磁盘上。