前回はWindowsでのサーバやPCのボトルネック箇所の簡単な見分け方をご紹介させていただきましたが、要望がありましたので今回はLinuxの場合をご紹介いたします。 4つの主要ボトルネック要素の復習です。 サーバやPCには4つの主要ボトルネック要素があります。このいずれかがボトルネックとなった場合システム全体のレスポンスが低下します。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 Linuxにおいてはボトルネック箇所を以下のように見分けることができます。 1. CPU使用率 CPU使用率が常に100%に近い場合はCPUがボトルネックであることが判明します。CPU使用状況を簡単に調べるには3つの方法があります。「top」「w」「vmstat」コマンドを使う方法です。 -----------------------------------------------------
業界トップ のエンタープライズ Hadoop 企業 Cloudera に入社しました http://www.cloudera.co.jp/ 今年の6月に、「平成２１年度 産学連携ソフトウェア工学実践事業報告書」というドキュメント群が経産省から公表されました。 そのうちの一つに、NTTデータに委託されたHadoopに関する実証実験の報告書がありましたので、今更ながら読んでみることにしました。 Hadoop界隈の人はもうみんなとっくに読んでるのかもしれませんけど。 http://www.meti.go.jp/policy/mono_info_service/joho/downloadfiles/2010software_research/clou_dist_software.pdf 「高信頼クラウド実現用ソフトウェア開発（分散制御処理技術等に係るデータセンター高信頼化に向けた実証事業）」という
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
特種用途自動車です！ 真空ポンプです！ 工業用アイロン台です！ 3人合わせて、バキュームです！ と書いた後で、すでに先達がいたことに気づいたわけですが、Firefoxを「バキューム」すると、動作が機敏になる、というTipsがブログ・Mozilla Linksで紹介されていました。 日々ブラウジングにいそしんでいると、履歴とブックマークを格納する「places.sqlite」に、履歴などが澱のように溜まってしまったり、データベースが断片化したりすることで、Firefoxの動作が遅くなってくる、という問題に直面します。そこで「places.sqlite」を最適化することで、インストールしたてのまっさらだったころのFirefoxの、あのスピードを取り戻すのが「バキューム」というわけです。 手順はわずか3ステップ。 「ツール」→「エラーコンソール」をクリック 以下のテキストをコピー＆ペースト Co
モバイルファクトリーの松野です。 本稿では、Wassr をどのようにチューニングしているか、という話をしたいとおもいます。 Wassrはその性質から負荷が集中しやすいサイトであり、DBへの書き込み・読み込みともに大量に発生するサイトですから、かなりマメにチューニングしてやらないといけません。 一時的な大量のアクセスへの対処 一方で、大量のアクセスが発生することもあります。 図1 Twitter,Wassrのサイト比較 図1のように、競合サイトのTwitterが落ちるとwassrに避難してくる人達がいますので、急激にアクセス数があがることがあります。このような場合にどのようにチューニングしていくかというのが一つの課題です。 実際に、このWassrへのアクセス集中の際には ユーザタイムラインの表示停止 サーバの増強 という2つの方策によって、落ちないように対策しました。 サーバの増強に対しては
JDK16 jconsoleの動作例 JavalobbyにおいてJavaパフォーマンストラブルシューティングに役立つ10のツールがTop 10 Java Performance Troubleshooting Toolsとして紹介されている。OSの限定されるツールもあるため実質的には7つの紹介とみていいだろう。Javaのパフォーマンス分析といえばJDK 6 Update 7からJava VisualVMが同梱されるなど今後のさらなる発展が期待される分野だ。同文書で紹介されているツールは次のとおり。 jconsole - JDK1.5およびそれ以降のバージョンに同梱されているJavaモニタリングおよびコンソール管理ツール。JMX互換のグラフィカルツールでローカルで動作しているJava仮想マシンもリモートで動作しているJava仮想マシンもどちらもモニタリング可能 VisualVM - 高性能な
PostgreSQLを遅くしている犯人はどこだ？：Linuxトラブルシューティング探偵団（3）（1/3 ページ） NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。引き続きOSSに関するトラブルの解決過程を＠ITで連載していくぜ。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！ 助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
