SAP VM_STACK_TRACE: java.lang.OutOfMemoryError:Failed to allocate 546152 bytes when copying a shared closure

[Former Member]

Dear experts,

we use a customer report to create a large amount of invoices at once. During out last invoice run, the system ended the processing with a shortdump VM_STACK_TRACE.

After we've reported it and get a parameter recommendation from SAP we've tried it again. Result is the same shortdump.

The recommended parameters were:

vmcj/option/maxJavaHeap = 1024
vmcj/option/percentageYoungGen = 10
vmcj/option/percentageMinOldGen = 5

An extract from the VM_STACK_TRACE:

Dump of Virtual Machine V4 in Workprocess W48

Short Error Description: RFC Server (in-process) stopped, java.lang.OutOfMemoryError:Failed to allocate 546152 bytes when copying a shared closure, termi

Last Error Info of VMC

RFC Server (in-process) stopped, java.lang.OutOfMemoryError:Failed to allocate 546152 bytes when copying a shared closure, termi

> Java error

Last Error Message of VMC (Area=14, Number=304)

Error occurred during program execution

Here are the technical infos of the VM V4:

<4> Field                                      Value

<4> _____________________________________________________________________________________

<4>

<4> Handle                                     4

<4> state                                      RUNNING

<4> internalState                              DP_VMC_INT_O_K

<4> waitReason DP_VMC_WAIT_RES_NO_REASON

<4> type                                       REM

<4> vmSubType DP_VMC_SUBT_RFC_IP

<4> vmcId {577FD8EB-52DB-25ED-E100-0000AC190A0F}

<4> wp                                         48

<4> last_wp                                    48

<4> last_rq_id                                 rq_id 51594982

<4> attachedInWp                               48

<4> attachedWpPid                              5891

<4> sessionInfo T161_U25217_M0_I2

<4> associatedSesEntry                         0

<4> contextHdl[0]                              2

<4> contextHdl[1]                              3

<4> contextState DP_CONTEXT_ATTACHED

<4> local classes                              19.22 KB (19680 bytes)

<4> local classes (allocated)                  8.00 MB (8388360 bytes)

<4> local code                                 8.00 MB (8388648 bytes)

<4> local code (allocated)                     16.00 MB (16776968 bytes)

<4> local peers                                481.69 KB (493248 bytes)

<4> local peers (allocated)                    8.00 MB (8388360 bytes)

<4> local guarded mem                          4.25 MB (4457088 bytes)

<4> local guarded mem (allocated)              8.00 MB (8388360 bytes)

<4> local temp. data                           0 bytes

<4> local temp. data (allocated) 0 bytes

<4> local volatile data                        0 bytes

<4> local volatile data (allocated)            0 bytes

<4> local profiling data                       178.17 KB (182448 bytes)

<4> local profiling data (allocated)           8.00 MB (8388360 bytes)

<4> local misc                                 9.78 MB (10251688 bytes)

<4> local misc (allocated)                     16.00 MB (16776720 bytes)

<4> total memory                               22.69 MB (23792800 bytes)

<4> total memory (allocated)                   64.00 MB (67107128 bytes)

<4> java heap                                  1024.00 MB (1073738752 bytes)

<4> shared classes                             48.59 MB (50951416 bytes)

<4> shared classes (allocated)                 81.91 MB (85890058 bytes)

<4> shared classes (allocated Peak)            81.91 MB (85890058 bytes)

<4> shared equ. classes                        0 bytes

<4> shared equ. classes (allocated)            0 bytes

<4> shared equ. classes (allocated Peak)       0 bytes

<4> shared code                                18.35 MB (19238336 bytes)

<4> shared code (allocated)                    32.00 MB (33554432 bytes)

<4> shared code (allocated Peak)               32.00 MB (33554432 bytes)

<4> shared data 68.07 MB (71374952 bytes)

<4> shared data (allocated)                    112.14 MB (117592376 bytes)

<4> shared data (allocated Peak)               112.14 MB (117592376 bytes)

<4> shared data small                          101.43 MB (106359080 bytes)

<4> shared data small (allocated)              202.21 MB (212035720 bytes)

<4> shared data small (allocated Peak)         202.21 MB (212035720 bytes)

<4> shared cpy only data                       3.06 MB (3205000 bytes)

<4> shared cpy only data (allocated)           10.24 MB (10737418 bytes)

<4> shared cpy only data (allocated Peak)      10.24 MB (10737842 bytes)

<4> shared cpod small                          124.80 KB (127792 bytes)

<4> shared cpod small (allocated)              2.93 MB (3077192 bytes)

<4> shared cpod small (allocated Peak)         2.93 MB (3077192 bytes)

<4> shared admin                               36.24 KB (37112 bytes)

<4> shared admin (allocated)                   7.15 MB (7499776 bytes)

<4> shared admin (allocated Peak)              7.15 MB (7500200 bytes)

<4> shared misc                                29.19 MB (30604320 bytes)

<4> shared misc (allocated)                    177.31 MB (185923647 bytes)

<4> shared misc (allocated Peak)               183.77 MB (192698559 bytes)

<4> total global memory                        268.84 MB (281898008 bytes)

<4> total global memory (allocated)            625.91 MB (656310619 bytes)

<4> total global memory (allocated Peak)       632.37 MB (663086379 bytes)

<4> gc old gen filled                          100.00 %

<4> number of threads                          10

<4> avg stack size per thread                  435.26 KB (445708 bytes)

<4> systemTimeMicros                           0:00:15.130000 (h:mm:ss.us)

<4> userTimeMicros 0:14:34.080000 (h:mm:ss.us)

<4> total time                                 0:14:49.210000 (h:mm:ss.us)

<4> creationTime                               Mon Jul 11 17:00:08 2016

<4> lastUsedTime                               Fri Jul 15 19:27:18 2016

<4> pool_time                                  Fri Jul 15 19:26:54 2016

<4> attachCount                                2733

<4> controlsCheckedCount                       42567

<4> actRequestInfo                             0x4

<4> ..actRequestInfo                           DP_VMC_SUBT_RFC_IP

<4> java_adm                                   7fcaa22c1160

<4> java_proxy_tbl_hdl                         (nil)

<4> java_stack_hdl                             1

<4> globals                                    7fcaa22e9658

<4> vm_state DP_JAVA_VM_ATTACHED

<4> vmcFdOfServ[DP_VMC_SUBT_WEB]               -1

<4> vmcThreadOfServ[DP_VMC_SUBT_WEB]           -1

<4> vmcFdOfServ[DP_VMC_SUBT_RFC]               9001

<4> vmcThreadOfServ[DP_VMC_SUBT_RFC]           6

Do you have any ideas for the correct parametrization?

Our problem is that we can't test our invoice run. So we have to test it on a productive run which executed twice a month.

Thanks in advance.

Best regards,

Paul

[raquel_gomez]

Hi Paul,

The java.lang.OutOfMemoryError error points to shortage on the size of the Java Heap area, defined by parameter 'vmcj/option/maxJavaHeap'.

This is a common problem if an application puts too much data into the heap. The dumps is thrown because there is no more available Java Heap and the application that is being executed needs more.

Problem can be solved by increasing parameter 'vmcj/option/maxJavaHeap' accordingly to application needs. When increasing the java heap, you need also to modify the value of the percentage parameters, based on formulas:

   vmcj/option/percentageYoungGen ~ (100M / vmcj/option/maxJavaHeap) * 100%

   vmcj/option/percentageMinOldGen ~ vmcj/option/percentageYoungGen / 2

Also check that Note 1083358 - VMC: Recommendations for parameter settings is followed.

Regards,

Raquel

[Former Member]

Hi Raquel,

thanks for your reply.

We've increased already our parameter to

vmcj/option/maxJavaHeap = 1024
vmcj/option/percentageYoungGen = 10
vmcj/option/percentageMinOldGen = 5

after we get the same error message in sm52, , java.lang.OutOfMemoryError:Failed to allocate 546152 bytes when copying a shared closure,... last time.

How can it be to failing "only" and exactly 546152 bytes and failing them again after increasing the mentioned values from 200 to 1024 and the percentage values?

Unfortunately our application team and myself can't give a specification how big the pdf files were. Our spools have been reorged already. We've also no possibilty to test our invoice run which runs twice a month. I've just talked with our CRM consultants to catch up the file sizes on the next run this friday.

Maybe we'll get some more information to estimate the correct values. I'll update this discussion with the pdf file sizes next monday. Until then I want try to understand the missing 0,5MB which the system couldnt alocate and also like mentioned, even after increased maxJavaHeap from 200 to 1024 already?!?!

Best regards,

Paul

[Former Member]

Hi,

as announced, here the file sizes from our last splitted invoice run last friday.

PJIDENT

PJSIZE

   17.076   2.200.904

   17.079   2.233.400

   17.083   2.624.640

   17.374   2.225.637

   17.377   2.227.116

   17.380   2.291.931

   17.424   2.369.920

   17.426   2.349.086

   17.429   2.332.594

   17.432   1.749.201

If we do not split we get the outofmemory, see above...

Best regards,

Paul

[raquel_gomez]

Hi Paul,

The error java.lang.OutOfMemoryError is caused by shortage of the size of the Java Heap area, and there's no other option to avoid it appart from increasing relevant parameter 'vmcj/option/maxJavaHeap' (remeber to adjust 'vmcj/option/percentageMinOldGen' and 'vmcj/option/percentageYoungGen' accordingly).

As mentioned, this is a common problem when the application puts too much data into the heap area. You could also chek from application side.

Regards,
Raquel