Azure Container Instance のリソースを見てみました #Java

Web+DB Press Vol.106 の Dive to Java (@YaSuenag さん、@sugarlife さん) の記事で、Java 8 なら cgroup のリソース制御が JVM 上から見えない (Java 10 だとリソース制御できる) という情報をみて、Azure (ACI) 上でやってみたくなったのでやってみました。

Container の作成

色々やるので、SSH で繋がるインスタンスを作ります。Docker Hub を探しつつ、こちらのイメージをお借りしました。利用する際の root パスワード等は、リンク先を参照してください。

Azure Cloud Shell 上で、コンテナをデプロイ。

$ az group create --name con01 --location eastus
$ az container create --resource-group con01 --name con01 --image rastasheep/ubuntu-sshd --dns-name-label con01 --ports 22

SSH で接続し、Java 8 をインストールします。

# apt-get update
# apt-get install openjdk-8-jre
# apt-get install openjdk-8-jdk

# java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-0ubuntu0.18.04.1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
# javac -version
javac 1.8.0_181

なお、default-j** でインストールすると、Java 10 が入りました。

# apt-get install default-jre
# apt-get install default-jdk

# java -version
openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.2)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.2, mixed mode)
# javac -version
javac 10.0.2

載っていたサンプルコードをコンパイル。

public class Main {
  public static void main(String[] args){
    Runtime rt = Runtime.getRuntime();
    System.err.format("VERSION : %s%nCPU : %d processors%nHeap : %s%n",
                      System.getProperty("java.version"),
                      rt.availableProcessors(),
                      humanRedable(rt.maxMemory()));
  }

  private static String humanRedable(long bytes){
    int unit = 1024;
    int exp = (int) (Math.log(bytes) / Math.log(unit));
    return String.format("%4.1f %sB",
                         bytes/Math.pow(unit,exp),
                         " KMGTPEZY".charAt(exp));
  }
}

実行すると…

# javac -cp . Main.java
# java -cp . Main
VERSION : 1.8.0_181
CPU : 1 processors
Heap : 464.0 MB

あれ？　1 processors？　なんか予想外。もう少し大き目を想定していたのに。
あ、そうか。コンテナホスト自体が 1 Core なのかしら？

ちょっと /proc/cpuinfo も見てみます。

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
stepping        : 2
microcode       : 0xffffffff
cpu MHz         : 2397.214
cache size      : 30720 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 15
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single kaiser fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips        : 4794.42
clflush size    : 64
cache_alignment : 64
address sizes   : 44 bits physical, 48 bits virtual
power management:

ふむー、１コアですね。ここを見ると、コンテナホスト側で制限も上手くできてしまうようですが、そういう場合は uptime を見ると、コンテナ起動タイミングからのカウントになってるんですかね。

環境では、起動後 15 分くらいの段階で

# cat /proc/uptime
5132.17 4473.34

こんな感じだったので、起動時からカウントされてるわけではなさそうでした。

ということは、もともとのコンテナホストが 1 Core なんでしょうかね。
＃もし考え方が間違っていたら、ご指摘ください

まぁ、ちょっと想像とはちょっと違う結果でしたが、勉強になったので良しとします。