在我的工作场所，我们有一个使用频繁的SAS服务器，但是它的工作量是这样的，获得1分钟的CPU时间通常需要10分钟的实时时间。 这不仅仅是由于I / O或networking瓶颈 – 在办公时间内，CPU负载平均值总是非常高，许多分析人员不得不等待很长时间才能运行查询。
有两个选项我想比较：
scheme1是绝对可行的，但我怀疑这种许可证的成本是非常高的。 另一方面，选项2看起来像涉及一些非常花哨的networking硬件。 是选项2：
我认为SAS应该能够在ScaleMP支持的一个Linux变种上运行 – 现有的SAS服务器使用的是SunOS 5.10，我认为它不被支持，所以我们可能必须将我们的数据库迁移到新的安装萨斯。
另一个要考虑的因素是我们有一个非常实际的代码库，这将需要相当多的修改才能充分利用SAS网格。
我仍然试图找出更多关于现有硬件的信息，但是我预计它会在2005年左右，也就是与SunOS 5.10大致相同的时代。
更新：硬件信息
从/ usr / sbin / psrinfo -v的输出看来，现有的服务器有32个sparcv9内核，其中8个运行在1.5GHz，另外24个运行在1.8GHz。 基于维基百科sparc处理器表的额定速度和操作系统的2005年的date，我认为这些是UltraSPARC_IV处理器，或者相当类似的东西。
从prstat来看，办公室午餐时间的平均负荷大约是32，即大约饱和。 在高峰期工作时间，这通常会升至45左右，但周一早上周末批量工作超时的情况已经达到110。 所以我得出这样的结论：CPU有一些瓶颈，但可能并不像我想的那么糟糕 – 获得服务器CPU时间的延迟很可能是等待磁盘I / O而不是等待线程队列。
根据输出
# /usr/platform/`uname -m`/sbin/prtdiag -v ，似乎服务器有256GB的内存。
*披露：我与ScaleMP *
rnxrx写道，如果你使用的是SunOS，那么硬件可能是全部的，而且他确实是对的。 过去的24个内核可能比现代32位核心服务器（采用英特尔Sandybridge处理器）慢10倍 – 50倍。 但是，那时候的24核心机器是非常昂贵的，你没有注意到你正在使用“大型机级”的系统，所以如果你真的可以提供硬件信息，这将是非常有帮助的。 如果你可以发布命令的结果：'cat / proc / cpuinfo'，这将是一个很好的开始。
如果您正在进行的工作需要大量数据访问，那么ScaleMP可以是一个很好的解决scheme，因为数据在技术上可以全部放入系统的共享RAM中（ScaleMP的软件基本上可以将集群变成一个共享内存的SMP）SAS Analytics（分析）已通过Redhat Linuxauthentication： http ： //www.redhat.com/resourcelibrary/whitepapers/red-hat-and-sas-alliance-brief以及SuSE Linux（而这些Linux发行版又是通过ScaleMP的vSMP Foundationauthentication为OS）
至于“奇特的networking”，事实上 – ScaleMP需要使用InfiniBand（目前在40Gbps或56Gbps，当然“看中”）。 但是，InfiniBand的成本并不比10GE高很多，因为无论如何，您最有可能需要使用10GE（如果要为SAS构build群集）。 ScaleMP的软件为您完成networking的所有pipe理，而且随着机器变成共享内存的SMP，您甚至不需要甚至知道有关InfiniBand操作系统的任何信息。
至于利用多个处理器：这真的取决于您的应用程序。 有些应用程序可以很好地在SMP上进行扩展，有些可以在分布式集群中很好地进行扩展。 有时候，正如你所指出的，可能需要一些工作才能扩大规模（特别是在分布式/集群环境中）。 起初看，当你描述的工作试图获得时间在'一个'CPU – 我想你有许多工作使用相同的数据，ScaleMP将是伟大的。
我很乐意提供进一步的信息，至less在ScaleMP方面。