Windows 7:下载数据时，我的程序中的GUI响应不佳；有什么办法可以改善这一点? [英] Windows 7: poor GUI response in my program while downloading data; is there some way to improve this?

问题描述

我编写了一个程序，该程序(除其他外)使用TCP从LAN上的服务器下载多个大文件.该程序可以在Linux，MacOS/X和Windows上正常运行(它在GUI上使用Qt，并在网络中使用直接套接字调用)，但是在某些Windows机器上，下载量太大，机器无法处理，我想知道是否有人对此有任何想法，对此可以采取什么措施.

下载文件时，我的程序会生成一个单独的I/O线程，该线程基本上位于一个循环中，通过TCP下载数据并将其写入文件，每次调用QFile:write()时写入128KB.每个文件的长度通常为数百兆字节，并且典型的下载会话会写出数十个这些文件.请注意，I/O线程独立于GUI线程运行，因此，我不希望它对GUI的性能产生任何影响，尤其是在多核PC上运行时.

有问题的PC是运行于2.40GHz的Core-2Duo Quad Q6600，具有4GB的RAM.它运行的是Windows 7 Ultimate SP1(32位).它正在通过千兆以太网连接接收数据，并将其写入232GB内部Hitachi ATA驱动器的NTFS格式的引导分区中的文件中.

症状是，有时在下载过程中(似乎是随机的)，程序的GUI会在每次10到30秒内变为无响应，并且窗口的标题栏通常会附加(无响应)"做到这一点.然后，症状将再次清除，下载将再次正常进行.另一个症状是下载过程中桌面非常呆滞……例如，如果我单击开始"按钮，则开始菜单将花费约30秒的时间来填充，而不是像我期望的那样瞬间被填充

请注意，任务管理器显示了大量可用内存，但确实显示出CPU使用率短暂升高，达到4个内核之一的100％，同时又看到了问题.

数据正在通过千兆以太网到达，并且如果我让我的程序仅接收数据并将其丢弃(不将其写入硬盘)，则机器可以保持约96MB/sec的恒定下载速率而不会中断出汗.但是，如果我将接收到的数据写到文件中，下载速度将降低到约37MB/秒，并且上述症状开始出现.

有趣的是，只是出于好奇，我在事件循环开始之前将此调用添加到了I/O线程的入口函数中:

SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_BELOW_NORMAL);

当我这样做时，(无响应)"症状消失了，但是下载速度却降低到了〜25MB/sec.

所以我的问题是:

• 有人知道硬盘驱动器承受大量写负载时可能导致GUI偶发性挂断的原因吗?

• 考虑到计算机上有三个空闲内核，为什么降低I/O线程的优先级会导致下载率下降太多?我认为在这种情况下，即使是低优先级的线程也将有大量可用的CPU.

• 有什么方法可以在不导致Windows桌面响应和/或我的应用程序GUI响应出现问题的情况下获得最大下载速度?

解决方案

没有看到任何代码很难回答，但这似乎与处理器有关，并且您的下载线程没有为其他线程留出空间执行其他操作.

似乎永远都没有等待，并且网卡的驱动程序编写得不好. 当没有数据传入时，您确定您的线程正在进入空闲状态吗? 在具有单个处理器的OS中，for(;;){}将消耗100％的cpu，并且如果它与内核连续通讯，它可能会停止其他进程或其他线程来执行此操作，尤其是在存在错误或行为很差的情况下在您的情况下使用某些网卡驱动程序.

您可能会要求线程优先级低于正常水平，这是要求操作系统减少使用线程的频率，这是一种神奇的组合，使事情不会挂太多. 检查代码，也许您忘记了什么?

检查是否添加了sleep(0)来迫使操作系统在某个时候让另一个线程屈服，这会使情况变得更好，但这是一个临时性的解决方法，您应该找出线程消耗100％cpu的原因，如果是这样的话./p>

I've written a program that (among other things) downloads multiple large files from a server on the LAN, using TCP. This program runs fine under Linux, MacOS/X, and generally under Windows as well (it uses Qt for the GUI and straight sockets calls for networking), but on certain Windows machines the download appears to be too much for the machine to handle, and I'm wondering if anyone has any ideas as to why that is and what can be done about it.

When downloading files, my program spawns a separate I/O thread that basically just sits in a loop, downloading data over TCP and writing it to a file, writing 128KB per call to QFile:write(). Each file is typically several hundred megabytes long, and a typical download session writes out several dozen of these files. Note that the I/O thread runs independently of the GUI thread, so I wouldn't expect it to affect GUI's performance much if at all -- especially not when running on a multicore PC.

The PC in question is a Core-2Duo Quad Q6600 running at 2.40GHz, with 4GB of RAM. It's running Windows 7 Ultimate SP1, 32-bit. It is receiving data over a Gigabit Ethernet connection and writing it to files on the NTFS-formatted boot partition of the 232GB internal Hitachi ATA drive.

The symptom is that sometimes during a download (seemingly at random) the program's GUI will become non-responsive for 10 to 30 seconds at a time, and often the title bar of the window will have "(not responding)" appended to it. The symptom will then clear up again and the download will proceed normally again. Another symptom is that the desktop is extremely sluggish during the download... for example, if I click on the "Start" button, the Start menu will take ~30 seconds to populate, instead of being populated near-instantaneously as I would expect.

Note that Task Manager shows plenty of free memory, but it does show short spikes of CPU usage to 100% one one of the 4 cores, at the same time the problems are seen.

The data is arriving over Gigabit Ethernet, and if I have my program just receive the data and throw it away (without writing it to the hard drive), the machine can maintain a constant download rate of about 96MB/sec without breaking a sweat. If I write the received data to a file, however, the download rate decreases to about 37MB/sec, and the symptoms described above start to appear.

The interesting thing is that just for curiosity's sake I added this call to my I/O thread's entry function, just before the beginning of its event loop:

SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_BELOW_NORMAL);

When I did that, the "(not responding)" symptoms cleared, but then download speed was reduced to only ~25MB/sec.

So my questions are:

• Does anyone know what might be causing the sporadic hangups of the GUI when the hard drive is under a heavy write-load?

• Why does lowering the I/O thread's priority cause the download rate to drop so much, given that there are three idle cores on the machine? I would think that even a lower-priority thread would have plenty of CPU available in this situation.

• Is there any way to get a maximum download rate without causing Windows' desktop responsiveness and/or my app's GUI responsiveness to suffer problems?

解决方案

Without seeing any code is hard to answer but this seems to be something related to processors and the fact that your download thread is not leaving any space for other threads to performs other operations.

It seems it never waits and that the driver of the network card is not well written. Are you sure your thread is entering in an idle state when there is no data incoming? In OS with a single processor a for (;;) {} will consume 100% cpu and if it talks continuously with the kernel it may stops other processes or other threads for doing that, especially if there is a bug or a very bad behaviour in some network card driver in your case.

Probably putting the thread priority below normal you are asking the OS to use your thread less often, this gives by a magical combination of things that allow things to not hang too much. Check the code, maybe you are forgetting something?

Check if adding a sleep(0) to force the OS to yield to another thread sometime will make things better, but this is a temporary fix, you should find why your thread is consuming 100% cpu, if it is.

这篇关于Windows 7:下载数据时，我的程序中的GUI响应不佳；有什么办法可以改善这一点?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！