求助：FASTt900 的带宽问题。

brian821003

我估计是 flush cache 比例的设置问题。。原来的设置是 最大 80%  最小20%。。我改成了最大 60% 最小 10% 正在四台采集同时工作中，已经将近一小时了。还没有抱错。。在光纤交换机上看是正常了。四个采集端口都是在6.5M左右，两个盘阵端口在13M左右。。

to：basten
单台直接采集已经试过了。。出错的几率明显降低，但还是会出错。

to：wnzl
FAStT 900 的缓存设置我看过了。。cache block 现在设置的是16K，没有更大的选项了。而还有一项，叫cache read ahead multiplier 一直不明白是什么意思。。

Basten

如果单机采集都要出现问题，那和存储应该没什么关系了。

brian821003

1:03:00再次报错。打算卸载sanergy。。直接上载盘阵试试看。。

brian821003

恩。我也是这么想的。如果单台还报错的话可能真的要考虑是不是存储的问题了。。但是客户一直咬住是存储的问题。。我也没办法，只好做到仁至义尽了。。

brian821003

卸载sanergy进行采集测试。。报错。。。。。。。。
更改了segment size 由原来的256改为128，不知道有没有效果。。望大家也帮我出出主意啊。。。谢谢了。。

[ 本帖最后由 brian821003 于 2006-3-22 16:02 编辑 ]

wnzl

关注ing，好像只有采集高码流才会有这样的问题

brian821003

对。。只有采集50Mbps的I祯和15Mbps的IBP码流才会出问题。15M的出错几率很低很低，将近4个月只出过一次。就是50M码流，采集一小时左右必出错。。报错就是缓冲区不足。。头疼死了。。正在查手册。。祈祷吧。。

brian821003

关于cache read ahead multiplier ，我查手册看了下，原文如下：
Read-ahead multiplier
    This parameter affects the reading performance and an incorrect setting can have a large
negative impact. It controls how many additional sequential data blocks will be stored into
cache after a read request.
    Obviously, if the workload is random, this value should be zero. Otherwise each read request
will unnecessarily pre-fetch additional data blocks. Since these data blocks will rarely be
needed, the performance is going to be negatively impacted.

    For sequential workloads, a good value would be between 1 and 4, depending on the particular environment. When using such a setting, a read request causes pre-fetching of several sequential data blocks into the cache; this speeds up subsequent disk access. This leads to a fewer number of I/O transfers (between disk and cache) required to handle the same amount of data, which is good for performance in a sequential environment. A valuethat is too high can cause an overall performance decrease because the cache is filled with read ahead data that is never used.
    Use the performance monitor to watch the cache hit rate for a logical drive to find a proper value.
我大致翻译了一下：
    这个参数影响了读取的性能，不正确的设置会导致很大的负面影响。它控制了在发出读取请求后有多少个additional sequential data blocks要存进缓存。
    显然，如果工作量是随机的，这个值应该为0。对于所有的读请求都不必预读additional data blocks.因为这些数据块很少需要，这些性能都不大必要。
    对于有一定持续工作量的情况，对于特殊的环境1和4是比较好的值。当使用这种设置的时候，读取请求会把一些特殊的数据块读入缓存，能加速并发磁盘通道。这将导致少量的I/O传输（磁盘和缓存之间）需要相同数量的数据。哪些设置对于持续工作环境有利，过高的值会引起性能的降低，因为缓存会被那些从来不用的数据填满。
    使用性能监视察看逻辑驱动器的缓存的命中率，从而找到一个合适的值。

呵呵。。看来和写缓存不足没有什么必然的联系。。

Basten

和存储没有什么关系，你单机采集50Mb码率的流，磁盘阵列性能再差，也不至于不行的。

你的采集卡散热是不是没有做好哦！？

brian821003

我也在想这个问题。。但是情况是四台采集如果一起开始采。。那么报错也必然是一起报错。前后不会相差超过20秒。。如果是温度问题恐怕不会有这么准。。并且从报错的情况看来是说缓冲区不足。这个错误我在网上查了一下。是迈超的卡报的错误。。也就是说是迈超视频卡的缓存不足。但是是由什么原因导致的呢？这样一想的话恐怕最大的问题还是出在盘阵。。

    并且还有重要的一点。就是单机采集到本地硬盘是没有问题的。。这更充分否定了采集卡本身的问题。会不会是兼容性问题？在FAStT 900中有没有类似监视 cache 的使用情况的功能？我想看看到底是不是因为 FAStT900 的缓存导致的这个问题。。