如何减少写入磁盘的旧版应用程序和实时读取磁盘的应用程序上的文件 IO (.NET)
我的情况是我有一个遗留应用程序，我没有每秒左右将数据写入磁盘的代码。我编写了一个 C# 程序，每秒都会读取写入磁盘的内容并使用这些数据。数据被写入几个文本文件，我在创建之前知道文件名。
问题是我有很多虚拟机运行这个旧应用程序和我的程序。它们不受 ram 或 cpu 的限制，但由于文件 io 瓶颈，我无法在每台机器上添加超过 10 个虚拟机。
有没有一种简单的方法可以在磁盘上创建存在于内存或其他东西中的文件？我听说命名管道是一种选择？
谢谢！
My situation is I have a legacy app which I don't have the code for which writes out data to disk every second or so. I have a C# program I wrote which every second reads what was written to disk and uses the data. The data is written to a few text files which I know the file name before its created.
The issue is I have lots of virtual machines running this legacy app and my program. They are not limited by ram or cpu but I can't add more than 10 VMs per machine due to file io bottleneck.
Is there an easy way I can make a file on disk that exists in ram or something else? I heard something about named pipes being an option?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您确定实际涉及的 IO 吗？
很久以前，我实现了一个非常丑陋的连接，通过文件的方式将数据从 dos 程序发送到 Windows 程序。不过，这比每秒一次要快得多——只要上面的任何内容发生变化，dos 程序就会发送一个 4k 块，每秒 50 次（如果被捕获）Windows 程序会读取帧号，然后读取如果帧编号不同，则为 4K 块。
这没有导致磁盘IO！您可以坐在那里，让 dos 程序每秒多次更新帧，只要您愿意，硬盘驱动器灯就会保持关闭状态。 Windows 发现文件已打开并且被频繁写入，缓冲区不会刷新到磁盘，直到更新停止。
虽然我花了很多时间优化 Windows 端的链接，但这一切都在处理数据，而不是在连接上——尽管它看起来很丑陋，但这根本不是瓶颈。
如果每次都关闭文件，Windows 可能会以不同的方式处理它。即使如此，将其粘贴在 ramdisk 上也会阻止它执行磁盘 IO。
Are you sure of the actual IO involved?
Long ago I implemented a very ugly connection sending data from a dos program to a Windows program by means of a file. This was a lot faster than once a second, though--the dos program would send a 4k block anytime anything on it changed, 50 times a second (if it was caught up) the Windows program would read the frame number and then read the 4K block if the frame number differed.
This did NOT cause disk IO! You could sit there causing the dos program to update the frame many times a second for as long as you wanted and the hard drive light would stay off. Windows saw the file was open and being frequently written, the buffers were NOT flushed to disk until the updates stopped.
While I spent a lot of time optimizing the Windows side of the link it was all in what was done with the data, not in the connection--that simply wasn't a bottleneck despite it's apparent ugliness.
It's possible Windows would handle it differently if the file was closed each time. Sticking it on a ramdisk would keep it from doing the disk IO even then.
您可以搜索某种内存/临时文件系统。
我不确定您是否可以在此处使用管道，因为您的旧应用程序直接写入硬盘。
You can search for some kind of memory/temporary file systems.
I'm not sure if you can use pipes here since you legacy app is writing directly to the HDD.