我有一台拥有 4GB RAM 的服务器。我在其上安装了 32 位 Slackware Linux 12.1。当然，它并没有使用全部 4GB RAM。我很快想将 RAM 增加到 8GB，并且正在寻找系统使用它的方法。该系统用作数据库服务器，白天负载很高。
据我所知，我有两个选择：继续使用 32 位并重建内核，这会损失一些性能。或者使用 64 位并重新安装所有内容。查看 64 位版本的 Slackware，我可以运行 -current 或 Slamd64。
现在，让我们来回答以下问题：
我应该继续使用 32 位还是使用 64 位？
如果我使用 64 位，我应该使用 -current 还是 Slamd64？
PS 我希望能从实际在生产中使用这些配置的人那里得到答案，而不仅仅是复制/粘贴我可以通过 Google 找到的东西。
答案1
大多数现代 32 位 CPU 都支持 PAE，这允许它们寻址超过 4GB 的物理内存，尽管单个进程一次只能看到 4GB。内核将占用部分地址空间。 此 Stackoverflow 帖子讨论 PAE 的工作原理。
许多操作系统（包括 Linux 和 MS Windows）都提供 API，允许您在进程的虚拟地址空间内外操纵 MMU 和页面覆盖。此功能允许您将额外内存用于磁盘缓冲区。但是，据我所知，唯一直接支持此功能的 DBMS 平台是 MS SQL Server。
增加内存将提高数据库读取性能（这可能会提高整体吞吐量），但写入性能将受到 I/O 的限制。如果您的数据库缓存命中率较低（例如低于 95%），则增加内存可能会提高整体吞吐量。否则，您可能需要查看磁盘子系统（参见下面的 1）。
假设您需要或可以从更多内存中受益，最好的方法是迁移到 64 位平台。现代 Xeon 或 Opteron 服务器将允许您安装高达 32-144GB 的内存（具体取决于型号）。这可能是您的最佳选择。
- SAN 非常适合事务应用程序。对于高容量应用程序，您应该在 DB 日志上使用写通缓存，但您可能能够使用数据卷上的写回缓存。这将为您带来良好的日志读取器性能，因为控制器的电池备份缓存可以吸收随机数据写入，并且控制器可以优化磁盘写入以提高吞吐量。
但是，这种安排存在故障模式，可能导致数据卷不一致（损坏）。在日志卷上使用写通可以缓解这种情况（因为日志不易受到这些故障模式的影响）。实际上，这会将您限制在恢复/前滚恢复模型中，因此只有当您能够容忍（例如）4 小时的恢复窗口时它才会起作用。
答案2
32 位系统上每个进程的内存为 4GB（默认情况下，分为 3GB 用于进程和 1GB 用于内核）。如果您希望数据库能够访问更多内存/每个进程/，您别无选择，只能安装 64 位操作系统。如果每个进程 3GB 的限制不困扰您，您不妨继续使用当前设置。顺便说一句，3GiB/1GiB 划分还有其他选项，但它们不会在您的特定情况下帮助您。
每个进程的内存使用量还有进一步的限制，即所谓的“ZONE NORMAL”，它永远不会超过 1GiB 以下（准确地说是 896MiB）。当使用超过 1GiB 的内存（ZONE HIGHMEM）时，内核必须将该内存映射到 ZONE NORMAL，从而产生进一步的潜在瓶颈。ZONE HIGHMEM 在 64 位系统上不存在，因为在 64 位系统中，所有内容都是 ZONE NORMAL。这也是选择 64 位的一个好理由。
至于“在生产中使用”部分：我甚至不知道您使用的是哪种数据库。我的 Oracle 设置几乎总是运行 64 位，原因如上所述。但我不会在生产中使用 Slackware，也不认识任何使用的人。
我的建议是：选择 64 位。与可能的好处相比，重新安装是小菜一碟。
答案3
我的情况和你差不多（有什么理由在小型数据库上使用 64 位 MySQL（和操作系统）吗？)，据我所知：无论您对内核做什么，32 位 MySQL 每个实例都不能使用超过 2GB 的 RAM。
如果您没有运行 MySQL，情况可能会有所不同。
答案4
在具有大量高端内存（超过 8GB）的 32 位系统上运行的主要危险是，内核最终可能需要分配比 ZONE_NORMAL 中容纳的更多的数据。这意味着机器可能会耗尽内存，即使仍有大量高端内存可用。
另一个问题是，系统将更积极地回收内核数据结构，如缓存的 inode、缓冲区头和其他可以帮助提高系统性能的缓存。
第三个问题是，在 32 位系统上，没有进程能够有效使用超过 3GB 的内存。这意味着，只有当系统上没有任何进程需要所有内存时，购买超过 4GB 的内存才有用。
出于这些原因，建议如果你购买了内存超过 4GB 的系统，你应该考虑购买 64 位 CPU 并安装 64 位操作系统。32 位和 64 位系统之间的价格差异实际上不存在，因此不再需要经历高内存的痛苦……