[OSSLab]LSI CacheCade Pro 2.0 R/W SSDC(SSD Caching)簡測..

對於档案伺服器4K IOPS是最重要的性能指標，單隊列的IOPS降低不少，緩存技術和NCQ處理的不錯，深隊列成績有提升，持續傳輸成績不是很重要

對於各種應用下..
其實也要注意App本身的Caching機制存在...
例如Web Server, 這類東西本身就提供超強的ca ...
per1-q1222 发表于 2011-10-16 20:39

   大部分熱數據集中的領域有很多成熟的韌體緩存技術存在（命中率超級高），磁盤的讀IOPS能力慢慢的在邊緣化，基於板卡的磁盤IO加速正在慢慢的變得不太重要（提供的持續性能有時有些許功用）。在我的工作範圍，我做國內網吧的技術支持工作，作為網吧的檔案伺服器來說（譬如無盤伺服器），基於韌體的緩存技術命中率幾乎達到100%，然後多盤回寫技術提供的寫IOPS又大大優於基於板卡的各種RAID技術（我用的SF主控的SSD作為回寫，因為可壓縮性尚可，可以併發出高IOPS），SO 我目前找不到使用這些產品的任何理由。相對來說讀的處理我認為完全基於可以韌體化，幾乎大部分併發高的應用場合，用戶訪問數據的資源熱集中性都很高，離散分佈的讀不是很多。就是用戶回寫不好預期，幾乎無法緩存，命中極低，寫緩存技術目前還是瓶頸（測評當中的回寫感覺沒有意義），分盤異步讀寫可以大大提高寫IOPS而不是板卡的各種聯合RAID（RAID難於異步寫，如果異步可寫，那麼讀併發又是問題）。我目前釋放讀寫壓力的方式就是韌體緩存讀、基於韌體的分盘異步寫。

说到底还是storage tiers的问题。LSI的SSDC从技术上看目前非常不错，比MAXIQ想的更周到，不过这家公司最近 ...
neeyuese 发表于 2011-10-16 21:05

   这个产品对我做网吧文件服务器来说有何用处？我的应用场合，读数据热集中型，用户回写超级离散型，几乎无法缓存。请浴室姐姐作答下，我看看有没有其他新方案可参考
我目前读在用SUPERCACHE，写使用无盘软件可提供的分盘异步回写，回写性能是异步累加的，相当于所有多盘SSD的IOPS写性能相加，目前比各种板卡或者RAID方案回写性能优

如果你文件服务器需要比较大的容量，再考虑这类方案吧，这个方案针对的是一整个体系，也就是利用上一级的Ti ...
neeyuese 发表于 2011-10-16 21:12

   除了无盘部分，无盘网吧还有上千G的内容服务器，譬如游戏等资源。通过ISCSI技术做虚拟盘映射到用户端来完成内容提供服务，这个容量的读命中让也是我头痛的地方，需要巨大的内存容量（8G甚至16G以上）来缓存才能提供不到80%的命中率，磁盘IO负载依然很高，忙时参考服务器性能监视器对应内容工作盘，压力不是一般的大，长期Idle时间为0。虽然有八二定理才使（80%的用户经常使用几乎20%的数据，80%的数据只有那少数20%的人调用）缓存命中有目前的状况，就是那20%人访问冷门数据让我的磁盘IO遇到瓶颈，其实我可以不管他们，既然是冷门数据，让他们慢好了，但是如果能解决的话还是一个不错的体验，貌似这个产品就是用来提高此类应用的。

这个内容服务器没有回写压力，提供的内容几乎不需要回写服务器
还有，现在的大型网吧可不是小型服务器了，主交换上万兆光纤模块交换机直连服务器，并发数据还是非常大的
不过我现在在有些网吧的内容服务器上使用纯软件的方式使用SSD缓存热数据，SSD容量比内存大，做三级缓存方式，内存不命中那么SSD可以提供一定的下一级的命中率，因为容量大，SSD的命中还是很高的，此SSD不提供任何内容服务，全部容量做热缓存（这样是不是一个意思？）

对于你第一种情况，最好的加速20%冷数据体验，是另外加一台内容服务器，专门负责这部分数据，如果纯粹在原 ...
neeyuese 发表于 2011-10-16 21:47

   你刚才有一点理解错了，八二定理，我这里是80%都是冷数据，因为20%的热数据是80%的人都经常访问，另外20%的人可能访问80%的冷数据。这个80%的冷数据我几乎无法另外做ISCSI服务器，涉及到客户端路径管理问题和游戏自动更新难度（虽然可以跨服务器做），跨服务器更新，主内容服务器更新内容下发的话这样需要同步到另外一台冷数据服务器。又因为我16G内存做读缓存提供的IOPS满足了80%的人，其实热数据缓存需求就是那20%的数据，比如1000G数据就是200G是热的，又因为用户载入时不会调用一个游戏的所有资源，进入同一个游戏载入资源，不同的用户有非常大的一致性，一个魔兽世界的文件夹只有少数几百兆是热数据，虽然他有10几G的材质库。所以16G内存可以达到20%的热数据（比如200G）有80%的全局命中率，我使用的SUPERCACHE是基于扇区的缓存，哪怕文件的一部分被经常使用就会缓存，而不是缓存整个文件，这样提供了缓存效率，并不是200G的热数据需要200G的内存提供100%的热数据命中。所以热数据命中好说。


难点在于冷数据，我的内容服务器不只1000G数据啊，那是上千G的冷门数据，实在无法管理，目前最优方案就是单服务器SSD做磁盘上级纯软件缓存，磨损就磨损，只是个读缓存，坏了不伤数据，立即换一块就是，只要能提供相应的性能，对于大型网吧来说这个成本忽略不计，提供5块SSD随时给他们网管备用，坏了就换就是

我前一贴的原话是：“（80%的用户经常使用几乎20%的数据，80%的数据只有那少数20%的人调用）”

热的20%有80%的人经常调用，20%的人才调用那80%的冷数据

热数据只有20%哦，但满足80%需求。
冷数据另建立服务器还是缓存效率低，因为冷数据大都冷门的原因，所以访问分布可能很广泛，另建服务器也不大可能有缓存高命中，单服务器压力是冷数据（因为冷数据未命中缓存），如果只有热数据访问，那么单服务器磁盘是没有什么压力的，另外建服务器只是转移了压力，并没有减少任何IO压力，我的IO压力就是冷数据访问，单服务器和双服务器区别似乎不大。



最关键的！冷数据可能是访问某个热数据的资源的一部分，无法分拆。比如这个版本下的魔兽世界，大家进游戏初始化载入的几乎是同一个资源需求，有趋向性，可以缓存。目前版本玩家经常进入的副本是趋同性的，很可能被缓存命中，但魔兽世界广大的无缝地图和冷门副本等资源不可能被缓存算法包含，那么你不会希望我把魔兽世界文件夹分拆到其他服务器，因为存在访问问题，而且热数据在工作中是动态统计的，下个游戏版本可能又有新的游戏热点地区，基于文件访问结构的约束，就算是“热门”资源，我无法把这个资源同一部分的冷门资源分拆，客户机的访问逻辑是个问题

热数据其实大部分都只是一个资源的少部分，我这里冷热数据的最小单位是扇区级别，不是以文件或资源文件夹来分割的
热数据也许只是一个游戏材质资源文件的一小部分，比如魔兽世界单个文件N个G的MPQ资源文件