タグ

TipsとPerformanceに関するdrivejpnのブックマーク (9)

  • スワップサイズをゼロにしてはいけない

    先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。 まず、書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、このをほめてくださっていることに大変感謝しています。まだ自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。 最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をして

  • 限界までMySQLを使い尽くす!!

    どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値(16MBなど)に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは

    限界までMySQLを使い尽くす!!
  • あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー

    お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinuxtop して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と

    あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
  • MySQLの状態がリアルタイムでわかるMySQL用topコマンド「mytop」と「innotop」

    サーバのチューニングをする上でかなりやっかいなのがデータベース系。特にログファイルの量が膨大になると後から中身を見て問題を分析するのも一苦労という場合が。そんなときにこのMySQLtopコマンド「mytop」を使えば一体何が起きているのかがすぐにわかるので問題点の把握が容易になります。ベンチマークするときに併用すればかなり効率が良くなるのではないかと。 インストールと使い方は以下の通り。 まずは「mytop」から。以下が公式サイト。 mytop - a top clone for MySQL http://jeremy.zawodny.com/mysql/mytop/ マニュアルは以下にあります。 mytop - display MySQL server performance info like `top' インストールするにはSSHなどを使ってrootでログイン後、wgetでファイル

    MySQLの状態がリアルタイムでわかるMySQL用topコマンド「mytop」と「innotop」
  • さらにMySQLを高速化する7つの方法

    MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗(?)でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう!!と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢(オトコ)のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負!!というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ

    さらにMySQLを高速化する7つの方法
  • マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー

    ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった

    マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
    drivejpn
    drivejpn 2009/03/07
    Linuxのロードアベレージを kernelレベルで説明
  • naoyaのはてなダイアリー - 負荷とは何か

    調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ

    naoyaのはてなダイアリー - 負荷とは何か
    drivejpn
    drivejpn 2009/03/07
    Linuxの負荷をkernelレベルで説明
  • Performancewiki «

    Willkommen zur deutschen Version von WordPress. Dies ist der erste Beitrag. Du kannst ihn bearbeiten oder l�schen. Und dann starte mit dem Schreiben!

    drivejpn
    drivejpn 2009/03/07
    ボトルネック別負荷調査方法
  • performancewiki.com - performancewiki リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

    drivejpn
    drivejpn 2009/03/07
    [I/O]Linux I/Oの正体調査
  • 1