AWS re:Invent2013参加レポート #19 EC2 ブロックストレージ(EBS/インスタンスストア)ベストプラクティス | DevelopersIO
ども、大瀧です。 今回のre:Invent参加で個人的にアツかったテーマのひとつが、EC2のブロックストレージ周りのセッションで濃いものが聞けたことです。3日目と4日目に行われた以下のセッションから、現時点でのブロックストレージのベストプラクティスが見えてきそうだったので、セッションから得られたことを自分なりにまとめてみました。 STG402 - Advanced EBS Snapshot Management [11/14 17:30 Murano 3303] STG401 - NFS and CIFS Options for AWS [11/15 10:15 Venetian B] ちなみに、プレゼンターはどちらもAWSでパートナーSAを務めるCraig Carlです。軽快な語り口で、Q&Aもスピーディーに答えていました。そのせいで、議論がヒートアップすると全然聞き取れなかったんですが
RAIDコントローラのキャッシュ構成 - とあるSIerの憂鬱
コントローラがもっているキャッシュは『コントローラ・キャッシュ』と呼ぶ。 コントローラ・キャッシュをライト・キャッシュとして使用する場合、電源断でキャッシュ内容が消失しないよう、バッテリを内蔵する。 バッテリが無い場合、バッテリの充電が十分でない場合はライト・キャッシュを使用しないライト・スルーに自動で切り替わる。 バッテリ動作の期間内にコントローラ・キャッシュの内容を保持するだけでなく、不揮発のフラッシュ・メモリに書き込むものもある。 リード・キャッシュは効果が少ないため、HPのコントローラではリード・キャッシュ25%、ライト・キャッシュ75%の比率がデフォルト。 コントローラ・キャッシュはRAIDのパリティ計算などコントローラの作業用メモリとしても使われる。 HDD自体が持っているキャッシュ(バッファ)は『ディスク・キャッシュ』と呼ぶ。 サーバ向けのHDDではディスク・キャッシュは通常
「ディスク」への書き込み性能を上げるには - （ひ）メモ
ユーザランドのプロセスから見たwrite(2)は、ページキャッシュのおかげで(メモリが潤沢にある環境下では)ブロックされない(待たされない)というのは id:naoya さんの丁寧な解説のおかげでわかると思うのですが、一方、fsync(2)などの実際にディスクに書き込む処理、 あと id:hirose31 さんがコメントしてますが、アプリケーションが SYNC モードでファイルを開いてたり、明示的に fsync() してたりするとそこで wait が発生するのは言わずもがな、です。 Linux I/O のお話 write 編 - naoyaのはてなダイアリー The fsync() function does not return until the system has completed that action or until an error is detected. fsync
コスいチューニング - フツーな日常
全く本質的でなく効果も小さいものばかりだけど、最後のひと絞りにどうぞ。 Hardware HT無効 今時サーバでNetBurstもないだろうけど、使っているなら切った方が速い。並列実行度が高くなるには違いないが、spin lockとHTは相性がよろしくないし、そもそもNetBurstのHTは速くなる局面が少なすぎる。いっぱいプロセッサが見えるのは気持ちいいが、実効性能を考えると無効の方が速い。 RAID1+0 ブロックサイズは大きめで(256KBとか)にする。"1つのレコードの大きさ ＜＝ RIADのブロックサイズ"である状態だと、RAIDを構成する複数のディスクのうち1個へのリクエストで処理が完結するので具合が良い。逆に"1つのレコードの大きさ ＞ RAIDのブロックサイズ"であると、1レコードの読み出しにも2個のディスクがその処理にかかり切りになってしまう。HDDの毎秒の処理回数は上限
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
