在我的工作场所，我们有一台使用率很高的 SAS 服务器，但它的工作负载非常大，以至于获取 1 分钟的 CPU 时间通常需要 10 分钟的实际时间。这不仅仅是由于 I/O 或网络瓶颈 - CPU 负载平均值在办公时间总是很高，许多分析师必须等待很长时间才能运行查询。
我想比较两个选项：
选项 1 肯定是可行的，但我怀疑许可费用会非常昂贵。另一方面，选项 2 看起来涉及一些非常花哨的网络硬件。选项 2 是：
- 完全可行吗？
- 可能更物有所值吗？
我认为 SAS 应该能够在 ScaleMP 支持的 Linux 变体之一上运行 - 现有的 SAS 服务器使用 SunOS 5.10，我认为它不受支持，因此大概我们必须将我们的数据库移至新安装的 sas 上。
要考虑的另一个因素是我们拥有非常庞大的代码库，需要进行大量返工才能充分利用 SAS 网格。
我仍在尝试了解更多有关现有硬件的信息，但我预计它可以追溯到 2005 年左右，即大致与 SunOS 5.10 同一时代。
更新：硬件信息
从 /usr/sbin/psrinfo -v 的输出来看，现有服务器有 32 个 sparcv9 核心，其中 8 个以 1.5GHz 运行，另外 24 个以 1.8GHz 运行。根据维基百科的额定速度sparc 处理器表操作系统的日期是 2005 年，我推测这些是超SPARC_IV处理器，或者类似的东西。
从 prstat 来看，办公室午餐时间的平均负载约为 32，即几乎饱和。在高峰工作时间，这个数字通常会上升到 45 左右，但据了解，在周末批量作业超负荷的周一早上，这个数字会达到 110。因此，我得出结论，存在一点 CPU 瓶颈，但情况可能没有我想象的那么糟糕 - 获取服务器 CPU 时间的大部分延迟可能是由于等待磁盘 I/O，而不是在线程队列中等待。
根据输出
# /usr/platform/`uname -m`/sbin/prtdiag -v
，看来服务器有256GB的内存。
答案1
* 披露：我来自 ScaleMP *
rnxrx 写道，如果您使用的是 SunOS，那么硬件可能就很重要了，他确实是对的。以前的 24 核服务器可能比现代的 32 核服务器（使用 Intel Sandybridge 处理器）慢 10 到 50 倍。但是，当时的 24 核机器非常昂贵，而且您没有注意到您使用的是“大型机级”系统，因此如果您能提供硬件信息，那将非常有帮助。如果您可以发布命令“cat /proc/cpuinfo”的结果，那将是一个很好的开始。
如果您正在做的工作需要大量的数据访问，ScaleMP 可以是一个很好的解决方案，因为数据在技术上可以全部放入系统的共享 RAM 中（ScaleMP 的软件基本上会将集群变成共享内存 SMP）SAS Analytics 已通过 Redhat Linux 认证：http://www.redhat.com/resourcelibrary/whitepapers/red-hat-and-sas-alliance-brief以及 SuSE Linux（这些 Linux 发行版又被 ScaleMP 认证为基于 vSMP Foundation 的操作系统）
至于“花哨的网络”，的确如此 - ScaleMP 需要使用 InfiniBand（目前为 40Gbps 或 56Gbps，当然“花哨”）。但是，InfiniBand 的成本并不比 10GE 高很多，而 10GE 无论如何您都很可能需要使用（如果为 SAS 构建集群）。ScaleMP 的软件会为您完成所有网络管理，并且由于机器变成了共享内存 SMP，您实际上甚至不需要了解任何有关 InfiniBand 的知识即可操作系统。
至于如何利用多个处理器：这实际上取决于您的应用程序。有些应用程序可以在 SMP 上很好地扩展，有些可以在分布式集群中很好地扩展。有时，正如您所指出的，可能需要做一些工作才能扩展某些东西（尤其是在分布式/集群环境中）。乍一看，正如您描述的试图在“一个”CPU 上获取时间的作业一样 - 我猜您有许多使用相同数据的作业，ScaleMP 非常适合。
我很乐意提供更多信息，至少在 ScaleMP 方面。