タグ

readaheadとdeadlineに関するyassのブックマーク (2)

  • Linux Kernel Tuning - GlusterDocumentation

    Linux kernel tuning for GlusterFS Every now and then, questions come up here internally and with many enthusiasts on what Gluster has to say about kernel tuning, if anything. The rarity of kernel tuning is on account of the Linux kernel doing a pretty good job on most workloads. But there is a flip side to this design. The Linux kernel historically has eagerly eaten up a lot of RAM, provided ther

    yass
    yass 2014/08/24
    " buffered before they are communicated to the disk by the Scheduler. The internal queue size of some controllers (queue_depth) is larger than the I/O scheduler's nr_requests so that the I/O scheduler doesn't get much of a chance to properly order and merge the requests "
  • コスいチューニング - フツーな日常

    全く質的でなく効果も小さいものばかりだけど、最後のひと絞りにどうぞ。 Hardware HT無効 今時サーバでNetBurstもないだろうけど、使っているなら切った方が速い。並列実行度が高くなるには違いないが、spin lockとHTは相性がよろしくないし、そもそもNetBurstのHTは速くなる局面が少なすぎる。いっぱいプロセッサが見えるのは気持ちいいが、実効性能を考えると無効の方が速い。 RAID1+0 ブロックサイズは大きめで(256KBとか)にする。"1つのレコードの大きさ <= RIADのブロックサイズ"である状態だと、RAIDを構成する複数のディスクのうち1個へのリクエストで処理が完結するので具合が良い。逆に"1つのレコードの大きさ > RAIDのブロックサイズ"であると、1レコードの読み出しにも2個のディスクがその処理にかかり切りになってしまう。HDDの毎秒の処理回数は上限

    コスいチューニング - フツーな日常
    yass
    yass 2007/12/04
    " ブロックサイズは大きめで(256KBとか)にする。"1つのレコードの大きさ <= RIADのブロックサイズ"である状態だと、RAIDを構成する複数のディスクのうち1個へのリクエストで処理が完結するので具合が良い。"
  • 1