オープンセミナー2017@岡山での発表スライドです
交通量に見合った道路を作ったり,工場の排煙を減らす高度なごみ処理施設を建設したりする,といった基本的な都市計画がなされていない,つまり「都市基盤」が整備されていなければどうなるか。道路は慢性的に渋滞しており,たどりつくだけで一苦労。街で交通事故が発生しても救急車が現場に到達することさえままならない。工場は排煙をまき散らし,深刻な大気汚染を引き起こす──。 情報システムにも,同じことが当てはまる。豊富な機能を持つアプリケーションを開発することは確かに重要だ。だが,サーバーやストレージの性能や信頼性,ネットワークの回線速度などを無視していては,システムの品質を保つことは難しい。システム開発に携わるあらゆるITエンジニアにとって,システムの性能や信頼性などを左右する「システム基盤」の知識は不可欠だ。そこで本講座では,システム基盤を理解するための基本的な技術や用語から,実践的な開発方法論までを解説
以前の記事でトラブルが起きた後の初動対応を書いてみたが、いざトラブルに遭遇すると、まず再起動してからどうするか考えるケースが多いと感じている。しかし何も情報がないと『情報がない/再現方法が不明』などの理由からそのままお蔵入りになってしまう。今回はトラブルに事前に備えるために、地味だけど大切なJavaVMのオプションをまとめてみる。 GCログの出力とローテーション OutOfMemoryError発生時のヒープダンプ自動出力と出力パス設定 JavaVMクラッシュログの出力パス設定 JVMオプションの設定 (OpenJDK/OracleJDK) JavaVMにはGCおよびヒープメモリの状態をロギングする仕組みや、OufOfMemoryError時にヒープダンプを自動的に出力するような障害に備えて自動的に情報を出力する機能がある。おすすめのオプション*1は以下の通り。 java -Xms?g -
■時間がかかっているSQLの特定方法 例 1回あたり60秒以上かかったSQLを調べる select to_char(last_active_time, 'yyyy/mm/dd hh24:mi:ss'), sql_id, hash_value, sql_text, round(cpu_time/1000000,2), round(elapsed_time/1000000,2), executions, buffer_gets, disk_reads from v$sql where executions > 0 and elapsed_time/executions/1000000 >= 60;
本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。(編集局) 連載目次 前回までの記事でSQLチューニングを行うために必要な基礎知識を説明しました。今回は、チューニング対象とすべきSQLを、どのような観点から、どのように洗い出していくのかを説明していきます。 チューニング対象SQLの洗い出し 通常、アプリケーションでは多くのSQLが実行されています。SQLチューニングのステップは、実行されている多くのSQLの中から、チューニングの目標に合わせて、対象とするSQLを洗い出
Javaトラブルでは『情報がなくて、再現もなかなかしません』といった状況に陥ることがある。このような状況を回避するために、以下の3つの代表的なトラブルを例に、アプリケーションサーバを再起動する前に何を取得すれば良いのかをまとめてみる。 アプリケーションから応答がない アプリケーションが遅い ヒープメモリが足りない(OutOfMemoryErrorの発生) アプリケーションから応答がない 取得する情報 スレッドダンプ データ取得方法 スレッドダンプとは、コマンド実行時点でのJavaスレッド実行状態を出力したものである。応答がない場合、何らかの要因によりどこかで処理が止まっていることが想定される。スレッドダンプは『どこで止まっているのか?』を切り分けるのに大切な情報である。 取得方法はJDKのバージョンによって色々ある。 kill -3 <pid> (少なくとも1.4.2にはある〜JDK7でも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く