링크 ux 서버 에서 스 레 드 수 를 늘 리 는 두 가지 사고

작업 중 자바 프로그램 에 오류 가 발생 하여 로 컬 스 레 드 를 만 들 수 없습니다.여기 서 정리 해 봐.
사고 1. ulimit 명령 을 통 해 셸 다 중 스 레 드 프로그램 스 택 의 크기 를 제한 하고 사용 가능 한 스 레 드 수량 을 증가 하 는 목적 을 달성 합 니 다.
하나의 예 는 진실 한 사례 에서 나온다.우리 가 직면 한 문 제 는 시스템 이 우리 의 다 중 스 레 드 프로그램 에 대해 다음 과 같은 제한 이 있다 는 것 이다.
ulimit -v 200000
본문 앞의 소개 에 따 르 면 이것 은 우리 프로그램 이 최대 200 MB 의 가상 메모리 만 사용 할 수 있다 는 것 을 의미한다.우리 의 프로그램 은 다 중 스 레 드 프로그램 이기 때문에 프로그램 이 실 행 될 때 필요 에 따라 새로운 스 레 드 를 만 들 것 입 니 다. 이것 은 반드시 전체 메모리 수 요 량 을 증가 시 킬 것 입 니 다.처음에 우리 가 스 택 크기 에 대한 제한 은 1024 였 다.

 # ulimit – s 1232

 
프로그램 이 시 작 된 후에 pmap 를 통 해 메모리 사용 상황 을 볼 수 있 습 니 다. 1232 KB 를 차지 하 는 여러 개의 데이터 세그먼트 를 볼 수 있 습 니 다. 이것 은 프로그램 이 만 든 스 레 드 에 사용 되 는 스 택 입 니 다.
 
새로운 스 레 드 가 생 성 될 때마다 1232 KB 크기 의 메모리 공간 을 새로 할당 해 야 합 니 다. 저희 의 전체 가상 메모리 제한 은 200 MB 입 니 다. 따라서 더 많은 스 레 드 를 만 들 필요 가 있다 면 개선 할 수 있 는 방법 은 모든 스 레 드 의 고정 스 택 크기 를 줄 이 는 것 입 니 다. 이것 은 ulimit – s 를 통 해 이 루어 질 수 있 습 니 다.

 # ulimit -s 512 

스 택 크기 를 512 KB 로 설정 합 니 다. 이 때 pmap 를 통 해 설정 이 작 동 하 는 지 확인 합 니 다.
위의 정 보 를 통 해 알 수 있 듯 이 우 리 는 스 레 드 의 스 택 크기 를 512 KB 로 성공 적 으로 바 꾸 었 습 니 다. 그러면 전체 메모리 사용 제한 이 변 하지 않 는 상황 에서 우 리 는 이 소절 에서 소개 하 는 방법 으로 만 들 수 있 는 스 레 드 수 를 증가 시 켜 프로그램의 다 중 스 레 드 성능 을 개선 할 수 있 습 니 다.
아이디어 2, JVM 부터 진행
jvm 시작 매개 변수의 Xss
- Xss 128 k: 스 레 드 마다 스 택 크기 를 설정 합 니 다.JDK 5.0 이후 모든 스 레 드 스 택 크기 는 1M 입 니 다.sunos 에서 32 비트 자바 테스트 이 값 은 512 K 입 니 다.응용 스 레 드 에 필요 한 메모리 크기 에 따라 조정 할 수 있 습 니 다.같은 물리 적 메모리 에서 이 값 을 줄 이면 더 많은 스 레 드 를 만 들 수 있 습 니 다.그러나 운영 체 제 는 한 프로 세 스 의 스 레 드 수 에 제한 이 있어 무한 생 성 이 불가능 하고 경험 치 는 3000 ~ 5000 정도 입 니 다.
"Exception in thread"main "java. lang. OutOf Memory Error: unable to create new native thread"이상 문 제 는 본질 적 으로 프로그램 이 너무 많은 스 레 드 를 만 들 었 기 때 문 입 니 다. 만 들 수 있 는 스 레 드 수 는 제한 되 어 이상 이 발생 했 습 니 다.
만 들 수 있 는 스 레 드 수의 구체 적 인 계산 공식 은 다음 과 같다.
자바 언어 에서 스 레 드 를 만 들 때 가상 기 회 는 JVM 메모리 에 Thread 대상 을 만 드 는 동시에 운영 체제 스 레 드 를 만 듭 니 다. 이 시스템 스 레 드 의 메모 리 는 JVMMMemory 가 아니 라 시스템 에 남 은 메모리 (MaxProcessMemory - JVMMMemory - Reserved OsMemory) 를 사용 합 니 다.공식 적 으로 결론 을 내 렸 습 니 다. JVM 메모리 가 많 을 수록 만 들 수 있 는 스 레 드 가 적 을 수록 자바. lang. OutOf Memory Error: unable to create new native thread 가 발생 하기 쉽 습 니 다.
-- 테스트 에 따 르 면 이런 견 해 는 32 비트 자바 프로그램 에 만 적용 되 며 64 비트 자 바 는 이 제한 을 받 지 않 는 다
 
프로그램

import java.util.concurrent.CountDownLatch;



public class TestNativeOutOfMemoryError {

    public static void main(String[] args) {

        for (int i = 0;; i++) {

            System.out.println("i = " + i);

            new Thread(new HoldThread()).start();

        }

    }

}

class HoldThread extends Thread {

    CountDownLatch cdl = new CountDownLatch(1);

    public HoldThread() {

        this.setDaemon(true);

    }

    public void run() {

        try {cdl.await();} 

        catch (InterruptedException e) {}

    }

}

만약 에 프로그램 이 대량의 스 레 드 가 필요 하 다 면 기 존의 설정 이 요구 에 도달 하지 못 하면 MaxProcessMemory, JVMMMemory, ThreadStackSize 라 는 세 가지 요 소 를 수정 하여 만 들 수 있 는 스 레 드 수 를 증가 할 수 있 습 니 다.
a, MaxProcessMemory 64 비트 JVM 사용
    테스트 를 통 해 64 비트 jvm 에서 생 성 된 스 레 드 수 는 상기 공식 으로 부터 제약 을 받 지 않 고 값 은 63260 이 므 로 이 수 치 는 충분히 사용 할 수 있 을 것 이다.
    테스트 데 이 터 는 다음 과 같 습 니 다. (명령 | 시작 할 수 있 는 스 레 드 수량)    

java -Xms512M -Xmx2G -cp . TestNativeOutOfMemoryError   | 63389

java -Xms512M -Xmx8G -cp . TestNativeOutOfMemoryError   | 63260

java -Xms512M -Xmx16G -cp . TestNativeOutOfMemoryError  | 63385

java -Xms512M -Xmx32G -cp . TestNativeOutOfMemoryError  | 63380

java -Xms512M -Xmx64G -cp . TestNativeOutOfMemoryError  |63387

b, JVMMemory   JVMMMemory 의 분 배 를 감소 합 니 다 (즉, xms/xmx 의 크기 를 감소 합 니 다)
c, ThreadStackSize  단일 스 레 드 의 스 택 크기 줄 이기 (- Xss)