Am 4. April 2020 14:53:17 MESZ schrieb calder <calder....@gmail.com>:
>On Fri, Apr 3, 2020 at 8:48 PM Mark Boon <mb...@vmware.com.invalid>
>wrote:
>>
>> For the past few months we’ve been trying to trace what looks like
>gradual memory creep. After some long-running experiments it seems due
>to memory leaking when
>> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType,
>_jmethodID*, JNI_ArgumentPusher*, Thread*) is invoked. Somewhere.
>>
>> My environment is Tomcat running a proxy webapp. It does TLS
>termination,  authentication and then forwards the call to local
>services. It doesn’t do much else, it’s a relatively small application.
>>
>> Some (possibly relevant) versions and config parameters:
>> Tomcat 8.5
>> Java 8u241 (Oracle)
>> Heap size = 360Mb
>> MAX_ALLOC_ARENA=2
>> MALLOC_TRIM_THRESHOLD_=250048
>> jdk.nio.maxCachedBufferSize=25600
>>
>> We couldn’t find any proof of memory leaking on the Java side.
>> When we turn on NativeMemoryTracking=detail and we take a snapshot
>shortly after starting, we see (just one block shown):
>>
>> [0x000003530e462f9a] JNIHandleBlock::allocate_block(Thread*)+0xaa
>> [0x000003530e3f759a] JavaCallWrapper::JavaCallWrapper(methodHandle,
>Handle, JavaValue*, Thread*)+0x6a
>> [0x000003530e3fa000] JavaCalls::call_helper(JavaValue*,
>methodHandle*, JavaCallArguments*, Thread*)+0x8f0
>> [0x000003530e4454a1] jni_invoke_static(JNIEnv_*, JavaValue*,
>_jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)
>[clone .isra.96] [clone .constprop.117]+0x1e1
>>                              (malloc=33783KB type=Internal #110876)
>>
>> Then we run it under heavy load for a few weeks and take another
>snapshot:
>>
>> [0x000003530e462f9a] JNIHandleBlock::allocate_block(Thread*)+0xaa
>> [0x000003530e3f759a] JavaCallWrapper::JavaCallWrapper(methodHandle,
>Handle, JavaValue*, Thread*)+0x6a
>> [0x000003530e3fa000] JavaCalls::call_helper(JavaValue*,
>methodHandle*, JavaCallArguments*, Thread*)+0x8f0
>> [0x000003530e4454a1] jni_invoke_static(JNIEnv_*, JavaValue*,
>_jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)
>[clone .isra.96] [clone .constprop.117]+0x1e1
>>                              (malloc=726749KB type=Internal #2385226)
>>
>> While other blocks also show some variation, none show growth like
>this one. When I do some math on the number (726749KB - 33783KB) /
>(2385226 – 110876) it comes down to a pretty even 312 bytes per
>allocation.
>> And we leaked just under 700Mb. While not immediately problematic,
>this does not bode well for our customers who run this service for
>months.
>>
>> I’d like to avoid telling them they need to restart this service
>every two weeks to reclaim memory. Has anyone seen something like this?
>Any way it could be avoided?
>
>I'm a bit confused. Your stated title is "JNI Memory Leak?"
>Tomcat, to my intimate knowledge, does not use JNI (correct me if I'm
>rwong)
>( quick check
> user@stimpy:~/Desktop/tomcat-source/apache-tomcat-8.5.53-src> find .
>-name *.c -ls
> user@stimpy:~/Desktop/tomcat-source/apache-tomcat-8.5.53-src> find .
>-name *.cpp -ls
> user@stimpy:~/Desktop/tomcat-source/apache-tomcat-8.5.53-src> find .
>-name *.asm -ls
> user@stimpy:~/Desktop/tomcat-source/apache-tomcat-8.5.53-src> find .
>-name *.pas -ls
>}
>
>a) for the "snapshots" provided, there is NO reference to their
>association, ie, "what" code are those related to?
>b) could you run Mission Control or jvisualvm to locate a stack trace
>for this?
>
>We have two apps that use JNI and run via Tomcat (and another app
>server) - one is "so old" that it is limited to 32-bit ..... the one
>memory leak we have encountered was related to the "native side" (for
>us, the native-compiled Pascal side of things (we also use Assembly
>code) via Java's JNI code).
>
>So, ultimately, I'm confused why we think Tomcat is "to blame" as
>there is no evidence it uses JNI.
>It's my experience JNI memory issues are related to the Java JNI or
>proprietary native code.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

Hi,

I think jni is used via apr in tomcat.

Do you use apr http connector?
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to