我使用raid0设置运行Ubuntu Lucid
我有一个1.9TB的truecrypt7.0文件容器，AES位于我的/ home（其中raid是）。
当以不同的方式testingnetworking性能时，如wget，似乎可以在第一个10-20秒内对磁盘进行写入/读取。 我注意到，下载突然停止2-3秒，然后继续 。
我已经用htop进行监控，如果它的CPU使用率过高，但通常只有1-3个核心有任何负载。 当下载突然停止时，CPU使用率不会意外爆发。 看着iostat，我只能看到2-3秒间隔的写入突发 – 假设由于caching是正确的，但我不能看到一个直接的关系，在下载/上传停止
从非truecrypt安装下载/上传时，我无法重现相同的错误，这导致我相信在读取/写入Truecrypt文件卷时会发生某些事情。
我不知道如何进一步解决这个问题，或者我可以做些调整，使其更加顺畅。 欣赏任何提示/帮助你可以给我。
谢谢
我build议dstat -cf更新一秒或更less的速度，这样你就可以得到所需要的分辨率，看到里面的1-3秒暂停。
你正在寻找的是一个单一的CPU使用率是100％或更多。 通常无法并行化encryption以利用多个处理器。 这意味着您可以将信息写入磁盘的最大速率是单个处理器可以encryption的速率。
如果在整个写入/下载过程中看到单个CPU挂起，并且写入/下载完成时，它是空闲的一部分时间，我会认为这可能是问题。
注意：当我说“单个CPU”时，我的意思是“一次一个CPU”，而不是一个特定的CPU。 由于某种原因，操作系统通常会将一个进程（如磁盘encryption）从一个CPU移到另一个CPU。 这是正常的，应该被忽略，除非这些举动特别适合下载暂停。
你可以做的其他事情是在一个未encryption的磁盘上find一个大文件（比如你至less拥有2倍的内存），看看你能够把它写到未encryption的磁盘和encryption磁盘有多快。 同时观看CPU的性能。 这将给你validation，并可能是一个好主意，你可以从系统中得到的总encryption带宽。
如果您没有发现CPU是瓶颈，请尝试使用dstat -af来显示dstat可以测量的大部分内容。 你正在寻找其他统计类似的模式来find瓶颈，类似的testing可能会有所帮助。