我有一台具有 4GB 内存的服务器。在它上面，我安装了 32 位 Slackware Linux 12.1。当然，它并没有使用全部 4GB 的 RAM。我很快想将 RAM 增加到 8GB，并且正在寻找一种方法让系统使用它。该系统用作数据库服务器，白天处于高负载状态。
AFAICT，我有两个选择：保留 32 位并重建内核并失去一些性能。或者使用 64 位并重新安装所有内容。查看 64 位版本的 Slackware，我可以运行 -current 或 Slamd64。
现在，关于问题：
我应该继续使用 32 位还是使用 64 位？
如果我使用 64 位，我应该使用 -current 还是 Slamd64？
PS我希望从实际在生产中使用任何这些配置的人那里得到答案，而不仅仅是复制/粘贴我可以通过谷歌找到的东西。
32 位系统上的每个进程内存为 4GB（默认情况下分为 3GB 用于进程和 1GB 用于内核）。如果您希望您的数据库能够访问更多内存/每个进程/您别无选择，只能安装 64 位操作系统。如果每个进程 3GB 的限制不打扰您，您不妨继续使用当前设置。顺便说一句，3GiB/1GiB 部门还有其他选择，但它们不会在您的特定情况下为您提供帮助。
每个进程内存使用的进一步限制以所谓的“ZONE NORMAL”的形式存在，它永远不会超过略低于 1GiB（准确地说是 896MiB）。当使用超过 1GiB (ZONE HIGHMEM) 的内存时，内核必须将该内存映射到 ZONE NORMAL，从而产生更多可能的瓶颈。ZONE HIGHMEM 在 64 位系统上不存在，在该系统上一切都是 ZONE NORMAL。这也是使用 64 位的一个很好的理由。
至于“在生产中”部分：我什至不知道您使用的是什么数据库。出于我上面所说的确切原因，我的 Oracle 设置几乎总是运行 64 位。不过，我没有在生产中运行 Slackware，也不知道有谁这样做过。
我的 0.02 欧元：选择 64 位。与可能的好处相比，重新安装是微不足道的。
大多数现代 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，具体取决于型号。这可能是您的最佳选择。
但是，这种安排具有可能导致数据量不一致（损坏）的故障模式。在日志卷上使用直写可以缓解这种情况（因为日志不易受到这些故障模式的影响）。实际上，这将您限制为还原/前滚恢复模式，因此只有在您可以容忍（例如）4 小时的恢复窗口时它才会起作用。
我几乎和你处于相同的情况（有什么理由在小型数据库上使用 64 位 MySQL（和操作系统）吗？），并且据我所知：32 位上的 MySQL 每个实例不能使用超过 2GB 的 RAM 否不管你用你的内核做什么。
如果您没有运行 MySQL，情况可能会有所不同。
我认为最好问一个问题，“我为什么要使用 32 位内核？”
我尽快在每一个支持它的硬件上都使用了 64 位，我并不后悔。在工作中，我们在具有 32 GB RAM 的 64 位 CentOS 5 上运行 PostgreSQL 服务器，它非常棒（除了 PostgreSQL 本身的某些限制，但与 32 位或 64 位无关。）
在具有大量内存（超过 8GB）的 32 位系统上运行的主要危险是内核最终可能需要分配比 ZONE_NORMAL 更多的数据。这意味着机器可以有效地耗尽内存，即使仍然有很多高内存可用。
另一个问题是系统将更积极地回收内核数据结构，如缓存的 inode、缓冲区头和其他有助于提高系统性能的缓存。
第三个问题是，在 32 位系统上，没有进程能够有效使用超过 3GB 的内存。这意味着购买超过 4GB 的内存只有在系统上没有进程需要所有内存的情况下才有用。
由于这些原因，建议如果您购买内存超过 4GB 的系统，则应考虑购买 64 位 CPU 并安装 64 位操作系统。32位系统和64位系统之间的价格差异实际上是不存在的，因此没有真正需要再体验highmem的痛苦......
更多信息...
64位是唯一的方法。在 32 位上，达到 > 1GB 是一种创造性的破解，而对于 > 4GB 则是更大的破解。[1]你说这是一个负载很重的系统，那么当它可以直接映射时，为什么要浪费循环来获取内存呢？
您应该使用 32 位的唯一原因是为了获得供应商支持。当您使用 Slackware 时，我怀疑这是一个原因。
[1]例如，参见UGS NX Nastran 5.0 Installation and Operations Guide中的“Linux Memory Allocation Limit on 32-bit Platform”，其中简要提到了 1GB 障碍。
64 位 + 更多内存，如果您使用的是 innodb，则将 inndb_buffer_pool_size 设置为系统总内存的 70-75%。调整缓存大小。如果您使用最新版本的 MySQL，请将 /tmp 目录设置为使用 tmpfs（内存），这将允许 MySQL 在内存中而不是在物理磁盘上创建临时表。确保 MySQL 被配置为使用 /tmp 作为临时表。
如果你想增加你的内存，你别无选择，只能运行 64 位内核。如果需要，您可以保留 32 位用户空间，但每个进程将被限制为最大 2GB（可能是 3GB）。您不需要重新安装所有内容，只需重新安装一个新内核。
大多数人都在回答问题#1，但让我回答问题#2。
如果您选择运行 64 位 Slackware，那么您实际上只有一个选择：Slackware64。Slamd64 是 Slackware 的非官方端口，现在 Slackware 拥有官方的 64 位端口，因此不再需要它。在版本方面，您可以选择 Slackware64 的 13.0、13.1、13.37 和 -current 版本。另请注意，14.0 可能很快就会发布，因此您也可以等待。