A memóriámmal van a baj...

Azért vannak jó hírek is rájöttem, hogy a Midnight Command a Meta , (ESC , vagy Alt+,) hatására kapcsolja át a Layout-ot. Amit könnyű véletlenül megnyomni, csak eddig sosem tudtam, hogy mi is volt az, amit véletlenül megnyomtam.

Aztán van egy olyan, hogy `mtrace(3)` és `mtrace(1)`
Betoltam a derék termék alá, meglátjuk, mi lesz belőle. (Mondjuk most jól jönne, ha a SpringBoot nem ébredne fel félpercenként, hogy 'na, kell valami? tudok valamit tüsténkedni?'.)
Szerk: és már itt is egy eredmény:

*** Error 'java.io.IOException: Cannot run program "df": error=1886334817, Exec failed'
in system('df -h ./tmp')

Ebből az első rész a ProcessBuilder által dobott Exception toString-je, a hibakódot még nem találtam meg az errno tipikus értékei között, de még keresem.

van pl egy olyan, hogy

/openjdk-jdk11u/src/java.base/share/classes/java/lang/ProcessBuilder.java:1124

            // It's much easier for us to create a high-quality error
            // message than the low-level C code which found the problem.
            throw new IOException(
                "Cannot run program \"" + prog + "\""
                + (dir == null ? "" : " (in directory \"" + dir + "\")")
                + exceptionInfo,
                cause);

Ő ezt hívja:

/openjdk-jdk11u/src/java.base/windows/classes/java/lang/ProcessImpl.java

És végül van a natív kód:

openjdk-jdk11u/src/java.base/unix/native/libjava/ProcessImpl_md.c:
  Java_java_lang_ProcessImpl_forkAndExec
/openjdk-jdk11u/src/java.base/unix/native/libjava/childproc.c:
  int childProcess(void *arg)

Szerk: stacktrace javítása után:

Root Exception: java.io.IOException: error=811743284, Exec failed
Following Excp: java.io.IOException: Cannot run program "df": error=811743284, Exec failed
  at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
  at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:340)
  at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:271)
  at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1107)
  at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)

Szóval az a csúnya szám az errno értéke, amikor a childProcess valamilyen hibára szalad. Esetleg ez a 'valamilyen hiba' nem állítja az errno-t, bár mindenki azt hitte, hogy minden hiba állítja az errno-t?

Egy másik kontextusban is kipróbáltam valami mást, ez annyival lett rosszabb, hogy ebben még C++ is látszik lenni. Mondjuk jogos, igazi nagy szoqásokat a C++ használatával lehet elérni. (Most hadd nem mondjam azt, hogy a C++ a programnyelvek uefi-je.)

#0  0x00007ffff72281ed in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff7232ce7 in fprintf () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff7261323 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff694ee91 in os::strdup(char const*, MemoryType) () from /local/opt/jdk-11.0.6+10/lib/server/libjvm.so
#4  0x00007ffff6ac3550 in Symbol::print_symbol_on(outputStream*) const () from /local/opt/jdk-11.0.6+10/lib/server/libjvm.so
#5  0x00007ffff68db4e7 in Method::print_short_name(outputStream*) () from /local/opt/jdk-11.0.6+10/lib/server/libjvm.so
#6  0x00007ffff638f7b4 in CompileTask::print(outputStream*, char const*, bool, bool) ()
   from /local/opt/jdk-11.0.6+10/lib/server/libjvm.so

Szerk: úgy foglalnám össze, hogy sikerrel bebizonyítottuk, hogy a mtrace nem jól kombózik a multithread-del.

Kiegészítő érdekesség: bármilyen file-megnyitási hiba `FileNotFoundException`-t ad, de legalább zárójelben ott van a valódi ok:

Root Exception: java.io.FileNotFoundException: /test1 (Permission denied)
Root Exception: java.io.FileNotFoundException: test2 (Is a directory)

Van például egy `-X:MaxRAM=` opció. Ez állítólag összességében korlátoz több dolgot. Azért a tapasztalatok szerint nem mindent.

$ (ulimit -v 393216; java11 -XX:MaxRAM=128M Hello)
Error occurred during initialization of VM
Could not reserve enough space for code cache (245760K)

Szóval 384MB a címtartomány, a MaxRAM 128MB, a code-cache 240MB-t szeretne. A kis szerény.

Most legutóbb két módon monitoroztam a futást, egyrészt ps -o size,vsz,rss értékeket másodprecenként, másrészt a fenti cgroup-os mágiával.

Azt véltem látni, hogy az első nem "szaladt el", csak a második... ebből akár arra is gondolhatok, hogy a kernelben a cgroups memóriaszámolása a problémás. A korszerű kernel-verzióm 3.10.0-957.5.1.el7.x86_64, ha nagyon bátor lennék, kipróbálnám egy frissebb kernellel.

Szerk: egyelőre ennyit mertem előrelépni, tesztelése következik:
3.10.0-957.5.1.el7.x86_64 #1 SMP -> 3.10.0-1127.13.1.el7.x86_64 #1 SMP

Ma azt mértem, hogy amikor a cgroups szerint hirtelen csökken a memóriahasználat, akkor mit csinál a program az `strace` szerint.

                   memory.usage   memory.kmem.usage
--------------------------------------------------------------------
20200709.103742 |  2468872192     67342336   2469097472   5368709120
20200709.103743 |  2387853312     67059712   2469097472   5368709120
20200709.103744 |  1825976320     59265024   2469097472   5368709120
20200709.103745 |  1255059456     45334528   2469097472   5368709120
20200709.103746 |   690331648     21778432   2469097472   5368709120
20200709.103747 |   596033536      5943296   2469097472   5368709120

Hát kérem szépen, az eredmény az, hogy épp abban az időben törli az ideiglenes fájlokat a program (unlink(2)). Ebből arra következtetnék, hogy valamilyen disk-cache-t számol hozzá a cgroups a programomhoz. Ami nagyon rendes tőle, de hogyan beszéljem le róla, vagy mit kezdjek ezzel?