Opened 4 years ago

Closed 3 years ago

#451 closed defect (fixed)

Profile petascope regarding RAM usage

Reported by: dmisev Owned by: pcampalani
Priority: major Milestone: 9.0.x
Component: petascope Version: 8.5
Keywords: Cc: damiano, pbaumann, mantovani, pcampalani
Complexity: Medium

Description

It seems like petascope/tomcat is using quite some memory after many WCS requests. We should check for memory leaks and the like by e.g. monitoring with top and the NetBeans? profiler during a session of 1000 queries sent to petascope. These queries could come from the wcs/wcps tests in the systemtest.

Attachments (4)

eobstest-avg1.png (18.8 KB) - added by dmisev 3 years ago.
first query after tomcat restart
eobstest-avg2.png (19.8 KB) - added by dmisev 3 years ago.
second query repeated after tomcat restart
petascope_heap_WCS10x.png (50.9 KB) - added by pcampalani 3 years ago.
Heap profile for 10 consecutive WCS systemtest runs.
petascope_heap_WCPS5x.png (38.4 KB) - added by pcampalani 3 years ago.
Heap profile for 5 consecutive WCPS systemtest runs.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 3 years ago by dmisev

  • Owner changed from nkolev to pcampalani
  • Status changed from new to assigned

comment:2 Changed 3 years ago by pcampalani

  • Status changed from assigned to accepted

I'd put in this ticket the profiling of performances too.

comment:3 Changed 3 years ago by dmisev

I profiled a simple query

for c in (eobstest)
return avg(c)

The first run loses a lot of time on CRS parsing and checking, but second time caching already fixes that as it seems.

Attached the results.

Changed 3 years ago by dmisev

first query after tomcat restart

Changed 3 years ago by dmisev

second query repeated after tomcat restart

comment:4 Changed 3 years ago by pcampalani

Good that the caches work fine, but still the RasQL execution represents a 60% of the overall response time: ideally I'd say it should be around 80%.

comment:5 Changed 3 years ago by dmisev

I think it's still reasonable, note that the rasql will take significantly more on more complex queries. It's not so critical to optimize it to death. But it would be good to check on the memory usage.

comment:6 Changed 3 years ago by pcampalani

Looking at the absolute times anyway, we're in the ms scale. On a tougher query the RasQL time increases while Petascope overhead should be fixed.

Changed 3 years ago by pcampalani

Heap profile for 10 consecutive WCS systemtest runs.

Changed 3 years ago by pcampalani

Heap profile for 5 consecutive WCPS systemtest runs.

comment:7 Changed 3 years ago by pcampalani

I made a preliminary general profiling of the heap usage of Petascope by running WCPS and WCS tests several times (5x and 10x respectively).

Looking at the telemetry plots, I generally see a stable behavior, WCS queries eating a little more memory as expected (~150 MB versus ~120MB for WCPS).

Comments/ideas?

Let me know if I should proceed with more detailed (objects/snapshots) profiling.

comment:8 Changed 3 years ago by dmisev

Would be good to profile the GetCapabilities issue to see where the time is mostly spent.

Not sure if you've tested for memory leaks specifically?

comment:9 Changed 3 years ago by pcampalani

Yes, the surviving generations' count is stable throughout the run, so there does not seem to be any leak.

Good idea: I'll profile the GetCapabilities (for #735 too).

comment:10 Changed 3 years ago by pcampalani

Regarding the issue of the GetCapabilities performance, refer to #735 and m-list for discussions.

comment:11 Changed 3 years ago by dmisev

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.