我试着为视频点播用例评估一些SSD。我们已经对它们进行了一些基准测试,但是我们希望通过比典型的基准测试工具更真实的负载测试来了解它们可以支持的视频流的数量。
到目前为止,我已经这样做了:
--vout dummy --aout dummy --codec dummy运行,以便它连续请求文件,但不对其进行任何解码以保存在CPU上)我也有一个机顶盒,可以从同样的SSD解码。这样做的目的是看看我们是否能在视觉上注意到SSD的性能何时开始崩溃。
我得到了不错的结果,但主要的问题是,负载服务器达到了一个限制(在700-800范围内,10-12 of的RAM),他们可以抓取的流数。看起来,这是由于大量的交换同时发生,推高了iowait天空,使服务器几乎没有反应。
简单地说,我的问题是:
/proc/sys/vm/swappiness玩了一会儿,但似乎没什么区别)谢谢,
时间
发布于 2010-11-18 20:04:56
我做的视频点播系统,没有任何替代的实际写一些代码,准确地描绘真实的回放特性。我们写了一个我们称之为“VODBasher”,它使用了我们在真实平台上真正使用的确切的传输机制,并且我们运行它的真实位置遍布各地。这帮助我们理解了我们会在哪里看到问题,而我们不会看到的地方。
发布于 2010-11-18 20:00:01
实际上,在运行700-800份VLC的情况下,您在“加载服务器”(在此场景中充当客户端)上耗尽了ram,这似乎是相当合理的。这只是每个实例使用的12-17 10内存,还有你的10-12 10内存。(因此,毫不奇怪的是,随意调整不会让你走得太远)。
是否有什么特别的理由真正用vlc加载电影(即使使用虚拟输出),而不是仅仅将其转储到/dev/null中?
https://serverfault.com/questions/203601
复制相似问题