The post Blog moved to https://gamlor.info first appeared on Gamlor.

OK!

Win+Space=OK

However, when I started to type the IBus icon suddenly changed and it wrote in English. I didn’t know that icon and it seemed strange. There was no error message. IBus just always switched to that icon and then wrote in the English alphabet.

What is this?

Well, first I searched the Internet without success. I found only old entries which did no help. So, maybe there are logs? I couldn’t find any IBus log in /var/logs or something like that. However, the IBus man page told about a –verbose flag. So, I used that and tada, there were error messages:

[gamlor@gamlor-t470p ~]$ ibus-daemon --verbose -r &
[4] 13270
[gamlor@gamlor-t470p ~]$ 
(ibus-daemon:13170): GLib-WARNING **: 21:33:08.140: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). See the documentation of g_child_watch_source_new() for possible causes.
(ibus-engine-hangul:13296): IBUS-WARNING **: 21:33:08.224: org.freedesktop.IBus.Config.GetValue: GDBus.Error:org.freedesktop.DBus.Error.Failed: Config value [engine/hangul:on-keys] does not exist.
(ibus-engine-hangul:13296): IBUS-WARNING **: 21:33:08.224: org.freedesktop.IBus.Config.GetValue: GDBus.Error:org.freedesktop.DBus.Error.Failed: Config value [engine/hangul:off-keys] does not exist.
(ibus-daemon:13270): GLib-CRITICAL **: 21:33:08.229: g_variant_unref: assertion 'value != NULL' failed
(ibus-ui-gtk3:13277): IBUS-WARNING **: 21:33:13.143: ibus_bus_call_sync: org.freedesktop.DBus.Properties.Get: GDBus.Error:org.freedesktop.DBus.Error.Failed: No global engine.

Oh…’assert failed’ doesn’t sound good. And whenever I tried to write Korean, the `bus_bus_call_sync…No global engine` message got printed. So I searched for that error message and found this Github issue. There is a work around: When configuring an Emoji selection key, the issue goes away. Strange. So, I did that and everything worked again. Here’s how: IBus Preference -> Emoji -> … Button -> Select a impossible key combination -> Add -> Done!

Work around

The end

The post Korean Hangul Stopped Working After IBus Update to 1.5.18? A Work Around. first appeared on Gamlor.

OK!

Win+Space=OK

하지만, 쓰기 시작할 떼 IBus의 아이콘이 갑자기 바꿨고 영어로 썼어요. 제거 그 아이콘을 몰랐어서 이상하는 것 같아요. 에러 메시지도 없어요. IBus가 그냥 항상 그 아이콘 보여주고 영어로 썼어요 =(

이것 뭐예요?

그럼 제가 먼지 이 문제를 인터넷으로 검색했고 아무것도 못 찾아요. 그냥 오래된 못 도웠어요. 그럼 아마 오류 로그가 있어요? /var/log에 IBus의 로그가 없어요. 근데 man 페이지에 –verbose 명령 행을 찾았고 사용하면 오류 로그 있어요:

[gamlor@gamlor-t470p ~]$ ibus-daemon --verbose -r &
[4] 13270
[gamlor@gamlor-t470p ~]$ 
(ibus-daemon:13170): GLib-WARNING **: 21:33:08.140: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). See the documentation of g_child_watch_source_new() for possible causes.
(ibus-engine-hangul:13296): IBUS-WARNING **: 21:33:08.224: org.freedesktop.IBus.Config.GetValue: GDBus.Error:org.freedesktop.DBus.Error.Failed: Config value [engine/hangul:on-keys] does not exist.
(ibus-engine-hangul:13296): IBUS-WARNING **: 21:33:08.224: org.freedesktop.IBus.Config.GetValue: GDBus.Error:org.freedesktop.DBus.Error.Failed: Config value [engine/hangul:off-keys] does not exist.
(ibus-daemon:13270): GLib-CRITICAL **: 21:33:08.229: g_variant_unref: assertion 'value != NULL' failed
(ibus-ui-gtk3:13277): IBUS-WARNING **: 21:33:13.143: ibus_bus_call_sync: org.freedesktop.DBus.Properties.Get: GDBus.Error:org.freedesktop.DBus.Error.Failed: No global engine.

어머…assert failed다로 진짜 안 좋아요. 근데 제가 한글 써보면 `bus_bus_call_sync…No global engine` 항상 났어요. 그래서 제가 이 오류를 검색했고 이 GitHub 문제 글 찾았어요. 저기에 임시 해결이 있어요: 에모지의 선택 키를 설정하면 문제 멈출 것 예요. 이상해지? 그럼 제가 그렇게 했고 다 다시 작동했어요. 방법이에요: IBus Preference -> Emoji -> … 버튼 -> 제가 불가능한 키를 설정했어요 -> Add -> 완료됐어요!

임시 해결

끝 =)

The post IBus 1.5.18 업데이트 후에는 한글 멈췄어요? 임시 해결이 있어요. first appeared on Gamlor.

ADBCJ will be fine ^.^

ADBCJ in JCenter

Finally, ADBCJ is in a decent Maven repository! That is a long standing to do crossed of the list. First, you’ll need to add JCenter to your projects maven repos. Unless your build tool has the JCenter by default.
For Maven:

<repository>
 <snapshots>
 <enabled>false</enabled>
 </snapshots>
 <id>central</id>
 <name>bintray</name>
 <url>https://jcenter.bintray.com</url>
</repository>

After than you include ADBCJ as a dependency.

MySQL driver:

<dependency>
    <groupId>org.adbcj</groupId>
    <artifactId>adbcj-api</artifactId>
    <version>0.9</version>
</dependency>
<dependency>
    <groupId>org.adbcj</groupId>
    <artifactId>mysql-async-driver</artifactId>
    <version>0.9</version>
</dependency>

H2 driver:

<dependency>
    <groupId>org.adbcj</groupId>
    <artifactId>adbcj-api</artifactId>
    <version>0.9</version>
</dependency>
<dependency>
    <groupId>org.adbcj</groupId>
    <artifactId>h2-async-driver</artifactId>
    <version>0.9</version>
</dependency>

Changes</h2

Java 8

Recent ADBCJ versions requires Java 8. Instead of ADBCJ’s own future implementations, methods now return Java 8’s completable futures =).

Callback API

Java 8’s futures are not every bodies taste. Especially other JVM language have their own futures and concurrency constructs. Or you might really do not want a future based control flow. So, I changed ADBCJ’s basic API to be callback driven. That allows to use other concurrency constructs without going through Java futures as intermediate step. The Java 8 completable future methods are also implemented in term of these futures.

Examples on Github

Examples how to use ADBCJ are on GitHub.

The post Async Database Connector for Java (ADBCJ) on JCenter. first appeared on Gamlor.

Start

First sign up on edgemesh.com. Then embed this script into your website:

<script
    type="application/javascript"
    src="https://sig.edgeno.de/edgemesh.client.min.js"
    onload="window.edgemesh = new Edgemesh()">
</script>

Done. Really!

So, how does Edgemesh work?

A normal CDN has tons of servers all over the world. Those server caches your images, CSS and Javascript. So, visitors can download your content quickly from a close CDN server. However, if there is no CDN server in your visitors area, they won`t benefit from quick downloads. And CDN servers are not free!

Classic CDN

Edgemesh

Does it work?

Yes. This blog has close to no visitors, yet Edgemesh manages to store and distribute some content:

This sites Edgemesh network

The post Need a CDN? Try out edgemesh.com. first appeared on Gamlor.

시작

먼저 edgemesh.com에 회원가입해야 되고 당신의 웹사이트 이 JavaScript를 추가해요:

<script
    type="application/javascript"
    src="https://sig.edgeno.de/edgemesh.client.min.js"
    onload="window.edgemesh = new Edgemesh()">
</script>

완전했어요. 진짜요!

그럼, edgemesh 어떻게 작동해요?

보통 CDN는 세상 각국에 많은 서버를 가지고 있어요. 이 서버는 당신의 웹 사진과 CSS과 Javascript 캐싱해요. 그래서 고객들이 가까운 CDN 서버에서 콘텐츠를 발리 다운 받아요. 근데 고객의 나라에 CDN 서버 없으면 CDN 가속 하지 않아요. 그리고 이 서버들이 무료 아니에요.

보통 CDN

Edgemesh는 작동 달라요. 요즘에 우리 핸드폰과 컴퓨터는 진짜 빨라요. 그리고 우리 웹 브라우저도 강력해요. 브라우저가 Indexed DB로 데이터베이스이고 WebRTC로 P2P 네트워크 할 수 있어요. 그래서 Edgemesh 이곳을 사용해요! 고객이 웹 사이트를 보면 Edgemesh가 브라우저에 콘텐츠를 저장해요. 그리고 다른 가까운 고객 도 같은 콘텐츠를 필요하면 고객의 브라우저한테서 다운 받을 거예요.
그래서 많은 고객 있으면 콘텐츠 빨리 다운 받을 수 있어요.

Edgemesh

근데 우리는 고객의 인터넷 연결을 잘 안 믿어요! 아마 진짜 느리고 아마 갑자기 연결 꺼요! 그래서 Edgemesh 프리 페치 (prefetch) 하고 연결 느리면 그냥 보통 다운 받을 거예요. 그리고 아직 CDN 서버 사용할 수 있어요. Edgemesh의 ‘Supernode’는 조금 보통 CDN 서버 같아요. 그리고 Edgemesh는 다른 CDN 결합할 수 있어요.

진짜 작동해요?

예! 이 블로그는 방문객이 별로 없어요. 근데 edgemesh로 아직 콘텐츠를 세상 각국에 저장하고 배달해요:

이 블로그의 Edgemesh P2P 네트워크

그냥 당신의 웹 사이트에 사용해보세요 =)

The post CDN 필요하면 edgemesh.com 사용해보세요 first appeared on Gamlor.

./produces-some-log.sh 2>&1 > log-of-my-script.log

Do you have time stamps on those logs?
If not, it is trivial to add. You just have to pipe the log through a time stamp tool.

Timestamp your lines

Linux: ts

On most Linux distros there the `ts` tool. If it is not installed, it is usually in the ‘moreutils’ package. So get it via `apt-get`, `yum`, `pacman` or whatever you`re distro uses.

Then, pipe the output through `ts`:

[gamlor@gamlor-manjaro log-util]$ ./produces-some-log.sh 2>&1                                          
We are making progress. We are at step 1/5         
And some other info about the system:  13:39:24 up 2:10, 2 users, load average: 1.44, 1.74, 1.76       
We are making progress. We are at step 2/5         
And some other info about the system:  13:39:25 up 2:10, 2 users, load average: 1.44, 1.74, 1.76       
We are making progress. We are at step 3/5         
....

Will become:

[gamlor@gamlor-manjaro log-util]$ ./produces-some-log.sh 2>&1 | ts                                     
Sep 25 13:39:30 We are making progress. We are at step 1/5                                             
Sep 25 13:39:30 And some other info about the system:  13:39:30 up 2:10, 2 users, load average: 1.65, 1.78, 1.77                                                                                               
Sep 25 13:39:31 We are making progress. We are at step 2/5                                             
Sep 25 13:39:31 And some other info about the system:  13:39:31 up 2:10, 2 users, load average: 1.65, 1.78, 1.77                                                                                               
Sep 25 13:39:31 We are making progress. We are at step 3/5                                             
...          

You can specify a date format string to have more clear format:

[gamlor@gamlor-manjaro log-util]$ ./produces-some-log.sh 2>&1 | ts '%Y-%m-%dT%T%z'
2017-09-25T22:47:25+0900 We are making progress. We are at step 1/5
2017-09-25T22:47:25+0900 And some other info about the system:  22:47:25 up 2:18, 2 users, load average: 1.25, 1.29, 1.53
2017-09-25T22:47:26+0900 We are making progress. We are at step 2/5
2017-09-25T22:47:26+0900 And some other info about the system:  22:47:26 up 2:18, 2 users, load average: 1.25, 1.29, 1.53
...

Last, I recommend using the UTC time zone, to avoid confusion. Expecially when your servers are all over the world. Or you need to cross reference time stamps with other logs.
If your server isn`t set to UTC, you can set the `TZ` enviroment variable:

[gamlor@gamlor-manjaro log-util]$ export TZ=UTC
[gamlor@gamlor-manjaro log-util]$ ./produces-some-log.sh 2>&1 | ts '%Y-%m-%dT%T%z'
2017-09-25T13:49:54+0000 We are making progress. We are at step 1/5
2017-09-25T13:49:54+0000 And some other info about the system:  13:49:54 up 2:21, 2 users, load average: 0.66, 1.13, 1.44
2017-09-25T13:49:55+0000 We are making progress. We are at step 2/5
...

For more details, check the man pages.

For all Unix-like systems, AWK to the rescue!

BSD, illumos or some other Unix like system? Maybe there no `ts` util around? Good old awk has got you covered. On each line, print the date, then the rest of the line.

This method is more portable. AWK is installed most systems. So, if you plan do distribute your script, this is the way to go.

[gamlor@gamlor-manjaro log-util]$ ./produces-some-log.sh 2>&1 | awk '{ print strftime("%Y-%m-%dT%T%z"), $0;  }'                                                                                                     
2017-09-25T22:57:54+0900 We are making progress. We are at step 1/5                                    
2017-09-25T22:57:54+0900 And some other info about the system:  22:57:54 up 2:29, 2 users, load average: 1.29, 1.23, 1.39                                                                                      
2017-09-25T22:57:55+0900 We are making progress. We are at step 2/5                                    
...

Again, I recommend using UTC. Your server probably already uses UTC anyway:

[gamlor@gamlor-manjaro log-util]$ export TZ=UTC    
[gamlor@gamlor-manjaro log-util]$ ./produces-some-log.sh 2>&1 | awk '{ print strftime("%Y-%m-%dT%T%z"), $0;  }'                                                                                                     
2017-09-25T13:59:23+0000 We are making progress. We are at step 1/5                                    
2017-09-25T13:59:23+0000 And some other info about the system:  13:59:23 up 2:30, 2 users, load average: 1.09, 1.15, 1.35                                                                                      
2017-09-25T13:59:24+0000 We are making progress. We are at step 2/5                                    
...                                  

That`s it =).
Thanks for the Stackoverflow answers, which include both solutions.

The post Adding Timestamp to Logs first appeared on Gamlor.

Well easy, a quick grep for TypeInfo[] array. Nothing. Ah, quick grep for TypeInfo collections. Nothing! Huh? Where the hell do I allocate the array then?
Ok, more profiling! So, I enabled flight recorder with ‘-XX:+UnlockCommercialFeatures -XX:+FlightRecorder’. Then did a recording with Java Mission Control, capturing the allocation stack traces:

Ok, the TypeInfo.values() method allocates the memory. TypeInfo is a enum, and I’m using the built in values() method. The code looked something like this:

package info.gamlor.blog;

import java.util.ArrayList;
import java.util.List;
import java.util.Random;

enum TypeInfo {
    UNKNOWN(0),
    INT(1),
    STRING(2);

    private final int id;

    TypeInfo(int id) {
        this.id = id;
    }

    public static TypeInfo findType(int type){
        for (TypeInfo t : values()){
            if(t.id == type){
                return t;
            }
        }
        return UNKNOWN;
    }
}

public class Main {
    private static Random rnd = new Random();

    public static void main(String[] args) throws Exception {
        List<TypeInfo> parsedData = new ArrayList<>();
        for (int i = 0; i < 1000000000; i++) {
            int idParsedFromWire = readTypeIdFromData(rnd);

            TypeInfo type = TypeInfo.findType(idParsedFromWire);

            // Pretend we use the type for the exampe
            parsedData.add(type);
            consumeData(parsedData);
        }
        System.out.println(parsedData.size());
    }

    private static void consumeData(List<TypeInfo> parsedData) {
        // Parsed data is consumed
        if(rnd.nextBoolean()){
            parsedData.clear();
        }
    }

    private static int readTypeIdFromData(Random rnd) throws InterruptedException {
        // Data comes from the wire....let's run this example a bit slower
        int idParsedFromWire = rnd.nextInt(16);
        Thread.yield();
        return idParsedFromWire;
    }
}

Do you see the allocation? Why should it allocate that many arrays? The Enum values are constant, so it should be able to initialize an array once?
Ok, let’s take a closer look and decompile the class file:

javap -c TypeInfo.class | grep -A 10 values

And we get:

  public static info.gamlor.blog.TypeInfo[] values();
    Code:
       0: getstatic     #1                  // Field $VALUES:[Linfo/gamlor/blog/TypeInfo;
       3: invokevirtual #2                  // Method "[Linfo/gamlor/blog/TypeInfo;".clone:()Ljava/lang/Object;
       6: checkcast     #3                  // class "[Linfo/gamlor/blog/TypeInfo;"
       9: areturn

As we can see, it deferences a static array of the Enum values. Then it clones that array before returning it, causing an array allocation. Why does it do that? It is a defensive copy:
Java’s arrays are a mutable. If values() just returns the reference to the original array, then some code might change the array’s content. That creates havoc, since it would change what Enum.values() returns. Therefore, the defensive copy.

Safety First, Copy It

So, after seeing this, it is easy to fix our code. We call Enum.values() once, cache the array and use it for the parsing:

// Enum.values() does a defensive copy and allocates an array on each call
// To avoid that allocation, we call values() only once
private static final TypeInfo[] ALL_VALUES = values();

public static TypeInfo findType(int type){
    for (TypeInfo t : ALL_VALUES){
        if(t.id == type){
            return t;
        }
    }
    return UNKNOWN;
}

Et voila, the allocations are gone =)

The post Java’s Enum.values() Hidden Allocations first appeared on Gamlor.

Chrome & JVM eat memory generously

Web App Example

The web app is just a ‘Hello World’ app. For better explaination, it also consumes tons of memory. I created the example in Scala, but the other JVM languages have the same issue. The source code for the example is here.

/** 
 * Snippet, memory limits 
 */
// Limit the amount of items in memory for this example.
// So, max ~192*256k=48MBytes
val maxMemoryItems = 192
val memoryPerItem = 256 * 1024
val memoryWasting = new ArrayBlockingQueue[Array[Byte]](maxMemoryItems)

/** 
 * Snippet, request handling
 */
// On each request, consume some memory.
// And keep things in memory to simulate memory use
case "/" :: Nil => {
    // On each request, consume some memory.
    // And keep things in memory to simulate memory use
    val chunkOfMemory = Array.ofDim[Byte](memoryPerItem)
    var addedToQueue = memoryWasting.offer(chunkOfMemory)

    // Throw things away until we've space
    while (!addedToQueue) {
        memoryWasting.poll()
        addedToQueue = memoryWasting.offer(chunkOfMemory)
    }

    val createdSoFar = createdItemsCounter.incrementAndGet()
    response.getWriter.write(
        s"""
            |{
            |"title":"Hello World! Let's use some memory",
            |"created-overall":"$createdSoFar",
            |"queue-size":"${memoryWasting.size()}",
            |"":"Hello. I'm so memory hungry. kthxbye!"
            |}
        """.stripMargin)
}

First Issue: Program Dies

The Triton instance won`t expirience any issue. But the plain Docker instance (Linux 4.10, Docker 17.04) suddenly stops working. =( The program got killed.

[root@gamlor-manjaro useless-demo-service]# docker run -m 128m --cpus 0.065 -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:1
2017-04-20 12:58:20.248:INFO::main: Logging initialized @5900ms to org.eclipse.jetty.util.log.StdErrLog
2017-04-20 12:58:23.348:INFO:oejs.Server:main: jetty-9.4.z-SNAPSHOT
2017-04-20 12:58:30.650:INFO:oejs.AbstractConnector:main: Started ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2017-04-20 12:58:30.748:INFO:oejs.Server:main: Started @16602ms
Killed

The penguin and whale are dangerous. Be careful!

So Many Threads

Now, we configured the memory properly. However, there maybe more things we can configure properly? So, let`s see what threads are runing in the container with `jstack`:

##
# Local docker run 
##
# Run second version of our container
sudo docker run -d -m 128m --cpus 0.065 --name=jvm-on-small-container -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:2
# List the threads running
sudo docker exec jvm-on-small-container sh -c 'jstack `pgrep java`' | grep os_prio 
"qtp791452441-23" #23 prio=5 os_prio=0 tid=0x000056473bc03800 nid=0x42 waiting on condition [0x00007fefe4931000]
"Attach Listener" #22 daemon prio=9 os_prio=0 tid=0x000056473bf72800 nid=0x41 waiting on condition [0x0000000000000000]
"DestroyJavaVM" #21 prio=5 os_prio=0 tid=0x000056473bcd1800 nid=0x8 waiting on condition [0x0000000000000000]
"qtp791452441-19-acceptor-0@27b0949f-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #19 prio=3 os_prio=0 tid=0x000056473bf75000 nid=0x24 runnable [0x00007fefe4b33000]
"qtp791452441-17" #17 prio=5 os_prio=0 tid=0x000056473bc2d800 nid=0x22 runnable [0x00007fefe8160000]
"qtp791452441-16" #16 prio=5 os_prio=0 tid=0x000056473bc2b000 nid=0x21 runnable [0x00007fefe8261000]
"qtp791452441-15-lowPrioritySelector" #15 prio=1 os_prio=0 tid=0x000056473bc29000 nid=0x20 waiting for monitor entry [0x00007fefe8363000]
"qtp791452441-14-lowPrioritySelector" #14 prio=1 os_prio=0 tid=0x000056473bc8c000 nid=0x1f waiting for monitor entry [0x00007fefe8464000]
"qtp791452441-13-lowPrioritySelector" #13 prio=1 os_prio=0 tid=0x000056473bc8a000 nid=0x1e waiting for monitor entry [0x00007fefe8565000]
"qtp791452441-12-lowPrioritySelector" #12 prio=1 os_prio=0 tid=0x000056473bc86800 nid=0x1d waiting for monitor entry [0x00007fefe8666000]
"qtp791452441-11" #11 prio=5 os_prio=0 tid=0x000056473bd8a800 nid=0x1c runnable [0x00007fefe8766000]
"qtp791452441-10" #10 prio=5 os_prio=0 tid=0x000056473bd84800 nid=0x1b runnable [0x00007fefe8867000]
"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x000056473bc63800 nid=0x19 runnable [0x0000000000000000]
"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x000056473bc14000 nid=0x18 waiting on condition [0x0000000000000000]
"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x000056473bbf9000 nid=0x17 waiting on condition [0x0000000000000000]
"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x000056473bbea000 nid=0x16 waiting on condition [0x0000000000000000]
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x000056473bbe7000 nid=0x15 waiting on condition [0x0000000000000000]
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x000056473bbe4800 nid=0x14 runnable [0x0000000000000000]
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x000056473bbb5000 nid=0x13 in Object.wait() [0x00007fefe92cb000]
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x000056473bbb2000 nid=0x12 in Object.wait() [0x00007fefe93cc000]
"VM Thread" os_prio=0 tid=0x000056473bba8000 nid=0x11 runnable 
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000056473b9f0000 nid=0x9 runnable 
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000056473b9f2000 nid=0xa runnable 
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000056473b9f3800 nid=0xb runnable 
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000056473b9f5800 nid=0xc runnable 
"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x000056473b9f7000 nid=0xd runnable 
"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x000056473b9f9000 nid=0xe runnable 
"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x000056473b9fa800 nid=0xf runnable 
"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x000056473b9fc800 nid=0x10 runnable 
"VM Periodic Task Thread" os_prio=0 tid=0x000056473bc59800 nid=0x1a waiting on condition

##
# Joyent Triton run
##
# Run second version of our container
eval "$(triton env)"
docker run -d -m 128m --name=jvm-on-small-container -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:2
# List the threads running
docker exec jvm-on-small-container sh -c 'jstack `pgrep java`' | grep os_prio 
"qtp791452441-44" #44 prio=5 os_prio=0 tid=0x000000000215e000 nid=0x12de4 runnable [0x00007fffe51f7000]
"qtp791452441-43" #43 prio=5 os_prio=0 tid=0x0000000000262000 nid=0x12aa4 waiting for monitor entry [0x00007fffe52fa000]
"qtp791452441-42" #42 prio=5 os_prio=0 tid=0x000000000068a000 nid=0x11808 waiting on condition [0x00007fffe7c7a000]
"Scheduler-1896277646" #41 prio=5 os_prio=0 tid=0x0000000000145000 nid=0x1176f waiting on condition [0x00007fffe4e34000]
"Attach Listener" #39 daemon prio=9 os_prio=0 tid=0x0000000000717800 nid=0x116e2 waiting on condition [0x0000000000000000]
"DestroyJavaVM" #33 prio=5 os_prio=0 tid=0x0000000000716000 nid=0x10796 waiting on condition [0x0000000000000000]
"qtp791452441-32-acceptor-3@6dbc83d8-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #32 prio=3 os_prio=0 tid=0x0000000000714800 nid=0x1082a runnable [0x00007fffe5cff000]
"qtp791452441-31-acceptor-2@1ac08473-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #31 prio=3 os_prio=0 tid=0x0000000000713000 nid=0x10829 waiting for monitor entry [0x00007fffe6000000]
"qtp791452441-30-acceptor-1@34228b2c-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #30 prio=3 os_prio=0 tid=0x000000000070d800 nid=0x10828 waiting for monitor entry [0x00007fffe67fe000]
"qtp791452441-29-acceptor-0@467e71fc-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #29 prio=3 os_prio=0 tid=0x000000000070b000 nid=0x10827 waiting for monitor entry [0x00007fffe6f72000]
"qtp791452441-28-lowPrioritySelector" #28 prio=1 os_prio=0 tid=0x0000000000695800 nid=0x10818 runnable [0x00007fffe72b3000]
"qtp791452441-27" #27 prio=5 os_prio=0 tid=0x000000000068d800 nid=0x10816 waiting on condition [0x00007fffe75f6000]
"qtp791452441-26-lowPrioritySelector" #26 prio=1 os_prio=0 tid=0x000000000068b800 nid=0x10815 runnable [0x00007fffe7937000]
"qtp791452441-24-lowPrioritySelector" #24 prio=1 os_prio=0 tid=0x0000000000687800 nid=0x10812 waiting for monitor entry [0x00007fffe7fbc000]
"qtp791452441-23" #23 prio=5 os_prio=0 tid=0x0000000000685800 nid=0x10810 waiting for monitor entry [0x00007fffe82fe000]
"qtp791452441-22-lowPrioritySelector" #22 prio=1 os_prio=0 tid=0x0000000000683800 nid=0x1080f waiting for monitor entry [0x00007fffe85ff000]
"qtp791452441-21" #21 prio=5 os_prio=0 tid=0x000000000067d000 nid=0x1080e runnable [0x00007fffe8b1d000]
"Service Thread" #20 daemon prio=9 os_prio=0 tid=0x00000000001ee800 nid=0x107c5 runnable [0x0000000000000000]
"C1 CompilerThread14" #19 daemon prio=9 os_prio=0 tid=0x00000000001e1800 nid=0x107c3 waiting on condition [0x0000000000000000]
"C1 CompilerThread13" #18 daemon prio=9 os_prio=0 tid=0x00000000001d7000 nid=0x107c1 waiting on condition [0x0000000000000000]
"C1 CompilerThread12" #17 daemon prio=9 os_prio=0 tid=0x00000000001d4000 nid=0x107bf waiting on condition [0x0000000000000000]
"C1 CompilerThread11" #16 daemon prio=9 os_prio=0 tid=0x00000000001b7800 nid=0x107bd waiting on condition [0x0000000000000000]
"C1 CompilerThread10" #15 daemon prio=9 os_prio=0 tid=0x00000000001ad800 nid=0x107bc waiting on condition [0x0000000000000000]
"C2 CompilerThread9" #14 daemon prio=9 os_prio=0 tid=0x00000000001a2000 nid=0x107bb waiting on condition [0x0000000000000000]
"C2 CompilerThread8" #13 daemon prio=9 os_prio=0 tid=0x0000000000197800 nid=0x107b9 waiting on condition [0x0000000000000000]
"C2 CompilerThread7" #12 daemon prio=9 os_prio=0 tid=0x0000000000172000 nid=0x107b8 waiting on condition [0x0000000000000000]
"C2 CompilerThread6" #11 daemon prio=9 os_prio=0 tid=0x0000000000186800 nid=0x107b7 waiting on condition [0x0000000000000000]
"C2 CompilerThread5" #10 daemon prio=9 os_prio=0 tid=0x000000000017c000 nid=0x107b6 waiting on condition [0x0000000000000000]
"C2 CompilerThread4" #9 daemon prio=9 os_prio=0 tid=0x0000000000165800 nid=0x107b5 waiting on condition [0x0000000000000000]
"C2 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x000000000010f000 nid=0x107b3 waiting on condition [0x0000000000000000]
"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x0000000000104800 nid=0x107b2 waiting on condition [0x0000000000000000]
"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00000000000f5000 nid=0x107b1 waiting on condition [0x0000000000000000]
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00000000000f2800 nid=0x107b0 waiting on condition [0x0000000000000000]
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00000000000f0800 nid=0x107af runnable [0x0000000000000000]
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00000000000c1000 nid=0x107a3 in Object.wait() [0x00007ffffd5fe000]
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00000000000be000 nid=0x107a1 in Object.wait() [0x00007ffffe9fe000]
"VM Thread" os_prio=0 tid=0x00000000000b4000 nid=0x1079d runnable 
"VM Periodic Task Thread" os_prio=0 tid=0x00000000001f3800 nid=0x107c6 waiting on condition 

Triton isn`t a fun guy!

Still Many Threads

We still have many ‘acceptor’ and ‘selector’ threads. On Triton we’ve 4 acceptor and 4 selector threads:

##
# Local docker run 
##
# Run third version of our container
sudo docker run -d -m 128m --cpus 0.065 --name=jvm-on-small-container -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:3
# List the threads running
sudo docker exec jvm-on-small-container sh -c 'jstack `pgrep java`' | grep os_prio 
"Attach Listener" #20 daemon prio=9 os_prio=0 tid=0x0000564e7cd17000 nid=0x37 waiting on condition [0x0000000000000000]
"qtp791452441-19" #19 prio=5 os_prio=0 tid=0x0000564e7cd15000 nid=0x36 waiting on condition [0x00007fdcc863f000]
"qtp791452441-17-acceptor-0@77fe3be4-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #17 prio=3 os_prio=0 tid=0x0000564e7cc25000 nid=0x34 runnable [0x00007fdcc8841000]
"DestroyJavaVM" #16 prio=5 os_prio=0 tid=0x0000564e7c922800 nid=0x8 waiting on condition [0x0000000000000000]
"qtp791452441-15-lowPrioritySelector" #15 prio=1 os_prio=0 tid=0x0000564e7ce14000 nid=0x31 waiting for monitor entry [0x00007fdccbd6e000]
"qtp791452441-14" #14 prio=5 os_prio=0 tid=0x0000564e7ce12000 nid=0x30 runnable [0x00007fdccbe6e000]
"qtp791452441-13-lowPrioritySelector" #13 prio=1 os_prio=0 tid=0x0000564e7ce0f800 nid=0x2f waiting for monitor entry [0x00007fdccbf70000]
"qtp791452441-12" #12 prio=5 os_prio=0 tid=0x0000564e7ce0e000 nid=0x2e runnable [0x00007fdccc070000]
"qtp791452441-11-lowPrioritySelector" #11 prio=1 os_prio=0 tid=0x0000564e7ce0c000 nid=0x2d waiting for monitor entry [0x00007fdccc172000]
"qtp791452441-10-lowPrioritySelector" #10 prio=1 os_prio=0 tid=0x0000564e7ce0a000 nid=0x2b waiting for monitor entry [0x00007fdccc273000]
"qtp791452441-9" #9 prio=5 os_prio=0 tid=0x0000564e7ce07800 nid=0x2a runnable [0x00007fdccc373000]
"qtp791452441-8" #8 prio=5 os_prio=0 tid=0x0000564e7ce01000 nid=0x29 runnable [0x00007fdccc474000]
"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x0000564e7c8c2800 nid=0xf runnable [0x0000000000000000]
"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x0000564e7c8b7800 nid=0xe waiting on condition [0x0000000000000000]
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x0000564e7c8ac800 nid=0xd waiting on condition [0x0000000000000000]
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x0000564e7c8aa800 nid=0xc runnable [0x0000000000000000]
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x0000564e7c87d800 nid=0xb in Object.wait() [0x00007fdccccd4000]
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x0000564e7c873000 nid=0xa in Object.wait() [0x00007fdcccdd5000]
"VM Thread" os_prio=0 tid=0x0000564e7c869000 nid=0x9 runnable 
"VM Periodic Task Thread" os_prio=0 tid=0x0000564e7c8c5800 nid=0x10 waiting on condition 


##
# Joyent Triton run
##
# Run third version of our container
eval "$(triton env)"
docker run -d -m 128m --name=jvm-on-small-container -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:3
# List the threads running
docker exec jvm-on-small-container sh -c 'jstack `pgrep java`' | grep os_prio 
"Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x000000000028c000 nid=0x732a waiting on condition [0x0000000000000000]
"qtp791452441-22" #22 prio=5 os_prio=0 tid=0x00000000006eb000 nid=0x7178 waiting on condition [0x00007fffe81fe000]
"qtp791452441-21-acceptor-3@161ab1a8-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #21 prio=3 os_prio=0 tid=0x00000000006ea000 nid=0x7177 waiting for monitor entry [0x00007fffe84ff000]
"DestroyJavaVM" #20 prio=5 os_prio=0 tid=0x00000000001df000 nid=0x7109 waiting on condition [0x0000000000000000]
"qtp791452441-19-acceptor-2@70b4bcd9-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #19 prio=3 os_prio=0 tid=0x00000000006e7000 nid=0x7175 waiting for monitor entry [0x00007fffe8800000]
"qtp791452441-18-acceptor-1@57033676-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #18 prio=3 os_prio=0 tid=0x0000000000747800 nid=0x7174 waiting for monitor entry [0x00007fffe97f6000]
"qtp791452441-17-acceptor-0@67e0dd84-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #17 prio=3 os_prio=0 tid=0x00000000006e4800 nid=0x7173 runnable [0x00007fffe8ffe000]
"qtp791452441-15-lowPrioritySelector" #15 prio=1 os_prio=0 tid=0x000000000066b000 nid=0x7159 waiting for monitor entry [0x00007fffe9af7000]
"qtp791452441-14" #14 prio=5 os_prio=0 tid=0x000000000066c800 nid=0x7157 runnable [0x00007fffe9df7000]
"qtp791452441-13-lowPrioritySelector" #13 prio=1 os_prio=0 tid=0x0000000000668800 nid=0x7156 waiting for monitor entry [0x00007fffea0f9000]
"qtp791452441-12" #12 prio=5 os_prio=0 tid=0x0000000000666800 nid=0x7155 runnable [0x00007fffea3f9000]
"qtp791452441-11" #11 prio=5 os_prio=0 tid=0x0000000000664800 nid=0x7154 runnable [0x00007fffea6fa000]
"qtp791452441-10-lowPrioritySelector" #10 prio=1 os_prio=0 tid=0x0000000000662800 nid=0x7153 waiting for monitor entry [0x00007fffea9fc000]
"qtp791452441-9" #9 prio=5 os_prio=0 tid=0x0000000000660800 nid=0x7152 runnable [0x00007fffeacfc000]
"qtp791452441-8-lowPrioritySelector" #8 prio=1 os_prio=0 tid=0x0000000000659800 nid=0x7151 waiting for monitor entry [0x00007fffeaffe000]
"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x0000000000130800 nid=0x7120 runnable [0x0000000000000000]
"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x0000000000104000 nid=0x711e waiting on condition [0x0000000000000000]
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00000000000f2800 nid=0x711d waiting on condition [0x0000000000000000]
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00000000000f0800 nid=0x711c runnable [0x0000000000000000]
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00000000000c1000 nid=0x7115 in Object.wait() [0x00007ffffd5fe000]
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00000000000be000 nid=0x7113 in Object.wait() [0x00007ffffe9fe000]
"VM Thread" os_prio=0 tid=0x00000000000b4000 nid=0x710f runnable 
"VM Periodic Task Thread" os_prio=0 tid=0x0000000000128800 nid=0x7121 waiting on condition 

Be Still Carefull of Many Threads

Our example web app now runs fine. But keep an eye on the thread count. Other Java/programming language library might create a thread pool and many threads. However, you can configure these libraries too.

Update 21th June, 2017

Well, first the OpenJDK team is improving the situation. As of JDK 8u131, the JVM does limit the CPU’s in Docker. And with the experimental flags ‘-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap’ it does limit the memory.

Also, Matt Rasband has a good blog post on how to estimate the memory usage of the JVM and set the flags properly.

Have fun running the JVM in a tiny container =)

The post Deploying JVM in tiny containers, be carefull! first appeared on Gamlor.

Chrome와 JVM 메머리 잘 먹어요.

웹앱 예

이 웹앱 예는 그냥 ‘안녕 세상’ 프로그램 이에요. 그리고 설명 때문에 메모리 많이 사용해요. 제가 이 예를 Scala로 만들어요, 근데 모든 JVM의 프로그래밍 언어들이 도같는 문제 있어요. 소스 코드가 여기 있어요.

/** 
 * Snippet, memory limits 
 */
// Limit the amount of items in memory for this example.
// So, max ~192*256k=48MBytes
val maxMemoryItems = 192
val memoryPerItem = 256 * 1024
val memoryWasting = new ArrayBlockingQueue[Array[Byte]](maxMemoryItems)

/** 
 * Snippet, request handling
 */
// On each request, consume some memory.
// And keep things in memory to simulate memory use
case "/" :: Nil => {
    // On each request, consume some memory.
    // And keep things in memory to simulate memory use
    val chunkOfMemory = Array.ofDim[Byte](memoryPerItem)
    var addedToQueue = memoryWasting.offer(chunkOfMemory)

    // Throw things away until we've space
    while (!addedToQueue) {
        memoryWasting.poll()
        addedToQueue = memoryWasting.offer(chunkOfMemory)
    }

    val createdSoFar = createdItemsCounter.incrementAndGet()
    response.getWriter.write(
        s"""
            |{
            |"title":"Hello World! Let's use some memory",
            |"created-overall":"$createdSoFar",
            |"queue-size":"${memoryWasting.size()}",
            |"":"Hello. I'm so memory hungry. kthxbye!"
            |}
        """.stripMargin)
}

처음 문제. 프로세스가 죽었어요.

트리톤 컨테이너가 문제 없고 그냥 작동해요. 근데 보통 도커 (Linux 4.10, Docker 17.04) 컨테이너가 갑자기 작동하지 않아요. =(. 프로세스를 죽였어요:

[root@gamlor-manjaro useless-demo-service]# docker run -m 128m --cpus 0.065 -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:1
2017-04-20 12:58:20.248:INFO::main: Logging initialized @5900ms to org.eclipse.jetty.util.log.StdErrLog
2017-04-20 12:58:23.348:INFO:oejs.Server:main: jetty-9.4.z-SNAPSHOT
2017-04-20 12:58:30.650:INFO:oejs.AbstractConnector:main: Started ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2017-04-20 12:58:30.748:INFO:oejs.Server:main: Started @16602ms
Killed

펭귄과 고래 위험 조심해주세요.

스레드 아주 많아요

그럼 이제는 메모리 잘 설정했어요. 근데 아마 다른 것 도 더 잘 설정할 수 있을까요? 그래서 컨테이너 작동하는 동안 `jstack`로 어느 스레드가 있는 걸 봐요!

##
# Local docker run 
##
# Run second version of our container
sudo docker run -d -m 128m --cpus 0.065 --name=jvm-on-small-container -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:2
# List the threads running
sudo docker exec jvm-on-small-container sh -c 'jstack `pgrep java`' | grep os_prio 
"qtp791452441-23" #23 prio=5 os_prio=0 tid=0x000056473bc03800 nid=0x42 waiting on condition [0x00007fefe4931000]
"Attach Listener" #22 daemon prio=9 os_prio=0 tid=0x000056473bf72800 nid=0x41 waiting on condition [0x0000000000000000]
"DestroyJavaVM" #21 prio=5 os_prio=0 tid=0x000056473bcd1800 nid=0x8 waiting on condition [0x0000000000000000]
"qtp791452441-19-acceptor-0@27b0949f-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #19 prio=3 os_prio=0 tid=0x000056473bf75000 nid=0x24 runnable [0x00007fefe4b33000]
"qtp791452441-17" #17 prio=5 os_prio=0 tid=0x000056473bc2d800 nid=0x22 runnable [0x00007fefe8160000]
"qtp791452441-16" #16 prio=5 os_prio=0 tid=0x000056473bc2b000 nid=0x21 runnable [0x00007fefe8261000]
"qtp791452441-15-lowPrioritySelector" #15 prio=1 os_prio=0 tid=0x000056473bc29000 nid=0x20 waiting for monitor entry [0x00007fefe8363000]
"qtp791452441-14-lowPrioritySelector" #14 prio=1 os_prio=0 tid=0x000056473bc8c000 nid=0x1f waiting for monitor entry [0x00007fefe8464000]
"qtp791452441-13-lowPrioritySelector" #13 prio=1 os_prio=0 tid=0x000056473bc8a000 nid=0x1e waiting for monitor entry [0x00007fefe8565000]
"qtp791452441-12-lowPrioritySelector" #12 prio=1 os_prio=0 tid=0x000056473bc86800 nid=0x1d waiting for monitor entry [0x00007fefe8666000]
"qtp791452441-11" #11 prio=5 os_prio=0 tid=0x000056473bd8a800 nid=0x1c runnable [0x00007fefe8766000]
"qtp791452441-10" #10 prio=5 os_prio=0 tid=0x000056473bd84800 nid=0x1b runnable [0x00007fefe8867000]
"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x000056473bc63800 nid=0x19 runnable [0x0000000000000000]
"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x000056473bc14000 nid=0x18 waiting on condition [0x0000000000000000]
"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x000056473bbf9000 nid=0x17 waiting on condition [0x0000000000000000]
"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x000056473bbea000 nid=0x16 waiting on condition [0x0000000000000000]
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x000056473bbe7000 nid=0x15 waiting on condition [0x0000000000000000]
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x000056473bbe4800 nid=0x14 runnable [0x0000000000000000]
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x000056473bbb5000 nid=0x13 in Object.wait() [0x00007fefe92cb000]
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x000056473bbb2000 nid=0x12 in Object.wait() [0x00007fefe93cc000]
"VM Thread" os_prio=0 tid=0x000056473bba8000 nid=0x11 runnable 
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000056473b9f0000 nid=0x9 runnable 
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000056473b9f2000 nid=0xa runnable 
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000056473b9f3800 nid=0xb runnable 
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000056473b9f5800 nid=0xc runnable 
"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x000056473b9f7000 nid=0xd runnable 
"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x000056473b9f9000 nid=0xe runnable 
"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x000056473b9fa800 nid=0xf runnable 
"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x000056473b9fc800 nid=0x10 runnable 
"VM Periodic Task Thread" os_prio=0 tid=0x000056473bc59800 nid=0x1a waiting on condition

##
# Joyent Triton run
##
# Run second version of our container
eval "$(triton env)"
docker run -d -m 128m --name=jvm-on-small-container -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:2
# List the threads running
docker exec jvm-on-small-container sh -c 'jstack `pgrep java`' | grep os_prio 
"qtp791452441-44" #44 prio=5 os_prio=0 tid=0x000000000215e000 nid=0x12de4 runnable [0x00007fffe51f7000]
"qtp791452441-43" #43 prio=5 os_prio=0 tid=0x0000000000262000 nid=0x12aa4 waiting for monitor entry [0x00007fffe52fa000]
"qtp791452441-42" #42 prio=5 os_prio=0 tid=0x000000000068a000 nid=0x11808 waiting on condition [0x00007fffe7c7a000]
"Scheduler-1896277646" #41 prio=5 os_prio=0 tid=0x0000000000145000 nid=0x1176f waiting on condition [0x00007fffe4e34000]
"Attach Listener" #39 daemon prio=9 os_prio=0 tid=0x0000000000717800 nid=0x116e2 waiting on condition [0x0000000000000000]
"DestroyJavaVM" #33 prio=5 os_prio=0 tid=0x0000000000716000 nid=0x10796 waiting on condition [0x0000000000000000]
"qtp791452441-32-acceptor-3@6dbc83d8-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #32 prio=3 os_prio=0 tid=0x0000000000714800 nid=0x1082a runnable [0x00007fffe5cff000]
"qtp791452441-31-acceptor-2@1ac08473-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #31 prio=3 os_prio=0 tid=0x0000000000713000 nid=0x10829 waiting for monitor entry [0x00007fffe6000000]
"qtp791452441-30-acceptor-1@34228b2c-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #30 prio=3 os_prio=0 tid=0x000000000070d800 nid=0x10828 waiting for monitor entry [0x00007fffe67fe000]
"qtp791452441-29-acceptor-0@467e71fc-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #29 prio=3 os_prio=0 tid=0x000000000070b000 nid=0x10827 waiting for monitor entry [0x00007fffe6f72000]
"qtp791452441-28-lowPrioritySelector" #28 prio=1 os_prio=0 tid=0x0000000000695800 nid=0x10818 runnable [0x00007fffe72b3000]
"qtp791452441-27" #27 prio=5 os_prio=0 tid=0x000000000068d800 nid=0x10816 waiting on condition [0x00007fffe75f6000]
"qtp791452441-26-lowPrioritySelector" #26 prio=1 os_prio=0 tid=0x000000000068b800 nid=0x10815 runnable [0x00007fffe7937000]
"qtp791452441-24-lowPrioritySelector" #24 prio=1 os_prio=0 tid=0x0000000000687800 nid=0x10812 waiting for monitor entry [0x00007fffe7fbc000]
"qtp791452441-23" #23 prio=5 os_prio=0 tid=0x0000000000685800 nid=0x10810 waiting for monitor entry [0x00007fffe82fe000]
"qtp791452441-22-lowPrioritySelector" #22 prio=1 os_prio=0 tid=0x0000000000683800 nid=0x1080f waiting for monitor entry [0x00007fffe85ff000]
"qtp791452441-21" #21 prio=5 os_prio=0 tid=0x000000000067d000 nid=0x1080e runnable [0x00007fffe8b1d000]
"Service Thread" #20 daemon prio=9 os_prio=0 tid=0x00000000001ee800 nid=0x107c5 runnable [0x0000000000000000]
"C1 CompilerThread14" #19 daemon prio=9 os_prio=0 tid=0x00000000001e1800 nid=0x107c3 waiting on condition [0x0000000000000000]
"C1 CompilerThread13" #18 daemon prio=9 os_prio=0 tid=0x00000000001d7000 nid=0x107c1 waiting on condition [0x0000000000000000]
"C1 CompilerThread12" #17 daemon prio=9 os_prio=0 tid=0x00000000001d4000 nid=0x107bf waiting on condition [0x0000000000000000]
"C1 CompilerThread11" #16 daemon prio=9 os_prio=0 tid=0x00000000001b7800 nid=0x107bd waiting on condition [0x0000000000000000]
"C1 CompilerThread10" #15 daemon prio=9 os_prio=0 tid=0x00000000001ad800 nid=0x107bc waiting on condition [0x0000000000000000]
"C2 CompilerThread9" #14 daemon prio=9 os_prio=0 tid=0x00000000001a2000 nid=0x107bb waiting on condition [0x0000000000000000]
"C2 CompilerThread8" #13 daemon prio=9 os_prio=0 tid=0x0000000000197800 nid=0x107b9 waiting on condition [0x0000000000000000]
"C2 CompilerThread7" #12 daemon prio=9 os_prio=0 tid=0x0000000000172000 nid=0x107b8 waiting on condition [0x0000000000000000]
"C2 CompilerThread6" #11 daemon prio=9 os_prio=0 tid=0x0000000000186800 nid=0x107b7 waiting on condition [0x0000000000000000]
"C2 CompilerThread5" #10 daemon prio=9 os_prio=0 tid=0x000000000017c000 nid=0x107b6 waiting on condition [0x0000000000000000]
"C2 CompilerThread4" #9 daemon prio=9 os_prio=0 tid=0x0000000000165800 nid=0x107b5 waiting on condition [0x0000000000000000]
"C2 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x000000000010f000 nid=0x107b3 waiting on condition [0x0000000000000000]
"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x0000000000104800 nid=0x107b2 waiting on condition [0x0000000000000000]
"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00000000000f5000 nid=0x107b1 waiting on condition [0x0000000000000000]
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00000000000f2800 nid=0x107b0 waiting on condition [0x0000000000000000]
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00000000000f0800 nid=0x107af runnable [0x0000000000000000]
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00000000000c1000 nid=0x107a3 in Object.wait() [0x00007ffffd5fe000]
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00000000000be000 nid=0x107a1 in Object.wait() [0x00007ffffe9fe000]
"VM Thread" os_prio=0 tid=0x00000000000b4000 nid=0x1079d runnable 
"VM Periodic Task Thread" os_prio=0 tid=0x00000000001f3800 nid=0x107c6 waiting on condition 

트리톤 재미 없는 놈 야!!

스레드 아직 많아요

‘acceptor’, ‘lowPrioritySelector’ 스레드가 아직 많아요. 트리톤 컨테이너 안에 ‘acceptor’ 스레드 4개, lowPrioritySelector 스레드 4개 있어요:

##
# Local docker run 
##
# Run third version of our container
sudo docker run -d -m 128m --cpus 0.065 --name=jvm-on-small-container -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:3
# List the threads running
sudo docker exec jvm-on-small-container sh -c 'jstack `pgrep java`' | grep os_prio 
"Attach Listener" #20 daemon prio=9 os_prio=0 tid=0x0000564e7cd17000 nid=0x37 waiting on condition [0x0000000000000000]
"qtp791452441-19" #19 prio=5 os_prio=0 tid=0x0000564e7cd15000 nid=0x36 waiting on condition [0x00007fdcc863f000]
"qtp791452441-17-acceptor-0@77fe3be4-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #17 prio=3 os_prio=0 tid=0x0000564e7cc25000 nid=0x34 runnable [0x00007fdcc8841000]
"DestroyJavaVM" #16 prio=5 os_prio=0 tid=0x0000564e7c922800 nid=0x8 waiting on condition [0x0000000000000000]
"qtp791452441-15-lowPrioritySelector" #15 prio=1 os_prio=0 tid=0x0000564e7ce14000 nid=0x31 waiting for monitor entry [0x00007fdccbd6e000]
"qtp791452441-14" #14 prio=5 os_prio=0 tid=0x0000564e7ce12000 nid=0x30 runnable [0x00007fdccbe6e000]
"qtp791452441-13-lowPrioritySelector" #13 prio=1 os_prio=0 tid=0x0000564e7ce0f800 nid=0x2f waiting for monitor entry [0x00007fdccbf70000]
"qtp791452441-12" #12 prio=5 os_prio=0 tid=0x0000564e7ce0e000 nid=0x2e runnable [0x00007fdccc070000]
"qtp791452441-11-lowPrioritySelector" #11 prio=1 os_prio=0 tid=0x0000564e7ce0c000 nid=0x2d waiting for monitor entry [0x00007fdccc172000]
"qtp791452441-10-lowPrioritySelector" #10 prio=1 os_prio=0 tid=0x0000564e7ce0a000 nid=0x2b waiting for monitor entry [0x00007fdccc273000]
"qtp791452441-9" #9 prio=5 os_prio=0 tid=0x0000564e7ce07800 nid=0x2a runnable [0x00007fdccc373000]
"qtp791452441-8" #8 prio=5 os_prio=0 tid=0x0000564e7ce01000 nid=0x29 runnable [0x00007fdccc474000]
"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x0000564e7c8c2800 nid=0xf runnable [0x0000000000000000]
"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x0000564e7c8b7800 nid=0xe waiting on condition [0x0000000000000000]
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x0000564e7c8ac800 nid=0xd waiting on condition [0x0000000000000000]
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x0000564e7c8aa800 nid=0xc runnable [0x0000000000000000]
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x0000564e7c87d800 nid=0xb in Object.wait() [0x00007fdccccd4000]
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x0000564e7c873000 nid=0xa in Object.wait() [0x00007fdcccdd5000]
"VM Thread" os_prio=0 tid=0x0000564e7c869000 nid=0x9 runnable 
"VM Periodic Task Thread" os_prio=0 tid=0x0000564e7c8c5800 nid=0x10 waiting on condition 


##
# Joyent Triton run
##
# Run third version of our container
eval "$(triton env)"
docker run -d -m 128m --name=jvm-on-small-container -p 8080:8080 gamlerhart/blog-jvm-on-small-containers:3
# List the threads running
docker exec jvm-on-small-container sh -c 'jstack `pgrep java`' | grep os_prio 
"Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x000000000028c000 nid=0x732a waiting on condition [0x0000000000000000]
"qtp791452441-22" #22 prio=5 os_prio=0 tid=0x00000000006eb000 nid=0x7178 waiting on condition [0x00007fffe81fe000]
"qtp791452441-21-acceptor-3@161ab1a8-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #21 prio=3 os_prio=0 tid=0x00000000006ea000 nid=0x7177 waiting for monitor entry [0x00007fffe84ff000]
"DestroyJavaVM" #20 prio=5 os_prio=0 tid=0x00000000001df000 nid=0x7109 waiting on condition [0x0000000000000000]
"qtp791452441-19-acceptor-2@70b4bcd9-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #19 prio=3 os_prio=0 tid=0x00000000006e7000 nid=0x7175 waiting for monitor entry [0x00007fffe8800000]
"qtp791452441-18-acceptor-1@57033676-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #18 prio=3 os_prio=0 tid=0x0000000000747800 nid=0x7174 waiting for monitor entry [0x00007fffe97f6000]
"qtp791452441-17-acceptor-0@67e0dd84-ServerConnector@512ddf17{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}" #17 prio=3 os_prio=0 tid=0x00000000006e4800 nid=0x7173 runnable [0x00007fffe8ffe000]
"qtp791452441-15-lowPrioritySelector" #15 prio=1 os_prio=0 tid=0x000000000066b000 nid=0x7159 waiting for monitor entry [0x00007fffe9af7000]
"qtp791452441-14" #14 prio=5 os_prio=0 tid=0x000000000066c800 nid=0x7157 runnable [0x00007fffe9df7000]
"qtp791452441-13-lowPrioritySelector" #13 prio=1 os_prio=0 tid=0x0000000000668800 nid=0x7156 waiting for monitor entry [0x00007fffea0f9000]
"qtp791452441-12" #12 prio=5 os_prio=0 tid=0x0000000000666800 nid=0x7155 runnable [0x00007fffea3f9000]
"qtp791452441-11" #11 prio=5 os_prio=0 tid=0x0000000000664800 nid=0x7154 runnable [0x00007fffea6fa000]
"qtp791452441-10-lowPrioritySelector" #10 prio=1 os_prio=0 tid=0x0000000000662800 nid=0x7153 waiting for monitor entry [0x00007fffea9fc000]
"qtp791452441-9" #9 prio=5 os_prio=0 tid=0x0000000000660800 nid=0x7152 runnable [0x00007fffeacfc000]
"qtp791452441-8-lowPrioritySelector" #8 prio=1 os_prio=0 tid=0x0000000000659800 nid=0x7151 waiting for monitor entry [0x00007fffeaffe000]
"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x0000000000130800 nid=0x7120 runnable [0x0000000000000000]
"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x0000000000104000 nid=0x711e waiting on condition [0x0000000000000000]
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00000000000f2800 nid=0x711d waiting on condition [0x0000000000000000]
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00000000000f0800 nid=0x711c runnable [0x0000000000000000]
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00000000000c1000 nid=0x7115 in Object.wait() [0x00007ffffd5fe000]
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00000000000be000 nid=0x7113 in Object.wait() [0x00007ffffe9fe000]
"VM Thread" os_prio=0 tid=0x00000000000b4000 nid=0x710f runnable 
"VM Periodic Task Thread" os_prio=0 tid=0x0000000000128800 nid=0x7121 waiting on condition 

스레드 많기 아직 조심하세요!

우리 웹앱 예 이제 괜찮게 작동해요. 근데 스레드 개수 잘 보세요. 다른 Java/프로그래밍 언어 라이브러리도 아마 스레드 풀 만들고 스레드 너무 많이 만들어요. 근데 이 라이브러리들이 도 설정할 수 있어요.

Update 21th June, 2017

먼저, JDK 프로그래머들이 도커 지원 개선 가요.. JDK 8u131부터, JVM는 CPU를 한도 해요. 그리고 `-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap’ 사용하면 메모리도 한도 해요.

그리고 Matt Rasband는 좋은 블로그 글 썼어요. 이 글이 어떡해 JVM의 메모리 사이즈 대략 추산하고 메모리의 명령 행 옵션 자동으로 설정하기 설명해요.

작은 JVM 컨테이너 잘 사용하세요 =).

The post JVM는 작은 컨테이너 안에 배포하면 주의! first appeared on Gamlor.