トラブルシューティンに関するeightterのブックマーク (3)

  • 【真夏の夜のミステリー】Tomcatを殺したのは誰だ?

    2007/xx/xx xx:28:50 org.apache.tomcat.util.threads.ThreadPool logFull 致命的: すべてのスレッド (200) が現在稼働中で待機しています。maxThreads (200) を増やすか、そのサーブレットのステータスをチェックしてください これは、Tomcatの持つスレッドプールが最大スレッド数に達してしまったという内容のメッセージだ。Tomcatは、スレッドの生成/破棄のオーバヘッドを削減するため、スレッドプーリングの機能を持っている。スレッドの数が多過ぎるとサーバ上のリソースを消費し過ぎてしまうため、プールには上限値として最大スレッド数を設定できる。 ■Tomcat解剖 それでは、最大スレッド数に達した場合にはどうなってしまうのか。それを理解するためには、Tomcat内部の動作に関する知識が必要となる。図3はTomca

    【真夏の夜のミステリー】Tomcatを殺したのは誰だ?
  • @IT:Javaパフォーマンスチューニング 第3回

    記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの

    @IT:Javaパフォーマンスチューニング 第3回
  • 【真夏の夜のミステリー】Tomcatを殺したのは誰だ? (1/3) - @IT

    【真夏の夜のミステリー】Tomcatを殺したのは誰だ?:現場から学ぶWebアプリ開発のトラブルハック(6)(1/3 ページ) 連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。(編集部) 【第1章】Tomcatが無応答!? トラフィックの多い大規模サイトでは、その負荷のためにさまざまな問題が発生する。それらの問題を回避するには、性能を考慮して作られたアプリケーションや、ノウハウに基づいたミドルウェアのチューニングが必要となる。 TomcatはServletコンテナとしての長い歴史を持ち、多くの採用実績を持つオープンソースのアプリケーションサーバ(以下、APサーバ)だ。大規模なサイトで採用される事例も出てきており、To

    【真夏の夜のミステリー】Tomcatを殺したのは誰だ? (1/3) - @IT
  • 1