park/unpark의 CPU 사용률이 60 % 인 이유는 무엇입니까?

최근 우리는 YJP 11.0.9를 사용하여 응용 프로그램 (XMPP 기반 채팅 서버)을 스트레스 테스트하기 시작했습니다. 우리가 시험하는 동안 우리는 이상한 행동을 한 것으로 나타났습니다.park/unpark의 CPU 사용률이 60 % 인 이유는 무엇입니까?

샘플링에서는 sun.misc.Unsafe.unpark (Object)가 CPU의 60 %를 차지함을 보여줍니다.
동일한 응용 프로그램의 경우 추적은 LockSupport.park (Object)가 CPU의 52 %를 차지함을 보여줍니다.

결과를 확인하기 위해 여러 번 테스트를했고 비슷한 결과가 나타날 때마다 테스트했습니다.

왜 unpark가 60 %의 시간이 소요되는지와 왜 추적 결과가 정확히 반대되는 결과를 보여야하는지 이해할 수 없습니다.

누군가 이러한 결과를 이해할 수 있도록 도와 줄 수 있습니까? 내가 여기서 뭔가를 놓치고 있니?

환경 : 특정 낮은 수준의 차단 명령으로

java -version 
java version "1.6.0_31" 
Java(TM) SE Runtime Environment (build 1.6.0_31-b04) 
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

출처

2012-10-19 Kalpesh Patel

'unpark'를 호출하면 스레드가하는 일이 거의 없습니다. "추적 결과가 정확히 반대되는 결과"라는 것은 무엇을 의미합니까? 추적은 아마도 메소드 내에서 소비 된 시간을 측정합니까? '공원 '은 차단 방법이므로, 그 안에 시간이 낭비되지 않습니다. –

@MarkoTopolnik 스레드는 다른 것들도합니다. 기본적으로 생산자/소비자 문제. 생산 작업을 생산하여 대기열에 제출하고 대기중인 소비자에게 알립니다. 소비자는 업무에 종사하며 공원 자체보다는 업무가 가능하지 않습니다. –

'unpark'를 호출하는 스레드는 스레드가 unpark되지 않습니다. 그 스레드는 실제로 적절한 소비자 스레드를 해제하는 것 외에는 거의 작업을 수행하지 않을 수 있습니다. '공원'의 CPU 시간은 a) 차단으로 인해 측정하기가 어렵고 b) 주차 상태에서 소요 된 실제 시간의 중요하지 않은 부분이므로 관련성이 없습니다. –

/쓰기/공원 /는이 작업이 차단 될 때 실제로 CPU를 소비하는 가정으로 추정 통해 "CPU"시간이 잠금 읽을 수있다. unpark/park가 모두 높다는 사실은 문제가 있음을 암시하지만, 두 비율 중 낮은 값을 추정치로 사용해야한다고 생각합니다.

출처

2012-10-19 11:58:31

높은 CPU 시간이 Unsafe.unpark 일 때 컨텍스트 스위칭의 부호가 과도합니다. 다음은 컨텍스트 스위치가 얼마나 고가의 아이디어를 얻을 수있는 기사는 다음과 같습니다

How long does it take to make a context switch?

리눅스에 CS 수를 찾는 가장 쉬운 옵션은 vmstat <seconds> 실행됩니다.

높은 CS가 확인되면 (예 : 코어 당 초당 10K 스위치/초당) 문제의 스레드 (CPU 시간 기준으로 YJP의 스레드를 정렬 할 수 있음)를 실행하고 strace -p <pid> -c을 실행하여 전환 원인을 찾습니다. 쓰레드가 소켓에서 작은 조각으로 읽히고 꺼지는 경우 소켓 버퍼를 늘리면 도움이 될 수 있습니다.

출처

2015-04-02 13:47:13

park/unpark의 CPU 사용률이 60 % 인 이유는 무엇입니까?

답변

관련 문제