RAMdisk 比磁盘慢？
我创建的 python 程序是 IO 受限的。大部分时间（超过 90%）花费在重复约 10,000 次的单个循环中。在这个循环中，生成了~100KB的数据并写入临时文件；然后由另一个程序读回并收集有关该数据的统计信息。这是将数据传递到第二个程序的唯一方法。
由于这是主要瓶颈，我认为将临时文件的位置从主 HDD 移动到 (~40MB) RAMdisk（在超过 2GB 的可用 RAM 内）将大大提高该文件的 IO 速度，从而降低运行时。但是，我获得了以下结果（每个结果均超过 20 次运行）：
- 测试数据 1：不带 RAMdisk - 72.7s，带 RAMdisk - 78.6s
- 测试数据 2：不带 RAMdisk - 223.0s，带 RAMdisk -
235.1s RAMdisk 比 HDD 慢。
可能是什么原因造成的？
为了获得更快的文件 IO，除了使用 RAMdisk 之外还有其他替代方法吗？
A python program I created is IO bounded. The majority of the time (over 90%) is spent in a single loop which repeats ~10,000 times. In this loop, ~100KB data is generated and written to a temporary file; it is then read back out by another program and statistics about that data collected. This is the only way to pass data into the second program.
Due to this being the main bottleneck, I thought that moving the location of the temporary file from my main HDD to a (~40MB) RAMdisk (inside of over 2GB of free RAM) would greatly increase the IO speed for this file and so reduce the run-time. However, I obtained the following results (each averaged over 20 runs):
- Test data 1: Without RAMdisk - 72.7s, With RAMdisk - 78.6s
- Test data 2: Without RAMdisk - 223.0s, With RAMdisk - 235.1s
It would appear that the RAMdisk is slower that my HDD.
What could be causing this?
Are there any other alternative to using a RAMdisk in order to get faster file IO?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您的操作系统几乎肯定已经缓冲/缓存磁盘写入。 RAM 磁盘的性能如此接近也就不足为奇了。
在不确切知道您在写什么或如何写的情况下，我们只能提供一般性建议。一些想法：
如果您有 2 GB RAM，您可能拥有一个不错的处理器，因此您可以将此数据写入具有压缩功能的文件系统。这将以 I/O 操作换取 CPU 时间，假设您的数据可以接受。
如果您正在写很多小文章，请将它们组合起来一次写出更大的文章。 （我们可以看到源代码吗？）
使用后是否删除 100 KB 文件？如果您不需要它，请删除它。否则操作系统可能会被迫将其刷新到磁盘。
Your operating system is almost certainly buffering/caching disk writes already. It's not surprising the RAM disk is so close in performance.
Without knowing exactly what you're writing or how, we can only offer general suggestions. Some ideas:
If you have 2 GB RAM you probably have a decent processor, so you could write this data to a filesystem that has compression. That would trade I/O operations for CPU time, assuming your data is amenable to that.
If you're doing many small writes, combine them to write larger pieces at once. (Can we see the source code?)
Are you removing the 100 KB file after use? If you don't need it, then delete it. Otherwise the OS may be forced to flush it to disk.
您可以批量写出数据而不是一次写出一项吗？您是否正在缓存打开文件句柄等资源或清理它们？您的磁盘写入是否阻塞，是否可以使用后台线程来饱和 IO，同时不影响计算性能。
我会首先考虑优化磁盘写入，然后在完成后考虑更快的磁盘。
Can you write the data out in batches rather than one item at a time? Are you caching resources like open file handles etc or cleaning those up? Are your disk writes blocking, can you use background threads to saturate IO while not affecting compute performance.
I would look at optimising the disk writes first, and then look at faster disks when that is complete.
我知道 Windows 在 RAM 中缓存磁盘数据非常积极，100K 就可以轻松满足。写入将直接进入缓存，然后可能通过非阻塞写入写入磁盘，这允许程序继续运行。 RAM 磁盘可能不支持非阻塞操作，因为它希望这些操作很快并且不值得麻烦。
通过减少程序和缓存可用的内存量，您将增加用于分页的磁盘 I/O 量，即使只是稍微增加。
这都是我的猜测，因为我不熟悉内核或驱动程序。我还推测 Linux 也会有类似的操作。
I know that Windows is very aggressive about caching disk data in RAM, and 100K would fit easily. The writes are going directly to cache and then perhaps being written to disk via a non-blocking write, which allows the program to continue. The RAM disk probably wouldn't support non-blocking operations because it expects those operations to be quick and not worth the bother.
By reducing the amount of memory available to programs and caching, you're going to increase the amount of disk I/O for paging even if only slightly.
This is all speculation on my part, since I'm not familiar with the kernel or drivers. I also speculate that Linux would operate similarly.
在我的测试中，我发现不仅批量大小会影响整体性能，还会影响数据本身的性质。仅在一种情况下，我就成功地获得了比 SSD 快 5 倍的写入时间：将 100MB 的预煮随机字节数组块写入 RAM 驱动器。写入更多“可预测”数据（例如字母“aaa”或当前日期时间）会产生完全相反的结果 - SSD 总是更快或相同。所以我的猜测是操作系统（在我的例子中是Win 7）做了很多缓存和优化。
看起来 RAM 驱动器最受阻碍的情况是当您执行大量小写入而不是一些大写入时，而 RAM 驱动器在写入大量难以压缩的数据方面表现出色。
In my tests I've found that not only batch size affects overall performance, but also the nature of data itself. I've managed to get 5 times better write times compared to SSD in only one scenario: writing a 100MB chunk of pre-cooked random byte array to RAM drive. Writing more "predictable" data like letters "aaa" or current datetime yields quite opposite results - SSD is always faster or equal. So my guess is that opertating system (Win 7 in my case) does lots of caching and optimizations.
Looks like the most hindering case for RAM-drive is when you perform lots of small writes instead of a few big ones, and RAM drive shines at writing large amounts of hard-to-compress data.
我也有过同样令人难以置信的经历，经过多次尝试后我找到了答案。
当 ramdisk 格式化为 FAT32 时，即使基准测试显示较高的值，但实际使用速度实际上比 NTFS 格式的 SSD 慢。
但在现实生活中，NTFS 格式的 ramdisk 比 SSD 更快。
I had the same mind boggling experience, and after many tries I figured it out.
When ramdisk is formatted as FAT32, then even though benchmarks shows high values, real world use is actually slower than NTFS formatted SSD.
But NTFS formatted ramdisk is faster in real life than SSD.
我和那些遇到 RAM 磁盘速度问题的人一样（仅在 Windows 上）。
我拥有的 SSD 可以写入 30 GiB（在一个大块中，转储 30GiB RAM 阵列），速度为 550 MiB/s（写入 30 GiB 大约需要 56 秒）...这是如果在一个源中请求写入的情况代码语句。
我拥有的 RAM 磁盘 (imDisk) 可以写入 30 GiB 写入（在一个大块中，转储 30 GiB RAM 阵列），速度略低于 100 MiB/s（写入 30 GiB 大约需要 5 分 13 秒）。 ..这是如果在一个源代码句子中询问写入的情况。
我还做了另一项 RAM 测试：从源代码执行顺序直接写入（每个源代码循环传递一个字节）到 30GiB RAM 阵列（我有 64GiB 的 RAM），我得到的速度接近 1.3GiB/s (1298 MiB 每秒）。
为什么（在 Windows 上）RAM 磁盘对于一个大的连续写入来说如此缓慢？
当然，Windows 上的 RAM 磁盘的写入速度较低，因为我在 Linux 上使用 Linux 原生 RAM 磁盘测试了相同的“概念”，并且 Linux RAM 磁盘可以以每秒近 1 GB 的速度写入。
请注意，我还在 Windows 上测试了 SoftPerfect 和其他 RAM 磁盘，RAM 磁盘速度几乎相同，写入速度不能超过每秒 100 兆字节。
实际 Windows 测试：10 & 11（在 HOME 和 PRO 上，64 位），RAM 磁盘格式（exFAT 和 NTFS）；由于 RAM 磁盘速度太慢，我试图找到一个 RAM 磁盘速度正常的 Windows 版本，但没有找到。
实际测试的 Linux 内核：仅 5.15.11，因为 Linux 本机 RAM 磁盘速度正常，所以我没有在任何其他内核上进行测试。
希望这对其他人有帮助，因为知识是解决问题的基础。
I join the people having problems with RAM disk speeds (only on Windows).
The SSD i have can write 30 GiB (in one big block, dump a 30GiB RAM ARRAY) with a speed of 550 MiB/s (arround 56 seconds to write 30 GiB) ... this is if the write is asked in one source code sentence.
The RAM Disk (imDisk) i have can write 30 GiB write (in one big block, dump a 30GiB RAM ARRAY) with a speed of a bit less than 100 MiB/s (arround 5 minutes and 13 seconds to write 30 GiB) ... this is if the write is asked in one source code sentence.
I had also done another RAM test: from source code do a sequential direct write (one byte per source code loop pass) to a 30GiB RAM ARRAY (i have 64GiB of RAM) and i get a speed of near 1.3GiB/s (1298 MiB per second).
Why on the hell (on Windows) RAM Disk is so slow for one BIG secuential write?
Of course that low write speed happens on RAM disks on Windows, since i tested the same 'concept' on Linux with Linux native ram disk and Linux ram disk can write at near one gigabyte per second.
Please note that i had also tested SoftPerfect and other RAM disks on Windows, RAM Disk speeds are near the same, can not write at more than one hundred megabytes per second.
Actual Windows tested: 10 & 11 (on both HOME & PRO, on 64 bits), RAM Disk format (exFAT & NTFS); since RAM disk speed was too slow i was trying to find one Windows version where RAM disk speed be normal, but found no one.
Actual Linux Kernel tested: Only 5.15.11, since Linux native RAM disk speed was normal i do not test on any other kernel.
Hope this help other people, since knowledge is the base to solve a problem.