你正确地使用自己的多个SSD了吗？（只有一个SSD的可忽略）
本帖最后由 Eviluess 于 18-7-22 11:54 编辑
随着音色越来越多，大家应该也不止拥有一块SSD了吧。
相信很多人是这样使用的：
把最常用的音色都放到最大，最新，测试速度最快的那个SSD。
用得少一点的乐器，放到稍微慢一点、旧一点、小一点的那些SSD去。
其实，这样，当你制作一个歌曲，80%都在使用最常用的音色时，其实只有一块SSD在疯狂被读取。
另外几块在睡觉……
在音乐对读取的数据量相同的情况下，这显然是一种浪费。
所以，私认为正确的做法是：
把常用的音色，分摊在各个SSD上。
比如Bass和鼓绝对不放在一个盘，因为一般有鼓的歌都会有Bass。
同理，当盘越多，在编曲时分摊的就越容易达到硬件平衡。
也更容易减少加载时间，减少卡顿。
先拿加载来说（其实演奏中途和工程渲染道理都一样的）：
如果一个工程稳定加载后需要占用12GB内存（不算软件自己的拿几百M）是来自音色库的采样。
那么对于一个400M/S的SSD来说，这个曲子所有的音色来自于一个这个SSD，那么最快也要30秒才能贡献完12GB给内存。
当第二个旧一点的SSD存有该歌曲一半音色的情况， 假设旧的SSD是300M/S的读取速度。
那么作为瓶颈的旧SSD，要贡献6GB的数据则需要20秒。
在这20秒内，新的SSD早就把他需要贡献的6G数据贡献完毕了（只要15秒）。
那么整个工程的加载速度就从30秒变成20秒了——在相同的硬件投资的前提下
随着音色越来越多，大家应该也不止拥有一块SSD了吧。
相信很多人是这样使用的：
把最常用的音色都放到最大，最新，测试速度最快的那个SSD。
用得少一点的乐器，放到稍微慢一点、旧一点、小一点的那些SSD去。
其实，这样，当你制作一个歌曲，80%都在使用最常用的音色时，其实只有一块SSD在疯狂被读取。
另外几块在睡觉……
在音乐对读取的数据量相同的情况下，这显然是一种浪费。
所以，私认为正确的做法是：
把常用的音色，分摊在各个SSD上。
比如Bass和鼓绝对不放在一个盘，因为一般有鼓的歌都会有Bass。
同理，当盘越多，在编曲时分摊的就越容易达到硬件平衡。
也更容易减少加载时间，减少卡顿。
先拿加载来说（其实演奏中途和工程渲染道理都一样的）：
如果一个工程稳定加载后需要占用12GB内存（不算软件自己的拿几百M）是来自音色库的采样。
那么对于一个400M/S的SSD来说，这个曲子所有的音色来自于一个这个SSD，那么最快也要30秒才能贡献完12GB给内存。
当第二个旧一点的SSD存有该歌曲一半音色的情况， 假设旧的SSD是300M/S的读取速度。
那么作为瓶颈的旧SSD，要贡献6GB的数据则需要20秒。
在这20秒内，新的SSD早就把他需要贡献的6G数据贡献完毕了（只要15秒）。
那么整个工程的加载速度就从30秒变成20秒了——在相同的硬件投资的前提下
其实核心思想就是把采样文件尽可能的分散到多块硬盘上，这样得到的结果是——在读取单个文件的时候速度不变，但如果需要一次读取大量的小文件（考验磁盘4K性能的时候），因为多个磁盘分头寻找和读取多个文件，于是4K性能就可以倍增。
现在的raid0方式似乎都是把一个文件的数据分割存放到多块硬盘上的，这样可以提升大文件的连续读写效率，但对4K性能的提升并无帮助（在某些设置下还会降低4K性能）。而更高级的raid5其实也是大同小异，区别只是增加了校验机制防止数据丢失。
其实我也很好奇，有没有一种新的raid方式，是可以把大堆的小文件自动的、整体分散到多个硬盘上的？比如我在一套3硬盘的阵列中存入3个文件，那么，让文件1写进1号盘，文件2写进2号盘，文件3写入3号盘，假定3个文件大小一样，这样在需要读取这三个文件的时候，三个硬盘各读一个，那么就总共只需要原来读一个文件的时间即可读取到3个文件了~~~只是不知道为啥我就没听说过这种raid模式~~~
这年头，固态硬盘的连续读取速度其实已经足够快，人们加载大工程、大游戏的时候，其实最主要的痛苦是来自于硬盘的4K性能限制了大量小文件的读取速度~~~
现在的raid0方式似乎都是把一个文件的数据分割存放到多块硬盘上的，这样可以提升大文件的连续读写效率，但对4K性能的提升并无帮助（在某些设置下还会降低4K性能）。而更高级的raid5其实也是大同小异，区别只是增加了校验机制防止数据丢失。
其实我也很好奇，有没有一种新的raid方式，是可以把大堆的小文件自动的、整体分散到多个硬盘上的？比如我在一套3硬盘的阵列中存入3个文件，那么，让文件1写进1号盘，文件2写进2号盘，文件3写入3号盘，假定3个文件大小一样，这样在需要读取这三个文件的时候，三个硬盘各读一个，那么就总共只需要原来读一个文件的时间即可读取到3个文件了~~~只是不知道为啥我就没听说过这种raid模式~~~
这年头，固态硬盘的连续读取速度其实已经足够快，人们加载大工程、大游戏的时候，其实最主要的痛苦是来自于硬盘的4K性能限制了大量小文件的读取速度~~~
好像是这样的，工程越大，覆盖音色库越多，收益越大。
然而实际上，个人体验，在加载工程读取音色的整个过程当中（25G-30G以上规模），往往快则几百M/S，少则几十M/S，有较多的时间，是达不到硬盘的极限的。最常出现的速度大致是在100M上下左右/S。而这个速度，其实还消耗不掉一块SSD盘的。
另外就是工程读取，在打开工程时的预缓冲，从显示条看是有先后顺序的，并没看出来有同时并发读取多个音色库的状态，总是一个音色完成再读下一个音色，而打开完成随后的详细读取，则是由用户播放指针控制，或在用户不干预时，由软件全自动读取各个音色库（这时候到底软件是有没有读取的先后顺序我不知道了），但结果显示基本上就是几百M到几十M每秒的速度区间。
凭心而论，PCI-E我有2块，也都放了一些常用音色，但是没感觉有立竿见影的提升（相比SATA的SSD）。SATA的SSD与HDD相比，有明显提升，但是中小规模工程（如10G、20G以下规模吧）个人感觉这个打开工程缓冲时间其实还能稍等，如果较大规模工程是当然要SSD，最大的差异不在打开时间，而是在打开完成后的后台随机详细读取时间，这个过程中，如果物理内存不足，则会放大4K响应差异，导致出现音色数据跟不上用户随机处理，甚至严重会产生信号中断不稳定因素。
诚然，如果耐心足够好，内存足够大，那么等工程全体都缓冲至内存，以上的都不重要了。
然而实际上，个人体验，在加载工程读取音色的整个过程当中（25G-30G以上规模），往往快则几百M/S，少则几十M/S，有较多的时间，是达不到硬盘的极限的。最常出现的速度大致是在100M上下左右/S。而这个速度，其实还消耗不掉一块SSD盘的。
另外就是工程读取，在打开工程时的预缓冲，从显示条看是有先后顺序的，并没看出来有同时并发读取多个音色库的状态，总是一个音色完成再读下一个音色，而打开完成随后的详细读取，则是由用户播放指针控制，或在用户不干预时，由软件全自动读取各个音色库（这时候到底软件是有没有读取的先后顺序我不知道了），但结果显示基本上就是几百M到几十M每秒的速度区间。
凭心而论，PCI-E我有2块，也都放了一些常用音色，但是没感觉有立竿见影的提升（相比SATA的SSD）。SATA的SSD与HDD相比，有明显提升，但是中小规模工程（如10G、20G以下规模吧）个人感觉这个打开工程缓冲时间其实还能稍等，如果较大规模工程是当然要SSD，最大的差异不在打开时间，而是在打开完成后的后台随机详细读取时间，这个过程中，如果物理内存不足，则会放大4K响应差异，导致出现音色数据跟不上用户随机处理，甚至严重会产生信号中断不稳定因素。
诚然，如果耐心足够好，内存足够大，那么等工程全体都缓冲至内存，以上的都不重要了。
南宫浩 发表于 18-7-22 13:04
其实核心思想就是把采样文件尽可能的分散到多块硬盘上，这样得到的结果是——在读取单个文件的时候速度不变 ...
可以创业了~~
其实思想都是一样的
不要全瓶颈在一个物理设备上
llewellyn 发表于 18-7-22 13:14
好像是这样的，工程越大，覆盖音色库越多，收益越大。
然而实际上，个人体验，在加载工程读取音色的整个过 ...
因为Kontakt推出ncw后，文件更分散。
当在播放的时候，DFD会时时刻刻从硬盘拉取采样。
这个时候，如果全押在一个SSD上，读取总有先后的，最晚读的那个明显是可能造成丢音或断音的乐器。
而如果分布在不同的SSD，那么等于在同一时刻，各分担一部分数据，以便减少单位时间中对单个SSD的读取压力