Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード

2017-09-15

MySQL で NOT NULL 制約のある列に複数行インサートするとその型のデフォルト値が入る

MySQLSQL モードが STRICT モードでない場合、NOT NULL 制約のある列に複数行インサートするとその型のデフォルト値(0とか空文字)が入る(1行インサートだとエラーで入らない)。


検証結果

  • Amazon Aurora with MySQL Compatibility に接続する
$ mysql -h ******.******.ap-northeast-1.rds.amazonaws.com -u awsuser -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 53
Server version: 5.6.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use mydb;
Database changed
  • テーブルを作成する
mysql> create table `not_null_test` (
    ->   `id` int(10) unsigned not null,
    ->   `int_col` int(10) unsigned not null,
    ->   `char_col` char(10)  not null,
    ->   `ts_col` timestamp not null,
    ->   primary key (`id`)
    -> ) engine=innodb default charset=utf8;
Query OK, 0 rows affected (0.05 sec)
  • SQL モードは設定されていない
mysql> select @@global.sql_mode;
+-------------------+
| @@global.sql_mode |
+-------------------+
|                   |
+-------------------+
1 row in set (0.02 sec)
  • 1行インサートはエラーになる
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be null
  • 複数行インサートは成功する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null), (2, null, null, null);
Query OK, 2 rows affected, 4 warnings (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 4
  • テーブルのデータを確認する
mysql> select * from not_null_test;
+----+---------+----------+---------------------+
| id | int_col | char_col | ts_col              |
+----+---------+----------+---------------------+
|  1 |       0 |          | 2017-09-15 06:54:07 |
|  2 |       0 |          | 2017-09-15 06:54:07 |
+----+---------+----------+---------------------+
2 rows in set (0.02 sec)
  • SQLモードを STRICT_ALL_TABLES にする
mysql> set sql_mode='strict_all_tables';
Query OK, 0 rows affected (0.03 sec)
  • 1行インサートは失敗する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be null
  • 複数行インサートも失敗する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null), (2, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be nul

参考

単列インサートの場合はNOT NULLが指定されたカラムにNULL値が挿入されるとそのクエリはエラーとなって失敗するが、複数列インサートの場合は警告(warning)を発するものの、クエリは正常に受け付けられる。

その際、NULL値が指定された各カラムにはそれぞれのカラムのデータ型の暗黙的なデフォルト値が挿入される。(数値型なら0、文字列型なら空文字''、etc…)

MySQLにおけるNOT NULLカラムへのインサート時の挙動 - Sojiro’s Blog

NOT NULL として宣言されているカラムへの NULL の挿入。複数行の INSERT ステートメントまたは INSERT INTO ... SELECT ステートメントの場合、このカラムは、そのカラムデータ型の暗黙のデフォルト値に設定されます。これは、数値型では 0、文字列型では空の文字列 ('')、および日付と時間型では「0」の値です。サーバーは SELECT からの結果セットを検査して、それが単一行を返すかどうかを確認しないため、INSERT INTO ... SELECT ステートメントは複数行の挿入と同じ方法で処理されます。(単一行の INSERT の場合は、NULL が NOT NULL カラムに挿入されても警告は発生しません。代わりに、このステートメントがエラーで失敗します。)

MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.2.5 INSERT 構文

明示的な DEFAULT 句のない NOT NULL カラムに対するデータエントリでは、INSERT または REPLACE ステートメントにカラムの値を含まれていない場合、または UPDATE ステートメントがカラムを NULL に設定する場合、MySQL はその時点で有効な SQL モードに従ってカラムを処理します。

(中略)

セクション5.1.7「サーバー SQL モード」を参照してください。

所定のテーブルに対して、SHOW CREATE TABLE ステートメントを使用すると、どのカラムに明示的な DEFAULT 句があるかを確認できます。

暗黙的なデフォルトは次のように定義されます。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 11.6 データ型デフォルト値

厳密モードは、MySQL が INSERT や UPDATE などのデータ変更ステートメントで無効な値または欠落した値を処理する方法を制御します。値はいくつかの理由で無効になることがあります。たとえば、カラムに対して正しくないデータ型を持っていたり、範囲外であったりすることがあります。値の欠落が発生するのは、挿入される新しい行の非 NULL カラムに値が含まれておらず、そのカラムに明示的な DEFAULT 句が定義されていない場合です。(NULL カラムの場合、値が欠落しているときは NULL が挿入されます。)

厳密モードが有効でない場合、MySQL は無効または欠落した値に対して調整された値を挿入し、警告を生成します (セクション13.7.5.41「SHOW WARNINGS 構文」を参照してください)。厳密モードでは、INSERT IGNORE または UPDATE IGNORE を使用すると、この動作を実行できます。

データを変更しない SELECT などのステートメントの場合、厳密モードでは無効な値はエラーでなく警告を生成します。

厳密モードは、外部キー制約が検査されるかどうかに影響されません。foreign_key_checks を検査に使用できます。(セクション5.1.4「サーバーシステム変数」を参照してください。)

MySQL :: MySQL 5.6 リファレンスマニュアル :: 5.1.7 サーバー SQL モード

2017-04-15

Amazon Redshift とは

Amazon Redshift は高速で完全マネージド型、ペタバイト規模のデータウェアハウスです。既存のビジネスインテリジェンスツールを使用して、すべてのデータをシンプルかつコスト効果の高い方法で分析できます。

Amazon Redshift(ビッグデータ活用に適したデータウェアハウス)|AWS

Amazon Redshift, a hosted data warehouse product, forms part of the larger cloud-computing platform Amazon Web Services. It is built on top of technology from the massive parallel processing (MPP) data-warehouse company ParAccel (later acquired by Actian).[1] Redshift differs from Amazon's other hosted database offering, Amazon RDS, in its ability to handle analytics workloads on big data data sets stored by a column-oriented DBMS principle. To be able to handle large scale data sets and database migrations[2] Amazon makes use of massive parallel processing.

Amazon Redshift is based on PostgreSQL 8.0.2. PostgreSQL 9.x includes features not supported in Amazon Redshift. In addition, there are important differences between Amazon Redshift SQL and PostgreSQL 8.0.2.[3] PostgreSQL 8.0.2 was released in 2005 and PostgreSQL has seen massive development since then. Many PostrgreSQL features are not supported[4].

Amazon Redshift - Wikipedia

登壇者の方の話は、このビデオの6:00頃から始まり、Redshiftの元になった製品、Actian Matrixの話は11:45頃あたりになります。表示スライドも下記のブログに掲載されてます。旧製品名は「ParAccel」。

(中略)

NetezzaとRedshiftは、同じエンジニアにより生み出された兄弟だというのです。なんと!そういうことでしたか。

(中略)

Redshiftの名前の由来について調べてみました。

QuoraというQAサイトに投稿がありまして、Redshiftの名前の由来を質問しているのですが、回答が2件ありました。Redshiftの日本語訳は、天文学用語の「赤方偏移」(せきほうへんい)になります。 「赤方偏移」は遠方の銀河からの光が、可視光で言うと赤い方にずれる現象を指します。 これは宇宙が膨張しているために起こると考えられます。 Quotaでの回答の1つは、 AWSは「データウェアハウスの爆発」の意味を込めて「Redshift」の名前を付けたのでは?という回答でした。みなさんはどう思われますか?

Redshiftのルーツを紐解く | Developers.IO

『Matrix』と『Netezza』の開発者はアメリカ人のBarry Zane (バリー・ゼイン) 氏。アメリカトップクラスのカーネギーメロン大学を卒業後、Prime Computer社へ入社。1983年にApplix社に移り、CTOに就任、13年間在籍しました。(Applix社は2007年にCognos社により買収。)

その後、2000年にNetezza社を立ち上げ、PostgeSQLをベースに開発したデータベースアプライアンス製品である『Netezza』を開発しました。『Netezza』は、「エンタープライズ向けDWHアプライアンスとは」を再考して開発され、革新的なアーキテクチャ、サーバーデータベース、ストレージをひとつのマシンに統合することで、大量データの分析を可能にしました。

(中略)

その後、『Netezza』では出来なかった「カラム型かつ、コモディティハードウェアで動作するスケールアウト型のデータベース」を作るため、ParAccel社を立ち上げ、『ParAccel MPP』というデータベースを作りました。(この記事によると、『ParAccel MPP』は『Amazon Redshift』の元となったデータベースとのことです。すごい!) そしてBarry Zane氏、現在はSparql Cityという会社を立ち上げ、Hadoopをベースにしたスケーラブルかつコモディティハードウェアで動作するグラフ分析エンジンを開発しているようです。

Barry Zane氏: Netezzaを作り, ParAccel MPP (Matrix)を作り, 今はグラフ分析エンジンを手がける ビッグデータ分析向けデータベースのスーパーアーキテクト | Insight Technology, Inc.

The company is lead by CEO Barry Zane, former founder and CTO of big data analytics company ParAccel (acquired by Actian in April 2013, creators of the core technology underlying Amazon Redshift). He has a long history in the domains of data management, storage and business intelligence, previously spending 5 years as Cofounder and VP of Architecture at Netezza (acquired by IBM in 2010) and 17 years before that as CTO of Applix (acquired by Cognos in 2007).

no title

Back in July, Data Warehouse vendor ParAccel announced it had a new investor: Amazon. Then yesterday, Amazon announced its new cloud Data Warehouse as a service offering: Redshift. And, none too surprisingly, it turns out that Redshift is based on ParAccel’s technology. I spoke to Rich Ghiossi and John Santaferraro, ParAccel’s VPs of Marketing and Solutions/Product Marketing, respectively, who explained some of the subtleties to me and helped me think through some others.

Amazon Redshift: ParAccel in, costly appliances out | ZDNet


アーキテクチャ

特殊なハードウェアで高速化するのではなく、予め分析に適したデータ構造で格納することで、問合せ時に最低限の仕事量で並列処理することで速くする戦略をとっている。

列指向・圧縮・ゾーンマップ・ソートキーでI/O量を削減し、分散キーを使ってデータを分散配置することで並列処理を可能にしている。

私の パフォーマンスチューニングの三原則で整理すると、以下の通り。

仕事量を減らす
  • 列指向
  • 圧縮
  • ゾーンマップ
  • ソートキー
並列化
  • MPP
  • シェアードナッシング
  • 分散キー
高速化
  • 特殊なハードウェアは使用していない

参考

2017-04-02

「エキスパートはどう考えるか? 体感!パフォーマンスチューニング」@DB Connect 2017

2017/3/8 に開催された Oracle Database Connect 2017 で、「エキスパートはどう考えるか? 体感!パフォーマンスチューニング」というお題で、津島博士(解説)、しばちょう先生(司会)、JPOUGの関口さん、諸橋さん、渡部さん、私(パネラー)でパネルディスカッションしました。

f:id:yohei-a:20170402102956p:image:w640

パフォーマンス・チューニングはデータベースエンジニアの腕の見せ所です。現場で発生したパフォーマンス問題に対して、データベース・エキスパートがどのように分析し、どのような対処策を適応するのか? —— 会場の皆さんもご一緒に考えながら、エキスパートの思考プロセスを体感ください

Oracle Database Connect 2017 | Japan Oracle User Group (JPOUG)

というコンセプトで、AWRレポート、SQL Monitor、iostat などを見ながら2つのケースをリアルタイム分析しました。

ケース1は 第51回 AWRレポートを読むステップ3: オンライン・トランザクションのスループット低下の原因特定 にしばちょう先生が解説記事を書かれています。


以下は Oracle Database Connect 2017 関連のリンクです。

解説記事

資料

togetter(Twitterでのつぶやきまとめ)

発表者のブログ

イベントページ


関連

2016-05-06

Java Mixed-Mode Flame Graphs で Java の CPU ネックをフルスタックで分析する

Brendan Gregg (NETFLIX の Senior Performance Architect) 作の Java Mixed-Mode Flame Graphs を使うと Java のプロセスが CPU ネックのケースで、Java アプリケーションコード、JVM(HotSpot VM)、Linux Kernel のどのレイヤーのどの関数がボトルネックになっているかを簡単に特定することができます。

以下は GitHub - martint/jittest: Demonstrate JIT compiler issue in java 7 のワークロードを実行して Flame Graphs で可視化したものです。

f:id:yohei-a:20160508132640p:image

以下は Java One 2015 での Brendan Gregg のスライドです(YouTube もあります)。

「Brendan Gregg って誰?」「Flame Graphs って何?」という方は以下のエントリをご覧ください。

Flame Graphs は perf(Linux)、SystemTap(Linux)、DTrace(Solaris、Oracle Linux(UEK)、Mac OS X、FreeBSD)、XPerf.exe(Windows) などでのプロファイリング結果を可視化して最も使われているコードパスを早く正確に特定することができます。実体はプロファイリング結果をグラフ(SVG)に変換する Perl スクリプトです。

下から上に行くほどコールスタックが深く、左から関数名のアルファベット順でソートされています。一番上で横幅が広い関数がCPUを長く使っています。


作者の Brendan Gregg は Sun、Oracle、Joyent でカーネル、パフォーマンスのエンジニアとして活躍し、現在は Netflix(北米のインターネットのトラフィックの32.3%を占める。YouTubeは17.1%) のシニア・パフォーマンス・アーキテクトです。ZFS L2ARC や DTrace Toolkit の開発者で、Solaris Performance and Tools、DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD の著者で、LinuxCon、FreeBSD Summit、Oaktable World、AWS re:Invent などのイベントで幅広く活動されています。

perf + Flame Graphs で Linux カーネル内のボトルネックを特定する - ablog

まとめ

  • JDK 8u60 build 19 以降(JDK-8072465 が含まれる)または JDK 9(JDK-8068945 が含まれる) で、
  • -XX:+PreserveFramePointer を指定して Java を実行し、
java -XX:+PreserveFramePointer ...
  • Perf でプロファイリングし、
perf record -F 99 -a -g -- sleep 30
  • perf-map-agent で実行中の Java のプロセスにアタッチして(PIDを指定) JIT コンパイルされたメソッドなどのマッピングを /tmp/perf-<PID>.map に記録し*1
java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar net.virtualvoid.perf.AttachOnce <PID>
chown root /tmp/perf-*.map
  • FlameGraph で SVG にすると、
perf script|stackcollapse-perf.pl|flamegraph.pl --color=java --hash > flamegraph_java.svg
  • Java アプリケーションコード、JVM、Linux Kernel のどのレイヤーのどの関数がCPUを最も使っているか一目でわかる

背景・経緯

サマリ
  • Java Profiler(hprof などは Java のメソッドしかプロファイリングできない) と System Profiler(Perf などは Linux Kernel や HotSpot をプロファイリングできるが Java のメソッドをプロファイリングできない) はカバー範囲が違うため、Java のプロセスの CPU ネックの原因を特定するには Java Profiler と System Profiler の両方を見る必要があった。 以下の2つの問題点に対応し、System Profiler で全範囲をカバーできるようになった。
HotSpot のレジスタの使い方の問題
  • HotSpot(x86_64) は frame pointer register(RBP) を使っているため Perf から Java のコールスタックを取得できなかった(昔は x86 はレジスタが少なかったため RBP を使っていたらしい) 。
  • Brendan Gregg が HotSpot のパッチ(A hotspot patch for stack profiling (frame pointer))を提案し、 Zoltan Majo(Oracle) が書き直して JDK-8068945(JDK 9)JDK-8072465(JDK 8) で OpenJDK に取り込んだ。
  • JDK 8 update 60 build 19 以降、JDK 9 では -XX:+PreserveFramePointer で Perf から Java のスタックを取得できるようになった。
JIT コンパイルされたメソッドのシンボルテーブルの問題
  • JVM が JIT コンパイルしたメソッドは Perf のような System Profiler が使うシンボルテーブルに出ないため JIT コンパイルされたメソッドを取得できない。
  • Johannes Rudolph 作の perf-map-agent で Java のプロセスにアタッチすると取得できる。

必要なソフトウェア


環境セットアップ

Java 8 update 60 build 19 以降をダウンロード
$ cd ~/Downloads/bin
$ tar xfvz jdk-8u102-ea-bin-b04-linux-x64-25_apr_2016.tar.gz 
$ cd jdk1.8.0_102/bin
$ ./java -version
java version "1.8.0_102-ea"
Java(TM) SE Runtime Environment (build 1.8.0_102-ea-b04)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b04, mixed mode)
perf-map-agent をダウンロード・インストール
$ su -
# yum install cmake
# exit
$ cd ~/Documents/github
$ git clone --depth=1 https://github.com/jrudolph/perf-map-agent
$ cd perf-map-agent
$ cmake .
$ make
FlameGraph をダウンロード
$ cd ~/Documents/github
$ git clone --depth=1 https://github.com/brendangregg/FlameGraph

テストケース準備

このテストケースは Flame Graphs とは関係ありません。分析対象として実行する Java コードとして、Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ で紹介されている GitHub - martint/jittest: Demonstrate JIT compiler issue in java 7 を実行するためのセットアップ手順です。

  • maven をダウンロード・インストールする
$ cd ~/Downloads/bin
$ curl -L -O http://ftp.jaist.ac.jp/pub/apache/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz
$ tar xfvz apache-maven-3.3.9-bin.tar.gz
$ mv apache-maven-3.3.9 /opt/
$ cd ~/Documents/github
$ git clone https://github.com/martint/jittest.git
$ cd jittest
$ export PATH=$PATH:/opt/apache-maven-3.3.9/bin
$ mvn install

テストケース実行

$ cd ~/Documents/github/jittest
$ export JAVA_HOME=~/Downloads/bin/jdk1.8.0_102
$ export PATH=~/Downloads/bin/jdk1.8.0_102/bin:$PATH
$ java -XX:+PreserveFramePointer -XX:ReservedCodeCacheSize=20m -XX:InitialCodeCacheSize=20m \
 -jar target/jittest-1.0-SNAPSHOT-standalone.jar > jittest.log &
[1] 9144 ★ PID は 9144
$ head -5 jittest.log
Timestamp	Compilation Time	Code Cache Size	Perm Gen/Metaspace Size	Invocations/s
1462677134771	972	2856960	4895984	27.40
1462677135775	2079	4200320	5560072	54.12
1462677136776	3192	5443200	5965504	75.44
1462677137776	4242	5320640	6329632	93.29
  • perf-map-agent を実行する(テストケース実行中に)
$ cd ~/Documents/github/perf-map-agent
$ java -cp ~/Documents/github/perf-map-agent/out/attach-main.jar:$JAVA_HOME/lib/tools.jar \
 net.virtualvoid.perf.AttachOnce 9144 #9144 は Java の PID

Perf + Flame Graph で可視化する

  • Perf でプロファイリングする(テストケース実行中に)
$ su -
# perf record -F 99 -a -g -- sleep 30
  • Flame Graph で可視化する(perf-map-agent 実行後に実行する)
# chown root /tmp/perf-*.map
# perf script |perl stackcollapse-perf.pl |\
 perl flamegraph.pl --title "OpenJDK 8u102 Build b04, Mixed Mode CPU Flame Graph: green == Java, yellow == C++, red == system"\
 --color=java --hash > flamegraph_java.svg

flamegraph_java.svg が本エントリの冒頭のイメージです(pngに変換しています)。


環境

$ cat /etc/oracle-release 
Oracle Linux Server release 6.6
$ uname -r
2.6.39-400.17.1.el6uek.x86_64
$ java -version
java version "1.8.0_102-ea"
Java(TM) SE Runtime Environment (build 1.8.0_102-ea-b04)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b04, mixed mode)
$ mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T01:41:47+09:00)
Maven home: /opt/apache-maven-3.3.9

補足

Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ で紹介されているコードキャッシュが一杯になった後、JITコンパイラが停まる問題は jdk8、8u20 で修正されています。

The above mentioned issues have been fixed in JDK8 and its updates. Here's the list of the bugs that have been fixed in jdk8 and 8u20 that address these problems:

  • JDK-8006952: CodeCacheFlushing degenerates VM with excessive codecache freelist iteration (fixed in 8)
  • JDK-8012547: Code cache flushing can get stuck without completing reclamation of memory (fixed in 8)
  • JDK-8020151: PSR:PERF Large performance regressions when code cache is filled (fixed in 8)
  • JDK-8029091 Bug in calculation of code cache sweeping interval (fixed in 8u20)
  • 8027593: performance drop with constrained codecache starting with hs25 b111 (fixed in 8)
https://blogs.oracle.com/poonam/entry/why_do_i_get_message

jittest/readme.md at master ? martint/jittest ? GitHub と同じですが、以下検証結果です。


OpenJDK 1.7.0_79 では再現

Code cahce size が約 20MB で頭打ちになりJITコンパイラが停止後、Java バイトコードが毎度ネイティブコードに変換されるようになり秒間実行回数が約40回に落込んでいます。

  • グラフ

f:id:yohei-a:20160508155346p:image:w640

  • テストケース実行手順
$ java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (rhel-2.5.5.3.0.1.el6_6-x86_64 u79-b14)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
$ java -XX:ReservedCodeCacheSize=20m -XX:InitialCodeCacheSize=20m -jar target/jittest-1.0-SNAPSHOT-standalone.jar > jittest_jvm-170_79.log
$ head -5 jittest_jvm-170_79.log 
Timestamp	Compilation Time	Code Cache Size	Perm Gen/Metaspace Size	Invocations/s
1462686065070	984	691840	5126184	35.98
1462686066074	1903	992512	5792376	70.64
1462686067074	3173	1366656	6292584	96.11
1462686068075	4187	1681856	6853904	121.67
$ tail -5 jittest_jvm-170_79.log 
1462686157127	60682	18579200	41666872	38.04
1462686158128	60682	18579200	41745208	38.00
1462686159128	60682	18579200	41834424	37.77
1462686160128	60682	18579200	41921464	38.14
1462686161129	60682	18579200	41999800	37.96
OpenJDK 1.8.0_102 では再現せず

JITコンパイルとコードキャッシュの解放が繰返され Code cache size は約 6〜14MB で推移し、秒間実行回数は約 140〜180 回で安定しています。OpenJDK 1.7.0 でJITコンパイラが停止した時のような実行回数の落込みは発生していません。

  • グラフ

f:id:yohei-a:20160508155343p:image:w640

  • テストケース実行手順
$ java -version
java version "1.8.0_102-ea"
Java(TM) SE Runtime Environment (build 1.8.0_102-ea-b04)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b04, mixed mode)
$ java -XX:ReservedCodeCacheSize=20m -XX:InitialCodeCacheSize=20m  -jar target/jittest-1.0-SNAPSHOT-standalone.jar > jittest_jvm-180_102.log &
$ java -version
java version "1.8.0_102-ea"
Java(TM) SE Runtime Environment (build 1.8.0_102-ea-b04)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b04, mixed mode)
$ head -5 jittest_jvm-180_102.log 
Timestamp	Compilation Time	Code Cache Size	Perm Gen/Metaspace Size	Invocations/s
1462686180191	990	2829824	4927976	24.55
1462686181197	2141	4131136	5538912	46.75
1462686182197	3251	5429952	5981560	68.45
1462686183198	4362	5321984	6334200	83.96
$ tail -5 jittest_jvm-180_102.log 
1462686539498	252194	10859520	9352688	175.20
1462686540498	252985	11689984	9745640	176.36
1462686541500	253685	12466368	10108464	175.21
1462686542500	254356	13176064	10445664	171.86
1462686543500	254793	13567616	10771176	167.98

蛇足

OpenJDK 7u60 の HotSpot VM のコードに https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff の変更を入れてビルドしかけたけど、続きはまた今度に。

# curl -L -O https://www.mercurial-scm.org/release/centos6/RPMS/x86_64/mercurial-3.7.3-1.x86_64.rpm
# rpm -ivh mercurial-3.7.3-1.x86_64.rpm 
$ export LANG=C
$ curl -L -O http://archive.apache.org/dist/ant/binaries/apache-ant-1.7.1-bin.tar.bz2
$ tar xfvj apache-ant-1.7.1-bin.tar.bz2
$ vi ~/.bash_profile
PATH=...:$HOME/Downloads/bin/apache-ant-1.7.1/bin
ANT_HOME=$HOME/Downloads/bin/apache-ant-1.7.1
export ... ANT_HOME
$ source ~/.bash_profile 
$ hg clone http://hg.openjdk.java.net/jdk7u/jdk7u60 jdk7u60
$ cd jdk7u60
$ sh ./get_source.sh
$ unset LD_LIBRARY_PATH
$ make sanity
$ make all

参考


関連

*1:テストケース(Java)を実行したと同じログインセッションで perf-map-agent を実行しないとSolved: Attaching the Java Agent to a Running JVM Process - Community | AppDynamics のエラーが出た