我试图评估一些SSD的video点播用例。 我们已经对它们进行了一些基准testing,但是我们希望能够比典型的基准testing工具更具有真实负载testing的videostream数量。
到目前为止,我已经这样做了:
--vout dummy --aout dummy --codec dummy
以便它连续请求文件,但不做任何解码,以保存在CPU上) 我也有一个机顶盒,解码从同一个SSD。 这个想法是要看我们能否在视觉上注意到SSD性能开始崩溃的时候。
我得到了不错的结果,但主要的问题是,负载服务器达到了可以抓取的数据stream数量的极限(在700-800范围内,有10-12GB的RAM)。 看起来这是由于大量的交换一次发生,推高了iowait
天空,使服务器几乎没有反应。
简而言之,我的问题是:
/proc/sys/vm/swappiness
玩了一下,但似乎没有什么区别) 谢谢,
蒂姆
我使用video点播系统,实际上编写一些准确描述真实播放特性的代码是无可替代的。 我们写了一个叫做“VODBasher”的版本,它使用了真正的平台上我们真正使用的确切的传输机制,并且从遍布各处的真实位置运行它。 这有助于我们了解我们将会在哪里看到问题,以及我们不会在哪里。 其他任何事情都是开玩笑的猜测。
在你的“负载服务器”(在这种情况下充当客户端)上运行700-800份VLC时,实际上你会用尽内存似乎是相当合理的。 每个实例只有12-17MB的内存,并且有10-12GB。 (所以难怪调整swappiness不会让你很远)。
是否有什么特别的理由真正加载电影与vlc(甚至与虚拟输出),而不是只是转储到/dev/null
?