问题标签 [disk-io]

我有一个大约 2000 个对象的列表（在本例中是 Teamspeak 频道），我想记录（到磁盘）它们是否为空，以确定正在使用哪些对象。

我在解决这个问题时遇到了麻烦，因为我每 10 秒插入 2000 次，这使我的磁盘抖动。但是我相信一定有更好的方法来做到这一点！我只是想获得一份未使用频道的列表（例如，空了 2 周的频道）以便稍后删除。

我应该使用关系数据库吗？有没有更好的方法来完成我想做的事情？

我使用来自第 3 方的应用程序，该应用程序不断（大约每秒 2k - 每天大约 80 兆）写入日志文件。我不相信应用程序从日志文件中读取，我相信它只是为了调试目的。这是一台 Windows 2008 R2 机器，它写入用户目录中“漫游”中的子文件夹。

Windows 中有没有办法让它不写入数据（但仍然返回成功消息）？我不希望应用程序失败，但希望没有那种持续的磁盘活动。

任何简单/干净的选择？

谢谢！

我创建了一个程序来测试分片 MongoDB 在 Linux（Ubuntu）和 Windows（Server2008）上的性能。由于插入了大量记录，Windows 的磁盘活动时间非常高（100%），性能非常差。但在 Ubuntu 上，磁盘的 util% 为 60%~70%，性能优于 Windows。我可以说 MongoDB 在 Linux 上的性能更好吗？

在使用 libevent 检测非阻塞磁盘文件描述符的读/写准备情况（对于强制锁定保护的文件）时，我遇到了以下问题：

当一个文件被另一个进程锁定为 IO 时，当我发出读/写调用时，我在当前进程中得到 EAGAIN，这与 API 的记录行为完全一致。

但是，当 libevent 轮询这些 FD 以了解 IO 就绪情况时，它们会被检测为 IO 就绪，这会导致调用我的回调。

我一直在尝试为此找到解决方案，但我不知道我是否在正确的行上搜索。是否可以避免这些电话？

当我尝试使用 cosbench 测试集群的性能时，我发现对象存储 swift 的性能每 30 秒波动一次。做了一个实验如下：

1台代理服务器和5台存储服务器（3台用于对象服务器，另外2台用于帐户/容器服务器），每台服务器配备8*1T硬盘、64GB内存和12个CPU内核。只是启动了服务对象服务器。当只有一个客户端将小对象放入集群时，就会出现这种现象。我发现许多磁盘请求到达并且所有磁盘延迟每 30 秒突然上升一次。任何人都可以告诉我为什么会发生这种情况。

我正在考虑为我正在构建的数据库系统创建一个明智的写入缓存（WOW 缓存）排序，但是我在将文件区域映射到物理磁盘区域时遇到了麻烦。

我发现您可以使用DeviceIoControl来获取文件的虚拟集群分配，但我不确定如何将其与物理磁盘位置相关联。

这在 Windows 上可行吗？如果没有，是否有解决方法或更适用的写入缓存算法。

这是我的 bash 脚本的一部分：

当我运行脚本时，bash 返回以下错误：disk_status.sh: line 38: [: : integer expression expected

错误行是：if [ "${status[1]}" -ne 0 ]

有人可以帮助解决这个错误吗？

以前，建议使用一个副本来解释每个进程的统计信息，而不是我需要的每个文件。经过几天的搜索，我找不到任何特定的方法来获取每个文件的磁盘统计信息。

我正在编写一个 PerfMonitor 并希望它显示哪个文件具有扩展的读写操作。很像这样： （Windows 性能监视器）

我尝试了所有 PerfCounters，包括深度 WMI 搜索，但都只给出整个 FileSystem 的数字或“一个数字代表整个进程”。

我试图为每个进程列出其文件句柄，然后以这种方式获取一些信息，但找不到任何方法从文件句柄中获取此统计信息。

我在某处读到 Hook 每个进程以计算所有 ReadWrite 字节，但挂钩整个系统看起来并不简单和/或高效

绝望 我使用反汇编程序查看 Windows PerfMon 正在使用哪些功能，但我还是一无所获。

有人听说过可以帮助我的事情吗？

提前致谢。

我很难理解磁盘调度的 SCAN 和 CSCAN 算法的工作原理。我了解 FCFS，Closest Cylinder Next，但听说 SCAN 类似于电梯机制并感到困惑。我的书说，对于传入的订单：[10 22 20 2 40 6 38]（而磁盘当前为 20）在开始时移动的 SCAN 服务于 [(20) 20 22 38 40 10 6 2]; 这需要移动[0 2 16 2 30 4 4]个气缸，总共58个气缸。模式 [(20) 20 22 38 40 10 6 2] 是怎么来的？

如果执行以下数据库（postgres）查询，则第二次调用要快得多。

我猜第一个查询很慢，因为操作系统（linux）需要从磁盘获取数据。第二个查询受益于文件系统级别和 postgres 中的缓存。

有没有办法优化数据库以在第一次调用时快速获得结果？

第一次通话（慢）

第二次调用（快速）

foo3_text 表的表布局（28M 行）

硬件更改（SSD 代替传统磁盘）或 RAM 磁盘是可能的。但也许当前的硬件也可以做出更快的结果。

版本：x86_64-unknown-linux-gnu 上的 PostgreSQL 9.1.2

如果您需要更多详细信息，请发表评论。