「Java 13のDynamic CDSで想像以上に起動速度が速くなった」を Docker コンテナで試してみた
nowokay.hatenablog.com気になったので自分でも計測してみることにしました。
あと、マルチステージビルドでうまく分離できそうだったので試してみました。
工夫したつもりなのは次のような点。
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 ファイル以外から読み込んだクラス数のパッケージ内訳。
参考リンク
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
途中まで参加してきました。
会場の大さん橋ホールは入り口が洞窟みたいでかっこいい。
途中で護衛艦いずもが入港する様子を目の当たりにした。
一次産業 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)。
内容把握してないけど、こんなタイトルならきっと技術的な内容なんだろう。
メソドロジストやアナリストだと思ってたので意外な気持ち。
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-Json
に json の配列を入力しても後ろのパイプラインにはそれぞれの要素が渡らない、というところにちょっとはまった。
$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 必要なのか…
リソースとサイジングについては、ボトムアップな計算と検証をやっていかなければ。