Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Requirements: 
Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODINVOICE-101
Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODORDERS-311
Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODORGS-45

...

Deep analysis of the memory utilization was performed with using Eclipse Memory Analyzer on the basis of memory dumps prepared in advance during the operation of the service (after 1 hour of service operating).

Issues Found

JMX reporting based on Dropwizard metrics

Description

The heap memory size is constantly increasing under load, reaches the maximum value for the container and a service failure occurs. The service does not recover after a load disconnect.

Detailed investigation

Emulation of the load on local environment showed the following results:

mod-invoice-storage:

Image Modified

mod-invoice:

Image Modified

It should be noted that the memory growth trend is observed for both of mod-invoice and mod-invoice-storage modules. However, for the mod-invoice-storage  the process is more intensive. Therefore, invoices flow failure occurs at the mod-invoice-storage layer.

Heap dumps: mod-invoices.hprofmod-invoices-storage.hprof.

Heap dumps analysis showed that problem relates to Dropwizard metrics collecting.

Image ModifiedImage Modified


After manual disabling of metrics collecting load test passes successfully with the following CPU/Heap utilization during 4 hours:

mod-invoice:

Image Modified

mod-invoice-storage:

Image Modified

Heap dumps analysis showed that issue was fixed.

Summary

Disable Dropwizard metrics on production environment. For this purpose, it makes sense to refactor the existed existing code to exclude the hardcoded enabling of the metrics RestLauncher.java#L30. Moreover, Vert.X supports the enabling of metrics collecting as a key of the Java command line, so the possibility of its enabling can be saved if command line activation is used.