PostgreSQL vs. I/O schedulers (cfq, noop and deadline) The reason why I do benchmarks is that, in my experience, many recommended settings are effectively myths. Many are perfectly fine, but a surprisingly large part either was never quite true or is based on data that got obsolete for various reasons (e.g. changes in hardware or software). So the verification of the facts is rather imporant to ma
PC の HDD を SSD に変更したので、I/Oスケジューラを noop に変更してみた。 SSD は HDD のようにシーク（目的のレコードが記憶されたシリンダにヘッドを移動）したり、サーチ（目的のセクタの先頭がヘッドの位置に来るのを待つ）したり、物理的な動きはない。なので、OSのI/OスケジューラでソートなんかせずにI/Oリクエストを渡してくれたほうが速いとという話だと思う。 簡単に noop が速いことを検証した上で、noop に変更した。 cfq I/Oスケジューラを cfq に設定する [root@yazekats-linux queue]# echo cfq > /sys/block/sda/queue/scheduler [root@yazekats-linux queue]# cat /sys/block/sda/queue/scheduler noop deadlin
米Facebookは10月10日、Linux向けの汎用キャッシュ技術「FlashCache ⒊0」を公開したことを発表した。SSDをキャッシュ用ストレージとして利用するための技術で、コストを抑えつつ性能を強化できるという。 FlashCacheはSSDをキャッシュデバイスとして使用するためのオープンソースプロジェクトで、Facebook社内で2010年にスタートした。Linuxカーネルデバイスラッパーのターゲットとして実装するというソフトウェアベースのアプローチをとる。データ書き込み時にHDDと同時にSSDにも書き込みを行い、読み出し時にはSSDを参照する。Facebookがユーザーデータを保持しているというMySQLとInnoDBエンジンと連携して動作するよう開発されているが、Linuxシステムのキャッシュシステムとしても利用できるという。 ⒊0は新しいブランチとなり、読み出しと書き込み
エンタープライズシステムのエンジニアをやって１０年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化（CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど）するのにディスク（ストレージ）が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
