SSDが来ると思われますが、ここにあります-幸せ！ 機構はなく、頭が目的のポイントに達するまで待つ必要はありません（特に、データが断片化されているか、OSが一度に多くのことを読み取ろうとしている場合）。 しかし、いいえ-高価で、信頼性が低く、十分なスペースがありません-一般に、サーバーに置くことはできません。
解決策は何ですか？ そう、組み合わせて！ タスクは、SSDの速度とアクセス時間、およびHDDの信頼性とボリュームを取得することです。 ハードウェアソリューションはありますが、経済的に精通していないため、フラッシュキャッシュを使用してプログラムで実行します。
フラッシュキャッシュとは何ですか？
facebookのflashcacheを使用していますが、何らかの理由でHabréについてはほとんど言及されていません。
FlashcacheはFacebook内で作成され、サーバー上のMySQL（および他のDBMS）を高速化し、2010年にオープンソースとして公開されました。
その本質は簡単です。SSD上の透過的なキャッシュです。 2つのブロックデバイス（通常はhdd-「from where」およびssd-「where」）に基づいて、別のキャッシュデバイスが作成され、システムで使用されます。 SSDの透過キャッシュにより、HDDとSSDの両方の利点を組み合わせることができます。
すべての始まり
約2年前、 私の友人が真剣にドイツからの車の選択と販売でサイトプロジェクトを開始しました。 このサイトは以前は共有ホスティング上に存在し、非常に愚かでした-エンジンは、メインページが約2〜3秒間生成されたときに、誰にでもわかりにくい形で書き込まれました。 出席者の急速な増加は、彼がまだ住んでいる別の人物-fastvps（hetznerの再販業者）からのプロモーションi7への移行をもたらしました。 しばらくして、8〜10の領域の負荷平均はほぼ標準になりました。コードの修正を行う必要があることが明らかになりました。
私はある時点でかなり長い間笑いました-メインページには約3秒間機能するインクルードがあり、それが何をしていたのか明確ではありませんでしたが、それなしでは機能しませんでした。 監査の結果は予測可能ですが、まだ悲しいものです。何を編集するよりも、すべてをゼロから書き直す方が簡単であることが判明しました（現在行っています）。 キャッシングを使用したSSIの一部のブロックの削除は少し役立ちました（nginx + php-fpmは既にそこにスピンしていました）が、何かしなければなりませんでした。 すべてを新たに書くのは長い時間でした（そして所有者はまだそのような決定にまだ満足していません-こんにちは、サーシャおじさん！:)）、彼らは代替ソリューションを探し始めました。 意識の端は、どこかで考えを聞いた表面に押し出されました-SSDにキャッシュできます。 思考は回転し、dr死しました。
6か月前、転機が来ました-RAID-1の2台の（たわごとが発生する） ハードドライブが一度にマールボロ地方に飛びました。 hetznerがHDDを変更している間、彼らは決心しました。 そして、彼らはさらにSSDも注文しました。
それの由来
6か月前にすべてが設定され、すぐにflashcacheで行われたため、「前」と「後」のチャートをプロットするためにすべてを停止する必要がありました。
そのため、グラフでは、左から右への断片：
- フラッシュキャッシュを使用する
- シャットダウンブレーク
- HDDから直接フラッシュキャッシュなしで動作します（負荷のせいで貧弱なzabbixはデータを保存できませんでした-理解して許してください）
- すべてをオンに戻すための休憩（ここで私がミスをしたが、これについては後で）
- フラッシュキャッシュを使用する
- エラー修正ブレーク
- 通常モードでの通常動作（フラッシュキャッシュを使用）
CPU負荷
巨大なロサンゼルスの古き良き時代に戻る：
HDDおよびSSDのロード
ここで、sdaはRAID（mdadm）の一部としてのHDD、sdcはキャッシュとして機能するSSDです。 sdb-空襲から2番目のHDD、私はグラフを与えませんでした-すべてがそこのsdaに非常に似ています。
HDDロード：
ご覧のとおり、HDDは非常に悪くなります-応答時間は1秒に達します。
SSD、ここではすべてがシンプルで明確です：
サイトのロード時間
サイトのメインページの読み込み時間を測定しました。 ブロックキャッシュを使用するSSIがいくつかあります。 これは私のお気に入りのスケジュールです。
私の意見では、結果は明らかです。
結果と落とし穴
サーバーの応答性が大幅に向上し、MySQL-より速く（測定は行われませんでした）、ヘア-より柔らかく、シルキーになりました。
I / Oの負荷が重いためにサーバーがほとんど呼吸していない場合は、考えないでください。 flashcacheをインストールします。 プロジェクトページには、その調理方法と調理方法に関する適切な説明があります。 これにこだわるつもりはありません-これに関するドキュメントがあります。 私が遭遇した困難のいくつかを強調したいだけです。
- Flashcacheは32ビットシステムでは機能しません。 コードには、修正を急ぐ人はいないという愚かな間違いがあります。Facebookには64ビット環境があります。
- 起動時にDebianのフラッシュキャッシュボリュームを初期化するためのinitramfsのフックとスクリプトが含まれますが、lvm上のボリュームでは機能しません（起動時にlvmが初期化されないため）。 スクリプトの冒頭で- / sbin / vgchange -ayをハックすることにしました。 もちろん間違っていますが、その後すぐに行う必要がありました。
- フラッシュキャッシュが実行されている上でボリュームをマウントして使用することは、（無効になっている場合でも）明確に不可能です。 もちろん、それは可能ですが、フラッシュキャッシュは変更を認識しません。 私にとっては、再起動後にわずかに打ち負かされたFSで終了しました（グラフの3番目の失敗）。 そうです-フラッシュキャッシュを停止し、無効にし（dmsetup remove）、ボリュームで必要なことを行い、SSD上のフラッシュキャッシュボリュームを削除し （flashcache_destroy）、再度フラッシュキャッシュを作成します。 fsのチェックなどの操作では、これはすべてオプションであり、フラッシュキャッシュボリュームを既にチェックしています。
ウクライナのhabrayuzerに関連する広告として
当社のウェブサイトでは、「ターンキー」を含むドイツの車を見つけて注文できます。