我正在通过 Qt 开发一个应用程序。
在这个应用程序中，主线程是一个网络服务器。另一个线程有时会从大文件 (250mb) 中读取数据并将它们写入输出文件 (~2gb)。
该线程对文件进行高I/O操作，CPU iowait在70%左右。
我的问题是写入文件时，网络服务器没有快速响应。我的理解是服务器的 qt 套接字(在 Linux 上)由连接到轮询或选择事件系统的系统套接字表示。所以 Qt 仅在轮询发出事件时才向我的应用程序发送信号。
我的想法是，写入文件的大量 io 操作可能会阻塞轮询系统，因此我的 qt 服务器不会接收到套接字事件。当线程完成数据写入后，一切正常。
文件的写法是这样的:
while(dataToRead){
// context has the list of files to read and current step
dataToRead = extractData(context, &pBuffer, &sizeBuf);
fwrite (pBuffer, 1, sizeBuf, pOutFile);
free(pBuffer);
pBuffer = NULL;
// usleep(100000);
}
如果我添加一个 break with usleep 函数，这有助于避免问题，但如果我没有使用足够大的 sleep ，则不能完全避免。但是太大的 sleep 会破坏性能，我是尽可能快地生成文件。
我做错了什么？尽可能快地读/写文件是否安全？在上述功能中是否必须 sleep ？但是我们怎么知道好的时间片呢？
我正在研究 Mint LMDE、Linux 3.2.0 64 位、Intel Core i5 2500 和标准 HDD 驱动器。
编辑: 此处提供了重现该问题的示例程序:https://bugreports.qt-project.org/secure/attachment/30436/TestQtBlocked.zip .需要qt的qmake来编译。如果你运行它，它会创建一个空的 3GB 文件，工作线程将在启动时启动并在几秒钟内创建文件。在此期间，如果您尝试连接到 http://localhost:8081/并多次运行 F5 刷新页面，您会发现有时它没有快速响应。 如果有人可以用我的示例程序重现我的问题并告诉我，这可能会有所帮助。
最佳答案
如果您正在等待主线程的选择调用，请创建一个单独的线程来执行文件 I/O。当事件来自 Qt 时，触发某种 IPC 唤醒您的工作线程以执行大文件 I/O 并立即从您的事件处理程序返回。
(假设异步写入文件对您的程序逻辑有意义。只有您自己才能弄清楚这是不是真的。)
关于c++ - 在 C++ 中读取/写入大文件的性能问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13846033/