「Java 13のDynamic CDSで想像以上に起動速度が速くなった」を Docker コンテナで試してみた

nowokay.hatenablog.com気になったので自分でも計測してみることにしました。

あと、マルチステージビルドでうまく分離できそうだったので試してみました。

 

java dynaimc cds in container

工夫したつもりなのは次のような点。

3ステージで構成

Micronaut のスケルトンプロジェクトをビルドするためのステージ。
mn を使うために SDKMAN をインストールしてるのは結構ムダだと思う。

クラスアーカイブを生成するためのステージ。
ケルトンプロジェクトはサーバーアプリなので、起動することが確認できたら停止するために timeout コマンドを利用してる。

実行用のステージ。
ENTRYPOINT に timeout コマンドを指定するのはすぐに停止したいから。
CMD に jar ファイルを実行するコマンドを指定しているので、環境変数 JAVA_OPTS を変更すれば振る舞いを変更できる。

java.base の AOT はかなりリソースを使用する

何回か試したけど docker build の環境では OutOfMemoryError の発生を回避できませんでした。どうやら Java ヒープに 4 GB くらい必要な模様。
PCで実行したときは成功したけどできた so ファイルは 1 GB 近くなっており、コンテナイメージに含めるべきではないと思った。

[JDK-8176141] [AOT] jaotc compilation of java.base module hangs sometimes - Java Bug System

[JDK-8175214] [AOT] OOM compiling jdk.internal.module.SystemModules.descriptors() - Java Bug System

計測結果

| パターン | JVM | Micronaut |
| NoCDS | 257.3 | 2927.2 |
| DefaultCDS | 230.9 | 2967.6 |
| DynamicCDS | 230.9 | 3162.1 |

元記事とは違い、どの構成でも変化は見られなかった。なんでだろう。

調査

JVM log で読み込んだクラスと読み込み元を集計するとなんだか不穏な感じ。

まったく効いてないわけじゃないみたい。

 

読み込み元
jar ファイル以外 3157
jar ファイル 2409

jar ファイル以外から読み込んだクラス数のパッケージ内訳。

パッケージ名 クラス数
io.micronaut 942
java.util 473
java.lang 319
jdk.internal 191
ch.qos 176
com.fasterxml 148
com.sun 137
org.yaml 114
sun.util 68
sun.nio 67
 
jar ファイルから読み込んだクラス数のパッケージ内訳。
パッケージ名 クラス数
io.micronaut 826
io.reactivex 456
io.netty 340
com.fasterxml 279
java.lang 108
java.util 82
ch.qos 65
java.nio 36
org.yaml 24
sun.nio 22
 

 

 

参考リンク

sudo で実行するコマンドに環境変数を指定したい

背景

たいていの場合は必要最小限の環境変数しか設定されないことになっています。

https://www.sudo.ws/man/1.8.13/sudoers.man.html

Command environment

By default, the env_reset option is enabled. This causes commands to be executed with a new, minimal environment.

普段は docker の接続先を環境変数で制御してるので、 sudo docker すると接続先を見つけられなくなってしまいました。

sudo docker version
Client: Docker Engine - Community
 Version:           19.03.3
 API version:       1.40
 Go version:        go1.12.10
 Git commit:        a872fc2f86
 Built:             Tue Oct  8 00:59:36 2019
 OS/Arch:           linux/amd64
 Experimental:      false
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

解決方法

普通にコマンドを実行するときのように環境変数を指定するだけでした。

sudo $(env | grep DOCKER | tr '\n' ' ') docker version
Client: Docker Engine - Community
 Version:           19.03.3
 API version:       1.39 (downgraded from 1.40)
 Go version:        go1.12.10
 Git commit:        a872fc2f86
 Built:             Tue Oct  8 00:59:36 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.9
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11.13
  Git commit:       039a7df9ba
  Built:            Wed Sep  4 16:55:50 2019
  OS/Arch:          linux/amd64
  Experimental:     false

アンケートや投票のためのWebサービス

機能より体験が重要そうな印象。 いずれも有料プランが用意されていることから、簡単そうで難しい領域なんだと思う。

Live!アンケート | 無料でカンタン!リアルタイムアンケート! |

  • CROSS Party 2019 で使われていました。
  • アンケートできるし、質問の投稿、質問への fav ができる。
  • 日本語だし QR コードでアクセスできるのは敷居が低そう。

Slido - Audience Interaction Made Easy

  • 最近の DevLOVE イベントでよく使われていました。
  • 質問の投稿、質問への fav ができる。
  • URL を共有してパスコード?でアクセスするのは便利。
  • 初めは読み方が分からなかった(スリドー?)

Interactive presentation software - Mentimeter

  • Red Hat Tech Night で使われていました。
  • アンケートできる。
  • リアルタイム集計と可視化機能がすごかった印象。
  • やはり URL を共有してパスコード?でアクセスするのは便利。

CROSS Party 2019

途中まで参加してきました。

 

会場の大さん橋ホールは入り口が洞窟みたいでかっこいい。

f:id:yujiorama:20191006141610j:image

途中で護衛艦いずもが入港する様子を目の当たりにした。

f:id:yujiorama:20191006144939j:image

 

一次産業 x IT の事業者トップが語る今 (11:20- @大会場) | CROSS Party 2019

一次産業向けにプロダクトを提供してる企業によるパネルディスカッション。

一次産業(農・林・水)は産業従事者の高齢化や人口減少が止まらないのに、需要はあまり減らないという厳しい状況。まるでSI業界みたい。

IT技術があまり浸透していない領域のため、新しいチャレンジだらけだし、何をしてもイノベーションになる、という捉え方が印象的。

一部を除いて、国や自治体の支援がない限り新しい取り組みを始めるのは難しいんだろうな…

 

[基調講演] 夢を形にする技術 〜 大規模開発におけるサイエンスとエンジニアリングの境界を科学する (14:10- @大会場) | CROSS Party 2019

はやぶさプロジェクトを立ち上げ、プロジェクトマネージャーを務めた川口淳一郎さんと、及川卓也さんのパネルディスカッション。

やりたいと思ったことを実現するために必要なことはなんでもやる、という信念の話。

企画を否定されるポイントを回避するため、アポなしでNASAに乗り込み交渉してくる、という経験談はヤバかった。

コンセプトを考えてから資料カプセルの回収まで35年かかっている。最初から最後まで参加し続けた人もいるけど、途中参加の人たちは徒弟制度のような体制でプロジェクトの知識や技術を身に付けていったとか。

予想外の問題が発生しても、必ず解決するという意志を示すことが重要。

緊急企画!漫画村再検証! (15:50- @大会場) | CROSS Party 2019

まとまってた。

検察やマスコミや出版業界団体や一部セキュリティベンダーがどうしようもないことは分かった。

一ソフトウェア開発者に出来ることと言えば、自分の周囲に働きかけることや、日本ハッカー協会の活動を支援(寄付 - 一般社団法人日本ハッカー協会)することかなぁ。

 

Running Serverless という本が出てた

SBE のゴジコ・アジックさん、こんな本書いてたんだ(2019-06)。

内容把握してないけど、こんなタイトルならきっと技術的な内容なんだろう。

メソドロジストやアナリストだと思ってたので意外な気持ち。

 

Running Serverless: Introduction to AWS Lambda and the Serverless Application Model (English Edition)

Running Serverless: Introduction to AWS Lambda and the Serverless Application Model (English Edition)

 

 

Windows 10 1903 にアップグレードしたら AppData\Roaming\Microsoft\Windows\Start\ Menu\Programs\Scoop\ Aps が空になった

Scoop で管理してるアプリケーションの Windows ショートカットが全滅した・・・

scoop update -f するのもだいぶ時間がかかりそうなのでショートカットだけを復旧する。

たまたま別の PC をほとんど同じ状態に構成してたので、Windows ショートカットを作るのに必要な情報を抽出。

dir -Path '.\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Scoop Apps\' -Recurse -Filter *.lnk `
| % { (New-Object -ComObject WScript.Shell).CreateShortcut($_.FullName) } `
| ConvertTo-Json > apps.json

apps.json を今の PC に移動して Windows ショートカットを作成。

ConvertFrom-Jsonjson の配列を入力しても後ろのパイプラインにはそれぞれの要素が渡らない、というところにちょっとはまった。

$WshShell = New-Object -ComObject WScript.Shell
$apps = Get-Content -Path apps.json | ConvertFrom-Json
$apps `
| ? { (Test-Path -Path $_.TargetPath) -and (Test-Path -Path $_.WorkingDirectory) } `
| % { `
    $Shortcut = $WshShell.CreateShortcut($_.FullName)
    $Shortcut.TargetPath = $_.TargetPath             
    $Shortcut.Arguments = $_.Arguments               
    $Shortcut.IconLocation = $_.IconLocation         
    $Shortcut.Description = $_.Description           
    $Shortcut.WorkingDirectory = $_.WorkingDirectory
    $Shortcut.Save()
}

参考

コンテナオーケストレーションと JVM アプリケーション

問題意識

特に fork-join は CPU コア数で動き方が変わってしまう(と思ってる)。

しかし、 `requesrs.cpu` の割り当てを増やすにはワーカーノードをスケールアップする必要がある。

そうすると利用料も高くなる…

 

スケールアップした専用ワーカーノードを用意して nodeSelector を指定すればいいのかもしれない。

でも、それは VM で運用するのと変わらないのでは…

 

コンテナオーケストレーションVMの判断基準は、運用コストの削減、リソース利用効率の改善あたりになるのかなぁ。

 

現実解

仕事でコンテナオーケストレーションを活用してる方に聞いてみたら、ノードのメモリ32GiBは当たり前、ということだった。

こんな資料もありました。hbstudy のセッション資料らしい。

https://nekop.github.io/slides/hbstudy78.html/#8

etcd で 16 GiB 必要なのか…

 

リソースとサイジングについては、ボトムアップな計算と検証をやっていかなければ。