求助：FASTt900 的带宽问题。

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传输（磁盘和缓存之间）需要相同数量的数据。哪些设置对于持续工作环境有利，过高的值会引起性能的降低，因为缓存会被那些从来不用的数据填满。
    使用性能监视察看逻辑驱动器的缓存的命中率，从而找到一个合适的值。

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

brian821003

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

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

brian821003

to：Basten
       采集时写盘阵和文件拷贝时写盘阵是不同的。前者要求有很好的缓存性能，一旦发生缓存被写满导致无法写入盘阵的情况，采集会立刻断掉，导致采集失败。而拷贝文件写入在缓存写满的时候可以稍做等待，等清空缓存后继续写入。现在在4台上载机器中用SANergy测试，写速度在80MB/s以上。按道理说，带宽足够了。。表面上看来不是盘阵的问题，但是可能会是盘阵在缓存管理上的问题。

brian821003

谢谢大家。。。前天我看了看手册，上面说segment的值小一些的话有助于提升媒体流的写入性能，所以我就把卷的segment值由原来的256调整到了128，昨天下午进行了2台同时采集50Mbps的码流，共进行了100分钟，没有出现报错情况，今天上午进行了4台50Mbps的采集，第13分钟的时候只有一台报错，后来重启。四台采集在下午1点的时候再次报错。。采集一共采了将近4个小时。。   

   控制器的电池是好的。。我昨天看了。。缓存也已经启用。现在苦于我的笔记本没有双网卡。。不能监控磁盘的使用状态。。明天去买一块网卡加上。。在SM里面我记得是可以监控缓存的使用情况的。。

    很不明白。为什么会突然卡死呢？如果说是采集卡的问题，那么单机采集并没有问题。那么采集卡的抱错说是缓冲区不足，一定是卡上的缓存不足，那么卡上的缓存不足是什么导致的呢？光纤通路？盘阵缓存？但是如果说不是盘阵的问题，那么四台采集怎么会同时报错呢？监控盘阵缓存的使用情况看来是最根本的解决方法了。。

brian821003

呵呵。。现在情况有所改善。看来和segment的大小有关，原来在256K的时候最多能采集90分钟，现在改成了128K，最长采集了4个多小时。但是还有报错的情况发生，下一步打算进一步调整为64k，看是不是能彻底避免这种情况的发生。但是原因还是不很清楚，查了手册中关于segment size 的解释，原文如下：

    The choice of a segment size can have a major influence on performance in both IOPS and throughput. Large segment sizes increase the request rate (IOPS) by allowing multiple disk drives to respond to multiple requests. A small segment size increases the data transfer rate (MB/s) by allowing multiple disk drives to participate in one I/O request. Use a small segment size relative to the I/O size to increase sequential performance.
   
      You can use the performance monitor (see “Performance monitor data” on page 85) to evaluate how a given segment size affects the workload. Use the following guidelines:

1、If the typical I/O size is larger than the segment size, increase the segment size in order to minimize the number of drives needed to satisfy an I/O request. This is especially true in a multi-user, database, or file system storage environment. Using a single drive for a single request leaves other drives available to simultaneously service other requests.

2、 If we are using the logical drive in a single-user, large I/O environment (such as for multimedia application storage), performance is optimized when a single I/O request can be serviced with a single data stripe (the segment size multiplied by the number of drives in the array that are used for I/O). In this case, multiple disks are used for the same request, but each disk is only accessed once.

3、 Normally, a small segment size is used for databases, normal sizes for a file server, and large segment sizes for multimedia applications.

4、 If we increase the segment size we gain more throughput

       同样大致翻译一下：

    段大小的选择可以对 IOPS 和吞吐量产生重大的影响。段大小值大可以增加多磁盘请求响应的速率，小的段大小值则能够增加多磁盘参与的输入输出请求中数据的传输速率（以MB/s为单位）。使用相对于输入输出值较小的段大小值能够增加时序性能。

您可以使用性能监控来估计对于当前的工作量需要多少段大小。有以下指导方针：

1、如果通常的输入输出大小要比当前的段大小大，为了平衡对于驱动器的输入输出请求可以增加段大小值。这适用于多用户，数据库或者文件服务器的存储环境。

2、如果我们只有单独的用户使用逻辑驱动器，较大量的输入输出环境，当单独的I/O请求能够被单独的数据通路所接受那么性能将是最好的。既然这样，多个磁盘用来做同样的请求，但是所有的磁盘之能够访问一次。

3、正常的，较小的段大小值适用于数据库。中等的段大小值适用于文件服务器，较大的段大小值针对多媒体应用。

4、如果我们增加段大小，我们将获得更多的吞吐量。


总结一下，较小的 segment size 能够增加时序性能，也就是说能够承受更大的连续数据量。但是对于多媒体应用，又推荐较大的 segment size 。较大的 segment size 可以增加盘阵读取和写入的速度。看来为了能够正常写入，只好牺牲一些速度了。。但是从我测试的情况看来，当 segment size 由256K改为128K之后，盘阵的速度并没有太大的降低，也就有10MB/s的降低，这个程度还是可以忍受的。所以决定继续降低到64k待测。。。

brian821003

现在有个疑问，如果继续减小 segment 的值，会不会对磁盘的读写有很大的影响。

brian821003

继续测试中。。现在已经连续采集300分钟没有问题了。。由于磁带长度不够，后面的150分钟一直都是在采集黑场。但是仍然是50Mbps的码流文件。。。期待。。。看看是不是还会有问题。。

brian821003

经过这近一周的测试。问题并没有太大的改善。但是我发现了一个细节，就是使用SANergy测试的时候，一是速度波动很大，最高的时候能到120左右，而最低的时候能到90多。二是在用SANergy测试的时候发现进度条有时会出现“卡”的情况。每次一“卡”，测出的速度就必然会低。我想是因为在清空缓存的时候造成的。不知道对不对。还有就是速度又20M左右的波动，是属于正常范围么？再有这么“卡”，也是正常的么？