Re:スタックサイズの調査(Windows)

Re:スタックサイズの調査(Windows) - ナンセンス不定記の続き。
Windows 10 x64+Oracle JDK 1.8.0_152 x64で計測した。

none: 11403
-Xss256k: 2454
-Xss512k: 5440
-Xss1m: 11424
-Xss2m: 23334
-Xss4m: 39501
-Xss8m: 94816

なんかLinuxはデフォルトサイズが1mで、Windowsは512k程度と思っていたら、Windowsも1mだった。
おそらくjdkのバージョン違いか、x86とx64の違いなんだろうけど、もうjdk 8のx64しか使わないからいいや。

Re:スレッド生成の調査(Windows)

スレッド生成の調査 - ナンセンス不定記の続き。
Windows x64+Oracle JDK 1.6.0_35 x86で計測した。

none 2704
-Xss256k 3031
-Xss512k 2057
-Xss1m 1243
-Xss2m 694
-Xss4m 363
-Xss8m 182

Windows x64+Oracle JDK 1.6.0_35 x86+tomcat 6.0.43で計測した。

none 2099
-Xss256k 2356
-Xss512k 1576
-Xss1m 959 ※jvmクラッシュ
-Xss2m 524
-Xss4m 269
-Xss8m 128
|<<
1MBの時だけcatch出来ずにjvmクラッシュログが出力された。
>||
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 700328 bytes for Chunk::new
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (allocation.cpp:317), pid=15180, tid=19336
#
# JRE version: 6.0_35-b10
# Java VM: Java HotSpot(TM) Server VM (20.10-b01 mixed mode windows-x86 )

Re:スタックサイズの調査(Windows)

スタックサイズの調査 - ナンセンス不定記の続き。
Windows x64+Oracle JDK 1.6.0_35 x86で計測した。

ローカル変数int×0個
none 7386
-Xss256k 5747
-Xss512k 12301
-Xss1m 25407
-Xss2m 51622
-Xss4m 104051
-Xss8m 208909

ローカル変数int×1個

none 7235
-Xss256k 5597
-Xss512k 12150
-Xss1m 25258
-Xss2m 51471
-Xss4m 103900
-Xss8m 208758

ローカル変数int×5個

none 6633
-Xss256k 4995
-Xss512k 11548
-Xss1m 24656
-Xss2m 50872
-Xss4m 103299
-Xss8m 208156

ローカル変数int×10個

none 4240
-Xss256k 3216
-Xss512k 7312
-Xss1m 15504
-Xss2m 31888
-Xss4m 64656
-Xss8m 130192

ファイル送信のサンプル

ファイル送信のサンプルを作った。

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;

public class SendFile {
	public static void main(String[] args) {
		BufferedOutputStream os = null;
		BufferedInputStream is = null;
		BufferedReader r = null;
		try {
			URL url = new URL("http://localhost:8080/upload.jsp");
			HttpURLConnection conn = (HttpURLConnection)url.openConnection();
			conn.setRequestMethod("POST");
			conn.setRequestProperty("x-filename", "arc.log");
			conn.setDoInput(true);
			conn.setDoOutput(true);
			os = new BufferedOutputStream(conn.getOutputStream());
			is = new BufferedInputStream(new FileInputStream("/home/hiuchida/arc.log"));
			while (true) {
				int dat = is.read();
				if (dat < 0) break;
				os.write(dat);
			}
			is.close();
			is = null;
			os.close();
			os = null;
			r = new BufferedReader(new InputStreamReader(conn.getInputStream()));
			while (true) {
				String line = r.readLine();
				if (line == null) break;
				System.out.println(line);
			}
			r.close();
			r = null;
		} catch (Exception e) {
			e.printStackTrace();
		} finally {
			if (is != null)
				try {
					is.close();
				} catch (IOException e) {}
			if (os != null)
				try {
					os.close();
				} catch (IOException e) {}
			if (r != null)
				try {
					r.close();
				} catch (IOException e) {}
		}
	}
}

サーバー側のtomcatにupload.jspを置く。

<%
String fname = request.getHeader("x-filename");
out.write("filename=" + fname);
java.io.InputStream is = request.getInputStream();
java.io.OutputStream os = new java.io.FileOutputStream(request.getRealPath("/" + fname));
byte[] buf = new byte[1024];
while (true) {
    int len = is.read(buf);
    if (len < 0) break;
    os.write(buf, 0, len);
}
os.close();
%>

プロセス起動のサンプル

お手軽にプロセス起動のサンプルを作った。stdoutとstderrはとりあえず要らない。

public class CreateProcess {
	public static void main(String[] args) {
		try {
			ProcessBuilder pb = new ProcessBuilder("/home/hiuchida/arc.sh");
			Process p = pb.start();
			int rc = p.waitFor();
			System.out.println("rc=" + rc);
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

libXext.so.6が無いと怒られた

CentOS 6.7 x86_64
Oracle JDK 1.8.0_91 x86
Apache Tomcat 6.0.45
で起動しようとしたら、

Caused by: java.lang.UnsatisfiedLinkError: /usr/java/jdk1.8.0_91/jre/lib/i386/li
bawt_xawt.so: libXext.so.6: 共有オブジェクトファイルを開けません: そのようなファ
イルやディレクトリはありません

と怒られた。

$ yum install libXext.so.6

libXextをインストールして再度起動しようとしたら、

Caused by: java.lang.UnsatisfiedLinkError: /usr/java/jdk1.8.0_91/jre/lib/i386/li
bawt_xawt.so: libXrender.so.1: 共有オブジェクトファイルを開けません: そのような
ファイルやディレクトリはありません

と怒られた。うーむ、JDK 1.8 x86だからいけないのか。

$ yum install libXrender.so.1

エラー:  Multilib version problems found. This often means that the root
        cause is something else and multilib version checking is just
        pointing out that there is a problem. Eg.:
        
          1. You have an upgrade for libXrender which is missing some
             dependency that another package requires. Yum is trying to
             solve this by installing an older version of libXrender of the
             different architecture. If you exclude the bad architecture
             yum will tell you what the root cause is (which package
             requires what). You can try redoing the upgrade with
             --exclude libXrender.otherarch ... this should give you an error
             message showing the root cause of the problem.
        
          2. You have multiple architectures of libXrender installed, but
             yum can only see an upgrade for one of those arcitectures.
             If you don't want/need both architectures anymore then you
             can remove the one with the missing update and everything
             will work.
        
          3. You have duplicate versions of libXrender installed already.
             You can use "yum check" to get yum show these errors.
        
        ...you can also use --setopt=protected_multilib=false to remove
        this checking, however this is almost never the correct thing to
        do as something else is very likely to go wrong (often causing
        much more problems).
        
        Protected multilib versions: libXrender-0.9.8-2.1.el6_8.1.i686 != libXrender-0.9.8-2.1.el6.x86_64

面倒なことになってきた。やれやれ。あきらめるか。

スレッド生成の調査

javaでスレッド生成の調査を行った。
まずjava.lang.OutOfMemoryError: unable to create new native threadが出るまでスレッド生成するプログラムを作る。

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

public class CreateThread {
	public static void main(String[] args) {
		List<Thread> list = new ArrayList<Thread>();
		try {
			for (int i=1; true; i++) {
				Thread t = new Thread() {
					public void run() {
						while (true) {
							try {
								Thread.sleep(1000);
							} catch (InterruptedException e) {}
						}
					}
				};
				t.start();
				list.add(t);
				System.out.println(i);
			}
		} catch (Error e) {
			e.printStackTrace();
		}
		for (Thread t : list) {
			t.stop();
		}
	}
}

起動パラメータを変えて、スレッド生成がいくつ可能か調べる。

none 772
-Xss256k 774
-Xss512k 774
-Xss1m 774
-Xss2m 774
-Xss4m 774
-Xss8m 775

あれれ、スタックサイズを増やすとスレッドが作れなくなると思っていたが、変わらなかった。
別の制限があるのかな。

Linux におけるスレッド数の上限を参考にシステムパラメータを調べてみた。

$ ulimit -u
1024
$ cat /proc/sys/kernel/threads-max
14714
$ cat /proc/sys/vm/max_map_count
65530
$ cat /proc/sys/kernel/pid_max
32768

試しにulimit -u 10000してみたら、

$ ulimit -u 10000
$ ulimit -u
7357

となった。
再度、スレッド生成を調べる。

none 14177
-Xss256k 14177
-Xss512k 14158

ここで、CentOS x86_64のOpenJDKを使っている事を思い出した。64ビットVMだからスタックサイズを増やしてもメモリ確保できるじゃん。
調べたいのは32ビットVMでスタックサイズを変えたときにスレッドがどれだけ生成できるかだった。
Oracle JDK 1.8.0_91 x86をインストールする。
再度、スレッド生成を調べる。

none 10247
-Xss256k 12764
-Xss512k 6480
-Xss1m 3268
-Xss2m 1638
-Xss4m 818
-Xss8m 406

やっと欲しい情報が取れた。でもWindowsだと100個くらいしかスレッドが作れなかったな。ああ、-Xms512m -Xmx512mだった。
再度、スレッド生成を調べる。

-Xms512m -Xmx512m 10111
-Xms512m -Xmx512m -Xss256k 12593
-Xms512m -Xmx512m -Xss512k 6394
-Xms512m -Xmx512m -Xss1m 3227
-Xms512m -Xmx512m -Xss2m 1616
-Xms512m -Xmx512m -Xss4m 806
-Xms512m -Xmx512m -Xss8m 400

ヒープサイズは関係なかった。うーむ、Windowsでも調査してみないと分からないな。