概要 SSDで寿命とかパフォーマンスを改善するために設定しておいた方が良い点のまとめです。 よくある系のネタですが、久しぶりにSSD設定見なおしたら勘違いしてた点がいくつかあったので備忘を兼ねて残します。目次見て「こんなの常識だよね」って思った方はスルーしてくださいm(_ _)m 基本 firmwareを最新化する kernel/osはなるべく新しいものを使う 新しいファイルシステムを使う(多分今のところext4が一番良さそう) swapしないようメモリを沢山積む TRIMを使う TRIMとは SSD上のデータは削除しても削除マークが付くだけで削除されません。 この状態のブロックにデータを書き込む場合、一度完全に消去してから書き込みます。 TRIMコマンドはOS上のファイルが不要になったことをSSDに伝えて明示的にデータの消去を行うコマンドです。 メリット TRIMを使わない場合、以前デー
ハードウェア層 OS層 クラスタの留意点 負荷分散 ベンチマーク BitcaskとLevelDB コンフィグファイル スケールアウトとスケールアップの手順 運用上の注意点 64ビットCPUアーキテクチャ 最低4GBのメモリ。メモリは最も重要。局所性を活かせるのであれば多くメモリを必要としない。 RAID0、SSDを考慮すると良い。IOバウンドになりがちなので。 ミラーリング(RAID1)は考えなくて良い。 RAID(RAID1？)はやめちゃいな(クラスタ組んでるしいいんじゃない？的な？)。 ディスクサイズ重要。 ギガビットイーサも考慮にいれて。ネットワークも使うよ。 仮想マシンを使う場合は一番良いインスタンスを使う。同じデータセンタ/リージョンに配置するようにする。 クラスタ全体で必要なディスクサイズは次のように計算できる。 オブジェクト数 * 平均オブジェクトサイズ * n_val 50
つい先日こんな日記を書いた。 サーバのHDD 原因はディスクI/Oだ！という結論は決して間違っていなかったんだけど、根本的なことを理解していなかったばっかりに、この日記を書いたあとも多いにはまりましたよ…という話。 そもそも今回の件って、さくらインターネットの専用サーバを新規に借りて、そこにRHEL6をのっけたところがスタートだったわけです。で、サーバが利用できるようになってから、サイトのセットアップを済ませ、いざ運用テストを行ってみた段階で、DBに対する書き込みのパフォーマンスが全然あがらない。なのでHDDの障害を疑って、そして再セットアップまで行ってもらったというのが前回の話。 ただ、再セットアップしてもらった環境で、改めてベンチマークとってスループットチェックを行っても、全然パフォーマンスが変わらないわけです。ベンチマークに利用したdbenchの傾向として、Flash項目だけずばぬけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く