MySQLからtmpfs
MySQLを使用してディスク上ではなくメモリにデータを保存した経験を共有したいと思います。 これにより、サーバーの負荷平均を減らすことができました。サーバーはディスク操作により急速に成長し始めました。
1つのプロジェクトでは、Debian LennyのMyISAMエンジンでMySQLを使用しています。 一般データはC ++のデーモンのRAMにロードされ、ユーザーデータはログイン時に1回ロードされ、ユーザーの作業中に定期的に保存されます。 ログアウト（またはタイムアウト）とともに保存されます。 説明したスキームを考慮すると、選択は更新よりもはるかに小さくなります（選択：24％、削除：4％、更新：61％、挿入：11％）。
原則として、この問題は管理者の問題ではありませんが、ツールの選択があまり良くないことが原因です。 MyISAMのようなテーブルレベルのロック（書き込み時にテーブル全体をロックする）ではなく、行レベルのロック（レコードベースのロック）を使用するInnoDBが適しています。 ディスクに書き込まれるデータの量は減りそうにないが。 一方、私たちは本当にSQLを必要とせず、プロジェクトをNoSQLに移植する傾向があります（私たちは長い間代表者の一部を探していました（assandra）。 しかし、データウェアハウスを別のエンジン/データベースに転送する時間がなかったため、管理者を使用することにしました。 リソース。
ユーザー数の増加と新しいコンテンツの導入に伴い、データベースサーバーの負荷平均が増加するという問題に直面しました（8コアサーバーで2〜3laが1秒あたり400リクエストのみで観察されました）。 さらに、プロセッサと同様に、メモリの負荷が低くなりました。 問題は、大量のデータがディスクに書き込まれることでした（iowaitの増加）。 ある時点で、システムが途切れ始め、いくつかの基本的なクエリに2秒以上かかりました。 通常モードでは、そのようなリクエストはミリ秒単位で実行されます。
MySQL構成を少し最適化しました（mysqltunerなどの自動スクリプトと手動チューニングの両方を使用）が、これにより負荷がわずかに減少しました（10〜15％）。 私たちの主な負担は読み取りではなくデータの更新であるため、ほとんどの場合、データのキャッシュを担当するパラメーターは適切ではありません。 ベースはSASディスク上にありますが、速度はまだ十分ではありません。 バイナリログは別のディスクにあります（スレーブからデータベースをバックアップするために使用されます）。
フルRAIDを購入してディスクシステムの動作を高速化することは、価格が高いために適していません。 ただし、ディスクを考慮しない場合、サーバー自体はほとんどアイドル状態です。 MyISAMのディスクに書き込む前にメモリ内のデータを圧縮する可能性はありませんが、まだ別のエンジンに切り替える可能性はありません（Falconはできるはずでしたが、OracleはMySQLの購入後に放棄しました）
データベースには約2〜2.5 Gb（tar.gz 700mb）が必要であり、長い間、tmpfs（mylvmbackupに基づく方法）でMySQLを使用しようとしていたため、ディスクをロードせず、バックアップ作成を簡素化できました。 幸いなことに、最近、クラウンを追加してデータベースをクリーンアップしました。これにより、プロジェクトをほとんど使用せず、支払いもしたことがない古いユーザーが削除されます。 さらに、統計用に収集した古いデータをクリーンアップし、約2か月の有効期間を設定しました。
この問題の迅速な解決策として、メインデータベースをtmpfsに転送するというアイデアが生まれました。 私たちは何を得ました：
したがって、3つのサーバーがありました。
1.サーバーA（デーモンがノックする戦闘基地（8GのRAMが搭載されています））
2.サーバーB（無料で動作する同じプラットフォーム上の任意のサーバー（5Gが無料である8Gがあります））
3.サーバーB（別のサイトでは、最大RAMのすべてのプロジェクトのバックアップの下にあります（16Gがあります））
サーバーAでは、ベースファイルのtmpfsを上げます
mount -t tmpfs -o size = 5G tmpfs / var / lib / mysql（ベースウェイトの2倍のマージン）
また、ビンのログが別の空きディスクに書き込まれるようにデータベースの構成に書き込むことを忘れないでください（マスターはそれらなしでは動作しません）。負荷がかかると、データベースはこれらのログに毎秒1Mまで書き込むことができます。 これらのファイルは7日間しか保存しません（スライドが存在する場合にデータベースを復元するため、不要になりました）
したがって、ベースをマスターとして開始します。 同じハードワークロードのサーバーは、メモリから1LAおよび6Gを超えません。 平均クエリの実行速度は10倍になり、以前の0.1〜0.3秒であれば、0.1〜3ミリ秒になりました。
次に、サーバーBで、tmpfsの最初のスレーブも上げます。ここでは、relay-log設定を忘れないでください。 スライドにエラーがあり、ウィザードがこれらのログで利用可能な場合、彼はウィザードにあったリクエストを書き込みます...その結果、スライドを修正する前に、1晩あたり数十ギガバイトで測定できます。1時間あたり約8〜10ギガバイトです。 デーモンへの負荷が最小限の1日1〜2回、夜間にスナップショットでこのベースをバックアップします。 そのような奴隷は、最大0.2-0.3機を食べ、ベースの重量より少し多く食べます。
また、サーバーBでは、プロジェクト用にいくつかのtmpfsスライドをすぐに作成し、サーバーをロードせずに非常に迅速に共存し、同時に10分ごとにスナップショットでバックアップします（この時間を拡張すると、スナップショットは約3秒間実行されます（基本重量は2.5ギガです） ）まあ、アーカイブ内のzhzhivanieは約6〜7分です）、LAサーバーでバックアップが時間内にオーバーラップしても、2を超えません。 どうやら、1つのサーバー上のバックアップスレーブの数は、データベースのサイズとRAMの数によって決まります。 バックアップは10分間（最後の24時間、6時間ごと）、30日、30日ごと、永久に保存します。
さらに、スライドBまたはCが突然落ちた場合は、マスターに触れずに別のスライドから任意のバックアップでそれを拾い上げ、両方とも10分間マスターに触れずに落下して持ち上げた-バックアップのコピーの速度。
マスターがクラッシュした場合、マスターの背後に最大1-2の更新があるスレーブが2つあり（マスターの背後のスレーブ遅延が0秒を超えるのを見たことはありません）、問題の緊急解決はスレーブBから5分以内に行われますマスター...そしてデーモンを再構築します。テスト中、彼らは同じサーバーに静かに住んでおり、互いに干渉しません。
その結果、3台の車が2つの異なるサイトに同時に落下する場合、サーバーまたはサイトのフィードでベースを上げるのに10分もかからないことはほとんどありません。
スライスの遅延を測定して2つのサイトに通知（munin、nagios、zabix-好み）を設定してください。SMSまたは石鹸でできます。nagiosでこれを監視し、同時にmuninが彼に保険をかけ、チャートを描画します。何も、どのように、誰が、すべてが非常に明確にviodnoです。
サーバーの平均負荷は秋に大幅に減少し、主な負荷はディスクではなくプロセッサとメモリによって負担されます。 今日の別のサーバー転送で撮影したグラフは次のとおりです。
データベースの変換後、C ++でユーザーデータを保存する間隔も短縮されたため、更新の回数が増えたことに注意してください。
一般的に、唯一の潜在的な問題はベースの成長です。 ただし、サーバーのメモリは十分に安価であり、メモリを増やしても問題はありません（一部のマシンでは16Gb、一部8Gbですが、私が知る限り、128Gbを天井に置くことができます）。 いずれにせよ、データベースのクラスタリングをキャンセルした人はいません。同様の構成を持つ複数のサーバーにデータベースを配布できます。
これが完全に正しいとは限らない、または何が疑われる。 しかし、データベースをメモリに転送することは、他のデータベース/エンジンを実装するよりもはるかに簡単でした。 コメントがあれば、コメントで読んでうれしいです。
いずれにせよ、おそらくこの経験は誰かに役立つでしょう。
InnoDB-dev.mysql.com/doc/refman/5.1/en/innodb.html
MyISAM-dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html
assandra- cassandra.apache.org
東京の暴君-fallabs.com/tokyotyrant
Berkeley DB-www.oracle.com/technetwork/database/berkeleydb/overview/index-085366.html
mysqltuner-mysqltuner.com/mysqltuner.pl
ファルコン-ja.wikipedia.org/wiki/Falcon_（storage_engine）
tmpfs-en.wikipedia.org/wiki/Tmpfs
mylvmbackup-www.lenzg.net/mylvmbackup
1つのプロジェクトでは、Debian LennyのMyISAMエンジンでMySQLを使用しています。 一般データはC ++のデーモンのRAMにロードされ、ユーザーデータはログイン時に1回ロードされ、ユーザーの作業中に定期的に保存されます。 ログアウト（またはタイムアウト）とともに保存されます。 説明したスキームを考慮すると、選択は更新よりもはるかに小さくなります（選択：24％、削除：4％、更新：61％、挿入：11％）。
原則として、この問題は管理者の問題ではありませんが、ツールの選択があまり良くないことが原因です。 MyISAMのようなテーブルレベルのロック（書き込み時にテーブル全体をロックする）ではなく、行レベルのロック（レコードベースのロック）を使用するInnoDBが適しています。 ディスクに書き込まれるデータの量は減りそうにないが。 一方、私たちは本当にSQLを必要とせず、プロジェクトをNoSQLに移植する傾向があります（私たちは長い間代表者の一部を探していました（assandra）。 しかし、データウェアハウスを別のエンジン/データベースに転送する時間がなかったため、管理者を使用することにしました。 リソース。
ユーザー数の増加と新しいコンテンツの導入に伴い、データベースサーバーの負荷平均が増加するという問題に直面しました（8コアサーバーで2〜3laが1秒あたり400リクエストのみで観察されました）。 さらに、プロセッサと同様に、メモリの負荷が低くなりました。 問題は、大量のデータがディスクに書き込まれることでした（iowaitの増加）。 ある時点で、システムが途切れ始め、いくつかの基本的なクエリに2秒以上かかりました。 通常モードでは、そのようなリクエストはミリ秒単位で実行されます。
MySQL構成を少し最適化しました（mysqltunerなどの自動スクリプトと手動チューニングの両方を使用）が、これにより負荷がわずかに減少しました（10〜15％）。 私たちの主な負担は読み取りではなくデータの更新であるため、ほとんどの場合、データのキャッシュを担当するパラメーターは適切ではありません。 ベースはSASディスク上にありますが、速度はまだ十分ではありません。 バイナリログは別のディスクにあります（スレーブからデータベースをバックアップするために使用されます）。
フルRAIDを購入してディスクシステムの動作を高速化することは、価格が高いために適していません。 ただし、ディスクを考慮しない場合、サーバー自体はほとんどアイドル状態です。 MyISAMのディスクに書き込む前にメモリ内のデータを圧縮する可能性はありませんが、まだ別のエンジンに切り替える可能性はありません（Falconはできるはずでしたが、OracleはMySQLの購入後に放棄しました）
データベースには約2〜2.5 Gb（tar.gz 700mb）が必要であり、長い間、tmpfs（mylvmbackupに基づく方法）でMySQLを使用しようとしていたため、ディスクをロードせず、バックアップ作成を簡素化できました。 幸いなことに、最近、クラウンを追加してデータベースをクリーンアップしました。これにより、プロジェクトをほとんど使用せず、支払いもしたことがない古いユーザーが削除されます。 さらに、統計用に収集した古いデータをクリーンアップし、約2か月の有効期間を設定しました。
この問題の迅速な解決策として、メインデータベースをtmpfsに転送するというアイデアが生まれました。 私たちは何を得ました：
したがって、3つのサーバーがありました。
1.サーバーA（デーモンがノックする戦闘基地（8GのRAMが搭載されています））
2.サーバーB（無料で動作する同じプラットフォーム上の任意のサーバー（5Gが無料である8Gがあります））
3.サーバーB（別のサイトでは、最大RAMのすべてのプロジェクトのバックアップの下にあります（16Gがあります））
サーバーAでは、ベースファイルのtmpfsを上げます
mount -t tmpfs -o size = 5G tmpfs / var / lib / mysql（ベースウェイトの2倍のマージン）
また、ビンのログが別の空きディスクに書き込まれるようにデータベースの構成に書き込むことを忘れないでください（マスターはそれらなしでは動作しません）。負荷がかかると、データベースはこれらのログに毎秒1Mまで書き込むことができます。 これらのファイルは7日間しか保存しません（スライドが存在する場合にデータベースを復元するため、不要になりました）
したがって、ベースをマスターとして開始します。 同じハードワークロードのサーバーは、メモリから1LAおよび6Gを超えません。 平均クエリの実行速度は10倍になり、以前の0.1〜0.3秒であれば、0.1〜3ミリ秒になりました。
次に、サーバーBで、tmpfsの最初のスレーブも上げます。ここでは、relay-log設定を忘れないでください。 スライドにエラーがあり、ウィザードがこれらのログで利用可能な場合、彼はウィザードにあったリクエストを書き込みます...その結果、スライドを修正する前に、1晩あたり数十ギガバイトで測定できます。1時間あたり約8〜10ギガバイトです。 デーモンへの負荷が最小限の1日1〜2回、夜間にスナップショットでこのベースをバックアップします。 そのような奴隷は、最大0.2-0.3機を食べ、ベースの重量より少し多く食べます。
また、サーバーBでは、プロジェクト用にいくつかのtmpfsスライドをすぐに作成し、サーバーをロードせずに非常に迅速に共存し、同時に10分ごとにスナップショットでバックアップします（この時間を拡張すると、スナップショットは約3秒間実行されます（基本重量は2.5ギガです） ）まあ、アーカイブ内のzhzhivanieは約6〜7分です）、LAサーバーでバックアップが時間内にオーバーラップしても、2を超えません。 どうやら、1つのサーバー上のバックアップスレーブの数は、データベースのサイズとRAMの数によって決まります。 バックアップは10分間（最後の24時間、6時間ごと）、30日、30日ごと、永久に保存します。
さらに、スライドBまたはCが突然落ちた場合は、マスターに触れずに別のスライドから任意のバックアップでそれを拾い上げ、両方とも10分間マスターに触れずに落下して持ち上げた-バックアップのコピーの速度。
マスターがクラッシュした場合、マスターの背後に最大1-2の更新があるスレーブが2つあり（マスターの背後のスレーブ遅延が0秒を超えるのを見たことはありません）、問題の緊急解決はスレーブBから5分以内に行われますマスター...そしてデーモンを再構築します。テスト中、彼らは同じサーバーに静かに住んでおり、互いに干渉しません。
その結果、3台の車が2つの異なるサイトに同時に落下する場合、サーバーまたはサイトのフィードでベースを上げるのに10分もかからないことはほとんどありません。
スライスの遅延を測定して2つのサイトに通知（munin、nagios、zabix-好み）を設定してください。SMSまたは石鹸でできます。nagiosでこれを監視し、同時にmuninが彼に保険をかけ、チャートを描画します。何も、どのように、誰が、すべてが非常に明確にviodnoです。
サーバーの平均負荷は秋に大幅に減少し、主な負荷はディスクではなくプロセッサとメモリによって負担されます。 今日の別のサーバー転送で撮影したグラフは次のとおりです。
データベースの変換後、C ++でユーザーデータを保存する間隔も短縮されたため、更新の回数が増えたことに注意してください。
一般的に、唯一の潜在的な問題はベースの成長です。 ただし、サーバーのメモリは十分に安価であり、メモリを増やしても問題はありません（一部のマシンでは16Gb、一部8Gbですが、私が知る限り、128Gbを天井に置くことができます）。 いずれにせよ、データベースのクラスタリングをキャンセルした人はいません。同様の構成を持つ複数のサーバーにデータベースを配布できます。
これが完全に正しいとは限らない、または何が疑われる。 しかし、データベースをメモリに転送することは、他のデータベース/エンジンを実装するよりもはるかに簡単でした。 コメントがあれば、コメントで読んでうれしいです。
いずれにせよ、おそらくこの経験は誰かに役立つでしょう。
InnoDB-dev.mysql.com/doc/refman/5.1/en/innodb.html
MyISAM-dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html
assandra- cassandra.apache.org
東京の暴君-fallabs.com/tokyotyrant
Berkeley DB-www.oracle.com/technetwork/database/berkeleydb/overview/index-085366.html
mysqltuner-mysqltuner.com/mysqltuner.pl
ファルコン-ja.wikipedia.org/wiki/Falcon_（storage_engine）
tmpfs-en.wikipedia.org/wiki/Tmpfs
mylvmbackup-www.lenzg.net/mylvmbackup
All Articles