タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

mysqlとlinuxに関するaprlのブックマーク (3)

  • naoyaのはてなダイアリー - Linuxのページキャッシュ

    世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io

    naoyaのはてなダイアリー - Linuxのページキャッシュ
    aprl
    aprl 2008/01/09
    MySQL が動いてるサーバーをメンテナンスで再起動したり、あるいはバックアップでデータを総なめした後にすぐ稼動させると、I/O 待ちが発生してスループットが出ないことがよくあります。
  • ユメのチカラ: MySQLのマルチコアスケーラビリティとLinux

    スラッシュドットの情報。FreeBSDとLinuxでsysbench(MySQLを利用している)の結果が出ている。結論から言うと8コアのAMD64のマシンでスレッド数を上げていくと8スレッドまではLinuxでの性能が良かったが、それ以上になるとがたっと性能が劣化して、FreeBSDのSMPngの実装が勝つ。 下記を参照してほしい。 http://jeffr-tech.livejournal.com/6268.html MySQL 5.0.2xではSMPスケーラビリティに問題があることは、われわれの性能評価でもあきらかになっていたが、(例:MySQLに対応した評価ツールDBT-1を利用したハードリソース変更によるパフォーマンスへの影響の考察を参照)、OSのSMPスケーラビリティ問題というよりMySQLの実装上の問題だと考えていた。 linux 2.6.18/2.6.20.1上でMySQL 5

    aprl
    aprl 2007/12/26
    linux 2.6.18/2.6.20.1上でMySQL 5.0.27と5.0.33(スケーラビリティの問題を若干解決した)を評価したグラフを見ると、linuxはスケーラビリティの問題がある。スレッド数がコア数(8)を越えたあたりから性能が急激に劣化
  • MySQL :: MySQL 5.1 リファレンスマニュアル :: 2.13.1.4 Linux のインストール後の注釈

    mysql.server はMySQL インストール ディレクトリの support-files ディレクトリあるいは MySQL のソース ツリーにあります。それを自動的起動・シャットダウンの /etc/init.d/mysql としてインストールします。項2.10.2.2. 「MySQL を自動的に起動・停止する」 参照。 MySQL が十分なファイルや接続ができない場合、十分なファイルを処理する Linux を設定していない場合があります。 Linux 2.2 およびそれ以降では、割り当てられたファイル処理を以下のようにチェックできます。 shell> cat /proc/sys/fs/file-max shell> cat /proc/sys/fs/dquot-max shell> cat /proc/sys/fs/super-max 16MB 以上のメモリがある場合、何か以下のよ

  • 1