問題タブ [solid-state-drive]

並列 I/O に関するいくつかのテストで、非常に奇妙な状況が発生しています。ここに状況があります..複数のスレッドが同じファイルへのファイルハンドラーを開き、ファイルの複数の場所 (等間隔) から有限数のバイトを読み取り、それを配列にダンプします。すべてブーストスレッドで行われます。ここで、ランダム アクセス シークのために遅くなるはずの HDD を想定しています。これが、私のテストが実際に SSD を対象としている理由です。HDDと比較して、ソリッドステートディスクから同じファイルを読み取る場合、ほとんど高速化されないことがわかりました。何が問題なのだろうか？それは私にとって非常に驚くべきことですか/私が正確に何をしているのかを確認するために、以下のコードも投稿しています:

今..私のメインファイルに私はほとんど持っています..:

驚いたことに、SSD からの読み取りでは、HDD と比べて速度が向上しませんか? それはなぜでしょうか？

ハードウェアの SSD が正しいデバイス ドライバーによって検出されない状況をデバッグしようとしています。SSD を所有するデバイス ドライバーは、ミラーリング モードで 2 つの SSD を自動的に構成するソフトウェア RAID ドライバー (megasr) です。megasr ドライバーが SSD を検出/所有していないことは確かですが、どのドライバーが実際にそれらを検出するかはわかりません。

/dev ディレクトリ内の特定のディスクを所有しているデバイス ドライバを特定できる Linux の方法はありますか。

したがって、たとえば、どのドライバーがデバイス /dev/sda を所有しているかを判断したいと思います。

OSはRHEL6.xです。

どうもありがとう。

これが Stack Overflow の有効な質問かどうかはわかりませんが、Crucial Micron SSD の SMART データに興味深いものがあることに気付きました。SMART データ内には、ファームウェアが古くなっていることを警告する URL が埋め込まれていました。

ご覧のとおり、SSD はファームウェアが古いことを認識しており、問題に関する Tom's Hardware の記事を参照することさえできました。

私の質問は... SSD はどのようにしてこれらの URL を収集できたのでしょうか? コールホーム機能が組み込まれていますか?

ありがとう、

ディスクのパフォーマンスが興味深いアプリケーションを書いています。私は以前、古い機械式ディスクを使用し、このスレッドの手法を使用して、パフォーマンスを測定する前にキャッシュをクリアしました。

それはうまく機能し、期待どおりの結果が得られました.キャッシュをクリアすると、測定されたディスクシーケンシャル読み取り速度は約100 MB /秒になり、キャッシュをそのままにしておくと何倍も速くなりました.

先日、/media/ の下にマウントされた SSD ディスクをインストールしました。コンピューターを新たに再起動した後、最初の数回の測定値は予想どおり (約 300 MB/秒) ですが、キャッシュが開始されると、明らかにはるかに高くなります。

私の問題は、アプリケーションを SSD に移動して以来、以前に使用したコード行が効果がないことです。そのキャッシュは別の方法で動作しますか? それをクリアするために何か違うことをする必要がありますか？現在機能する唯一のことは、コンピューターの再起動です。

最近、既存の MySQL (XP 32 ビット + HDD) を Vista 64 ビット (16 GB RAM) で動作する新しいマシンに切り替えました。データ ストレージは SSD (Samsung Pro 840) です。

データは Unix サーバーから取得され、毎日置き換えられるため、データ転送はありません。代わりに、既存のバッチ ジョブが更新され、新しいサーバー アドレスを指すようになりました。しかし、このバッチ ジョブの実行速度ははるかに遅くなります。つまり、7 時間のジョブが 15 時間になります。

SSD をデータ ストレージとして使用すると IO が向上するはずですが、逆です。

私はいくつかの調査を行い、my.ini 構成を微調整しましたが、これらのどれも改善をもたらしません。

データをファイル内にロードし、チャンクを小さくすると、パフォーマンスが 7 時間まで改善されましたが、それでも SSD を使用するメリットはありません。

私が間違ったことをしましたか？助けてください。

通常、cassandra では 2 つの別個のディスクを使用することをお勧めします。1 つはコミット ログ用、もう 1 つはその他すべてのログ用です。

ただし、構成ガイドラインの最近の更新と思われるものでは、次のフレーズが表示されます。

SSD の場合、コミット ログと SSTable の両方を同じマウント ポイントに配置することをお勧めします。

SSDの場合、1つのディスクのみを使用することが推奨される理由を誰か説明できますか? ありがとう。

これが私の難問です。

私が取り組んでいるプロジェクトでは、ブランチを 1 日に数回切り替える必要があります。マシンのグラインドを停止すると、Visual Studio がソリューションをリロードするまでの 10 分間、生産性が大幅に低下します。

コンパイル時間は非常に遅く、この間はマシンがまったく使用できないため、コーヒーを作る時間は 2 ～ 5 分です。

今、私の仕事用マシンは野獣ではありませんが、事務員の POS でもありません。8GBのRAMを搭載したハイスペックi5。HDDはおそらく安価なジャンク品です。

私たちのソリューションには約 11,000 のファイルがあり、今後も増え続けます。

スピードアップするにはどうすればよいですか？

SSD でおそらく 4GB 以上の RAM を考えていましたが、RAM ドライブをセットアップしますか?

SSD ルートを使用する場合は、SSD で何が行われ、何が行われないかについての提案を歓迎します。

テーブルの列に char/varchar2 データ型を選択し、テーブルでバッチの削除/挿入/更新を発行するとき、行の断片化は常に考慮する必要がありました。これは、Oracle が新しいデータを開いている空き領域に合わせようとするため、断片化が遅くなり始める可能性があるためです。一時的にパフォーマンスを低下させます。フラッシュテクノロジー自体により、データは可能な限り断片化されて書き込まれるため、フラッシュストレージディスクですべてが変わりました。断片化に注意する必要がない場合、テーブル データ ストレージの問題とデータの断片化に関する理解が完全に失われます。データベース ファイルをフラッシュ ストレージ ディスクに保存した経験のある人はいますか? フラグメンテーションの問題は SSD ディスクで解消されましたか?

現在、Amazon の EC2 インスタンスにデプロイされている mongodb シャード クラスターがあります。これらのシャードもレプリカ セットです。使用されるインスタンスは、IOPS がプロビジョニングされた EBS を使用しています。

コレクションには約 3,000 万のドキュメントがあります。クエリは、フィルターに一致するコレクション全体をカウントします。クエリ可能なフィールドのほぼすべてにインデックスがあります。これにより、RAM の使用率が 100% に達します。ワーキング セットが RAM のサイズを超えています。クエリの応答が遅いのは、EBS が遅いことが原因であると考えているため、新しい SSD ベースのインスタンスに移行することを考えています。

C3 が利用可能 http://aws.typepad.com/aws/2013/11/a-generation-of-ec2-instances-for-compute-sensitive-workloads.html

I2 は近日公開予定 http://aws.typepad.com/aws/2013/11/coming-soon-the-i2-instance-type-high-io-performance-via-ssd.html

私たちの唯一の懸念は、SSD がエフェメラルであることです。つまり、インスタンスが停止、終了、または失敗すると、データは失われます。どうすればこれに対処できますか? バックアップを自動化する方法。クエリのパフォーマンスを向上させるために SSD に移行することは良い考えですか? シャード クラスターをセットアップする必要はありますか?