64ビットまたは32ビットのLinuxシステム？
4GBのRAMを搭載したサーバーがあります。その上に、32ビットのSlackware Linux12.1がインストールされています。もちろん、4GBのRAMをすべて使用しているわけではありません。すぐにRAMを8GBに増やして、システムで使用する方法を探しています。システムはデータベースサーバーとして使用されており、日中は高負荷になっています。 。
AFAICT、私には2つのオプションがあります。32ビットのままにしてカーネルを再構築すると、パフォーマンスが低下します。または、64ビットを使用してすべてを再インストールします。 Slackwareの64ビットバージョンを見ると、-currentまたはSlamd64を実行できます。
さて、質問に移りましょう。
32ビットのままにするべきですか、それとも64ビットのままにするべきですか？
64ビットを使用する場合、-currentまたはSlamd64を使用する必要がありますか？
追記：Googleで見つけたものをコピーして貼り付けるだけでなく、本番環境でこれらの構成のいずれかを実際に使用している人から回答を得たいと思っています。
最新の32ビットCPUのほとんどはPAEをサポートしているため、4GBを超える物理メモリをアドレス指定できますが、1つのプロセスで一度に確認できるのは4GBのみです。カーネルはこのアドレス空間の一部を使用します。 このStackoverflowの投稿 PAEの仕組みについて説明しています。
多くのオペレーティングシステム（LinuxおよびMS Windowsを含む）は、プロセスの仮想アドレス空間に出入りするMMUおよびページオーバーレイを操作できるAPIを提供します。この機能を使用すると、ディスクバッファ用の追加メモリ。ただし、私が知る限り、これを直接サポートする唯一のDBMSプラットフォームはMS SQLServerです。
メモリを追加すると、データベースの読み取りパフォーマンスが向上しますが（おそらく全体的なスループットが向上します）、書き込みパフォーマンスはI/Oによって制約されます。 DBキャッシュのヒット率が低い場合（たとえば95％未満）、メモリを追加すると全体的なスループットが向上する可能性があります。それ以外の場合は、ディスクサブシステムを確認する必要があります（以下の1を参照）。
より多くのメモリが必要である、またはその恩恵を受けることができると仮定すると、最善のアプローチは64ビットプラットフォームに移行することです。最新のXeonまたはOpteronサーバーでは、モデルに応じて最大32〜144GBをインストールできます。これが最善の選択肢である可能性があります。
- SANはトランザクションアプリケーションに適しています。大量のアプリケーションの場合、DBログにライトスルーキャッシュを設定する必要がありますが、データボリュームのライトバックキャッシュを回避できる場合があります。これにより、ランダムデータの書き込みがコントローラーのバッテリーバックアップキャッシュによって吸収され、コントローラーがディスク書き込みを最適化してスループットを向上させることができるため、ログリーダーのパフォーマンスが向上します。
ただし、この配置には、データボリュームに一貫性がない（破損している）可能性のある障害モードがあります。ログボリュームでライトスルーを使用すると、これが軽減されます（ログはこれらの障害モードに対して脆弱ではないため）。実際には、これは復元/ロールフォワードリカバリモデルに制限されるため、（たとえば）4時間のリカバリウィンドウを許容できる場合にのみ機能します。
32ビットシステムのプロセスあたりのメモリは4GBです（デフォルトでは、プロセス用に3GB、カーネル用に1GBに分割されています）。データベースが/プロセスごとに/より多くのメモリにアクセスできるようにしたい場合は、64ビットオペレーティングシステムをインストールする以外に選択肢はほとんどありません。プロセスあたり3GBの制限が気にならない場合は、現在の設定のままにしておくことをお勧めします。 3GiB/1GiB部門には他にもオプションがありますが、特定の状況では役に立ちません。
プロセスごとのメモリ使用量には、1GiB（正確には896MiB）を少し下回ることのない「ZONENORMAL」と呼ばれる形式でさらに制限があります。 1GiB（ZONE HIGHMEM）を超えるメモリを使用する場合、カーネルはそのメモリをZONE NORMALにマップする必要があり、さらに可能性のあるボトルネックが発生します。 ZONE HIGHMEMは、すべてがZONENORMALである64ビットシステムには存在しません。これは、64ビットを使用する理由にもなります。
「本番環境にある」について-パート：どのデータベースを使用しているかさえわかりません。私のOracleセットアップは、上記の正確な理由により、ほとんどの場合64ビットで実行されます。私はSlackwareを本番環境で実行していませんし、実行している人も知りません。
私の€0.02：64ビットを選択してください。再インストールは、考えられる利点と比較して簡単です。
私はあなたとほぼ同じシナリオにいます（ 小さなデータベースで64ビットのMySQL（およびOS）を使用する理由はありますか？ ）、そして私が見つけたものから：32ビットのMySQLは使用できませんカーネルで何をするかに関係なく、インスタンスあたり2GB以上RAM。
MySQLを実行していない場合は、状況が異なる可能性があります。
「なぜ32ビットカーネルを使い続けるのか」という質問をしたほうがいいと思います。
私はできるだけ早くそれをサポートするすべてのハードウェアですべて64ビットを使用しましたが、後悔はありません。職場では、32GBの64ビットCentOS5でPostgreSQLサーバーを実行していますRAMそしてそれはかなり素晴らしいです（PostgreSQL自体の特定の制限を除いて、32ビットまたは64ビットとは関係ありません。 ）
64ビットが唯一の方法です。 32ビットでは、1 GBを超えるのは独創的なハックであり、4GBを超える場合はさらに大きなハックです。[1] 負荷の高いシステムだとおっしゃっていますが、直接マッピングできるのに、なぜボッジでサイクルを無駄にしてメモリにアクセスするのでしょうか。
32ビットを使用する必要がある唯一の理由は、ベンダーのサポートのためです。 Slackwareを使用しているので、それが理由になるとは思えません。
[1] たとえば、UGS NX Nastran 5.0インストールおよび操作ガイドの "32ビットプラットフォームでのLinuxメモリ割り当て制限" を参照してください。 -）、1GBの障壁について簡単に触れています。
多数のhighmem（8GB以上）を備えた32ビットシステムで実行することの主な危険性は、カーネルがZONE_NORMALに収まるよりも多くのデータを割り当てる必要が生じる可能性があることです。これは、空きメモリがまだたくさんある場合でも、マシンのメモリが効果的に不足する可能性があることを意味します。
もう1つの問題は、システムが、キャッシュされたiノード、バッファヘッド、およびシステムパフォーマンスに役立つその他のキャッシュなどのカーネルデータ構造をより積極的に再利用することです。
3番目の問題は、32ビットシステムでは、3GBを超えるメモリを効果的に使用できるプロセスがないことです。つまり、4 GBを超えるメモリを購入することは、システム上のどのプロセスもすべてのメモリを必要としない場合にのみ役立ちます。
これらの理由から、4GBを超えるメモリを搭載したシステムを購入する場合は、64ビットCPUの入手と64ビットオペレーティングシステムのインストールを検討することをお勧めします。 32ビットシステムと64ビットシステムの価格差は事実上存在しないため、highmemの苦痛をこれ以上経験する必要はありません...
64ビット以上のRAM。innodbを使用している場合は、inndb_buffer_pool_sizeをシステムRAM全体の約70〜75％に設定します。キャッシュサイズを調整します。最近のバージョンのMySQLを使用している場合は、/ tmpディレクトリをtmpfs（メモリ）を使用するように設定します。これにより、MySQLは物理ディスクではなくメモリに一時テーブルを作成できます。次に、MySQLが一時テーブルに/ tmpを使用するように構成されていることを確認します。
ほとんどの人が質問1に答えていますが、質問2に答えさせてください。
64ビットのSlackwareを実行することを選択した場合、実際にはSlackware64という1つの選択肢しかありません。 Slamd64はSlackwareの非公式ポートでしたが、Slackwareに公式64ビットポートが追加されたため、不要になりました。バージョンに関しては、Slackware64の13.0、13.1、13.37、および現在のリリースを選択できます。また、14.0がまもなくリリースされる可能性があるため、それを待つこともできます。
メモリを増やしたい場合は、64ビットカーネルを実行する以外に選択肢はありません。必要に応じて32ビットのユーザーランドを維持できますが、各プロセスは最大2GB（おそらく3GB）に制限されます。すべてを再インストールする必要はなく、新しいカーネルだけを再インストールする必要があります。