camel-quarkus
camel-quarkus copied to clipboard
memory increase in camel quarkus
Bug description
Hello friends, your support in this concern, I have a microservice made in Quarkus Camel, I want to do profiling and I see that the application, just by starting it without testing request or anything, begins to consume memory, reaching approximately 250 and then it drops to 100 and the same process is repeated. cycle, is this normal in camel quarks?
I heard something about the camel event cycle but I don't know if it is related to this, I left the image of the application
a microservice made in Quarkus Camel
Please can you provide some more details?
- Which version of Quarkus is used?
- Which extensions do you use?
- What does the Camel route configuration look like?
hi @jamesnetherton add the details
<quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
<quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
<camel-quarkus.platform.group-id>${quarkus.platform.group-id}</camel-quarkus.platform.group-id>
<camel-quarkus.platform.artifact-id>quarkus-camel-bom</camel-quarkus.platform.artifact-id>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.testTarget>${maven.compiler.target}</maven.compiler.testTarget>
<maven.compiler.testSource>${maven.compiler.source}</maven.compiler.testSource>
<formatter-maven-plugin.version>2.23.0</formatter-maven-plugin.version>
<impsort-maven-plugin.version>1.9.0</impsort-maven-plugin.version>
<license-maven-plugin.version>4.2</license-maven-plugin.version>
<maven-compiler-plugin.version>3.11.0</maven-compiler-plugin.version>
<maven-jar-plugin.version>3.3.0</maven-jar-plugin.version>
<maven-resources-plugin.version>3.3.1</maven-resources-plugin.version>
<maven-surefire-plugin.version>3.1.2</maven-surefire-plugin.version>
</properties>
class route
/*
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
http://www.apache.org/licenses/LICENSE-2.0 - Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License. */ package org.acme.rest.json;
import java.util.Collections; import java.util.LinkedHashSet; import java.util.Set;
import org.apache.camel.builder.RouteBuilder; import org.apache.camel.model.rest.RestBindingMode;
/**
-
Camel route definitions. */ public class Routes extends RouteBuilder { private final Set<Fruit> fruits = Collections.synchronizedSet(new LinkedHashSet<>()); private final Set<Legume> legumes = Collections.synchronizedSet(new LinkedHashSet<>());
public Routes() {
/* Let's add some initial fruits */ this.fruits.add(new Fruit("Apple", "Winter fruit")); this.fruits.add(new Fruit("Pineapple", "Tropical fruit")); /* Let's add some initial legumes */ this.legumes.add(new Legume("Carrot", "Root vegetable, usually orange")); this.legumes.add(new Legume("Zucchini", "Summer squash"));}
@Override public void configure() throws Exception {
restConfiguration().bindingMode(RestBindingMode.json); rest("/fruits") .get() .to("direct:getFruits") .post() .type(Fruit.class) .to("direct:addFruit"); rest("/legumes") .get() .to("direct:getLegumes"); from("direct:getFruits") .setBody().constant(fruits); from("direct:addFruit") .process().body(Fruit.class, fruits::add) .setBody().constant(fruits); from("direct:getLegumes") .setBody().constant(legumes);} }
this ms is git hub test , can donwload here :
git clone https://github.com/apache/camel-quarkus-examples.git
the test in this applicaction :
Are you profiling the application in dev mode (E.g mvn quarkus:dev)?
@jamesnetherton yes in dev Mode using mvn quarkus:dev .
I made a comparison with an ms in pure Quarkus and this does not present that memory increase problem, it is maintained. I understand we are talking about camel with quarkus that's why my concern
We can investigate. But I'm not sure if profiling in dev mode is particularly meaningful:
https://quarkus.io/guides/dev-mode-differences
If you want to do profiling, it's better to do so when the application is run via the runnable JAR.
You were able to test the application and it was the same with the profiling?. Is the behavior normal?
@jamesnetherton In production I have this behavior from a kubernetes pod that lifts apache camel with quarkus in native mode and I can see this behavior. That's why I decided to profile the ms but I'll have to do the test with java -jar in a non-productive environment and see if it has this behavior.
@jamesnetherton how are you ? have you done any tests
@jamesnetherton how are you ? have you done any tests
I'm good thanks. Sorry, I've had no time to do any real analysis.
Maybe @aldettinger has some insight here as he's investigated performance related issues before.
Hi @brianmolinaspring,
Many thanks for contributing to Camel Quarkus :+1: Trying to summarize there is a microservice implemented with camel-quarkus 3.7.1 that is consuming/releasing memory. The microservice is assumed to be inactive / doing nothing. A peak of 250 MiB of memory is reached every 40 minutes when the garbage collector probably reclaims the memory. So far, this behavior is reproduced:
- in native mode with a microservice deployed on kubernetes
- in dev mode with the rest-json camel-quarkus example
Please amend if above summary is not correct.
The main hytothesis would be that there is actually a bit of activity occurring under the hood. A way to validate this hypothesis would be to collect some information before the memory is reclaimed. Especially collecting a dump of the java class histogram showing the most used classes would be helpful.
Note that investigating in dev mode could be misleading and is not recommended. Investigating in jvm or native mode should help. And most of the time investigating in jvm mode is sufficient to understand what's happening.
hi @aldettinger thanks for your
response, I am currently testing the camel quarkus class that is in the documentation in java -jar mode, it has already been going on for 5 minutes and it does not present the increase in memory. I will leave the print screen attached. then I would understand that this mvn quarkus:dev mode must activate some components that cause the memory to increase, now I am going to try now with my application in this java -jar mode and I see the behavior in my development environment, I am telling you about this through.
Update : the ms is seen to go up but the memory is very little