I took a look at the resources of Azure Container Instance

In the article of Dive to Java (@YaSuenag, @sugarlife) of Web + DB Press Vol.106, see the information that the resource control of cgroup is not visible from the JVM in Java 8 (resource control is possible in Java 10). , I wanted to try it on Azure (ACI), so I tried it.

Creating a Container

I will do various things, so I will create an instance that connects with SSH. While looking for Docker Hub, I borrowed the image of here. Please refer to the link for the root password etc. when using it.

Deploy the container on 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

Connect with SSH and install 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

If you install it with default-j **, Java 10 is included.

# 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

Compile the sample code that was included.

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));
  }
}

When you run ...

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

that? 1 processors? Something unexpected. I was expecting it to be a little bigger. Oh yeah. Is the container host itself 1 Core?

Let's take a look at / proc / cpuinfo as well.

# 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:

Hmmm, it's one core. Looking at here, it seems that the restrictions can be set well on the container host side, but in that case, look at uptime. And, is it the count from the container start timing?

In the environment, about 15 minutes after startup

# cat /proc/uptime
5132.17 4473.34

It was like this, so it didn't seem to be counted from the start.

So I wonder if the original container host is 1 Core.

If you think wrong, please point out: bow_tone1:

Well, the result was a little different from what I had imagined, but I'm glad I learned it.