我正在使用raid0安装程序运行Ubuntu
我在我的/home ( raid所在的地方)中有一个带有AES的1.9Tbtruecrest7.0文件容器。
当以不同的方式测试网络性能时,比如wget,它似乎能够在最初的10-20秒内对磁盘进行读写。我注意到下载突然停止2-3秒,然后继续。
我对htop进行了监控,如果cpu使用率过高,但通常只有1-3个内核有负载。当下载突然停止时,cpu使用率不会突然中断。在iostat中,我只看到2-3秒间隔的写入-假设这是正确的,因为缓存,但我不能看到与停止下载/上传的直接关系。
在下载/上载到/从非truecrypt挂载下载/上载时,我无法复制相同的错误,这使我相信在读/写truecrypt文件卷时会发生一些事情。
我不知道如何进一步解决这一问题,或者如果有调整,我可以做,以使它更顺利。感谢你能给我的任何建议/帮助。
谢谢
发布于 2011-08-08 03:38:14
我建议dstat -cf的更新速率为1秒或更短,这样您就可以获得在1-3秒暂停内查看所需的分辨率。
您正在寻找的是一个单一的CPU是100%的使用率或更多。通常不可能并行化加密以利用多个处理器。这意味着您可以将信息写入磁盘的最大速率是单个处理器可以加密的速率。
如果您看到一个CPU在整个写/下载过程中被固定在一起,并且当写/下载完成时,会有一部分时间处于空闲状态,我会认为这可能是问题所在。
注意:当我说‘一个CPU’时,我指的是‘一次一个CPU',而不是一个特定的CPU。由于某种原因,操作系统通常会将进程(如磁盘加密)从一个CPU移动到另一个CPU。这是正常的,并且应该被忽略,除非这些动作与下载暂停很好地对应。
您可以做的其他测试工作是在未加密的磁盘上找到一个大文件(至少是内存数量的2倍),并查看将其写入未加密磁盘和加密磁盘的速度。还可以观察CPU的性能,就像您每次做的那样。这将为您提供验证,并可能是一个很好的想法,总加密带宽是什么,你可以离开系统。
如果您没有发现CPU是瓶颈,请尝试dstat -af来显示dstat可以测量的大部分内容的统计信息。您正在寻找其他统计数据中类似的模式来查找瓶颈,类似的测试可能会有所帮助。
https://serverfault.com/questions/289558
复制相似问题