BUG Memory leak when use agent
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 25/100
- Type d'issue
- Bug
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- java
- Domaine
- observability-sre
Piste de recherche
Commencez par l’appel à PyroscopeAgent.start et suivez la gestion par l’agent des instantanés répétés ainsi que l’implémentation personnalisée de GalileoProfileExporter.export. Reproduisez le rapport avec la configuration 0.12.0 fournie et surveillez la mémoire pendant l’exécution des téléversements. Le travail est terminé lorsque la source de l’augmentation persistante de la mémoire est identifiée et que l’agent ne conserve plus de manière inattendue les données de profilage terminées.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
I use 0.12.0 agent upload JFR data to my backend.
<dependency>
<groupId>io.pyroscope</groupId>
<artifactId>agent</artifactId>
<version>0.12.0</version>
</dependency>
Upload code:
Config profileConfig = new Config.Builder()
.setFormat(Format.JFR)
.setLogLevel(Logger.Level.INFO)
.setProfilingEvent(EventType.ITIMER)
.setProfilingAlloc("0")
.setProfilingInterval(Duration.ofMillis(10))
.setUploadInterval(Duration.ofSeconds(5))
.build();
GalileoProfileExporter exporter = new GalileoProfileExporter(resource, DEFAULT_RETRY);
PyroscopeAgent.start(new PyroscopeAgent.Options.Builder(profileConfig).setExporter(exporter).build());
My exporter:
public class GalileoProfileExporter implements Exporter {
private static final Duration TIMEOUT = Duration.ofSeconds(10);
private static final String ENDPOINT = "https://xxxxxxxxxxxxx";
final Ocp.Resource resource;
final int ingestMaxTries;
final Logger logger = new DefaultLogger(Logger.Level.INFO, System.err);
final OkHttpClient client = new OkHttpClient.Builder()
.connectTimeout(TIMEOUT)
.readTimeout(TIMEOUT)
.callTimeout(TIMEOUT)
.build();
public GalileoProfileExporter(Ocp.Resource resource, int ingestMaxTries) {
this.resource = resource;
this.ingestMaxTries = ingestMaxTries;
}
@Override
public void export(Snapshot snapshot) {
final HttpUrl url = HttpUrl.parse(ENDPOINT);
logger.log(Logger.Level.INFO, "Upload profile. %s %s JFR: %s",
snapshot.started.toString(), snapshot.ended.toString(), snapshot.data.length);
byte[] reqBody = constructReqBody(snapshot);
byte[] compressedData = new byte[0];
try {
compressedData = Snappy.compress(reqBody);
} catch (IOException e) {
logger.log(Logger.Level.ERROR, "Error compress snapshot.");
}
MediaType type = MediaType.parse("application/octet-stream");
RequestBody jfrBody = RequestBody.create(compressedData, type);
Request.Builder request = new Request.Builder()
.post(jfrBody)
.url(url);
request.header("language", "java");
try (Response response = client.newCall(request.build()).execute()) {
int status = response.code();
if (status >= 400) {
ResponseBody body = response.body();
final String responseBody;
if (body == null) {
responseBody = "";
} else {
responseBody = body.string();
}
logger.log(Logger.Level.ERROR, "Error uploading snapshot: %s %s", status, responseBody);
}
if (status == 200) {
logger.log(Logger.Level.INFO, "Success upload jfr");
}
} catch (final IOException e) {
logger.log(Logger.Level.ERROR, "Error uploading snapshot: %s", e.getMessage());
}
}
private byte[] constructReqBody(Snapshot snapshot) {
Otp.Profile.Builder profile = Otp.Profile.newBuilder()
.setName("jfr")
.setType("cpu")
.setData(ByteString.copyFrom(snapshot.data));
Otp.ProfilesBatch profilesBatch = Otp.ProfilesBatch.newBuilder()
.setSequence(1)
.setStart(snapshot.started.toEpochMilli() / 1000)
.setEnd(snapshot.ended.toEpochMilli() / 1000)
.setResource(this.resource)
.addProfiles(profile)
.build();
return profilesBatch.toByteArray();
}
}
When I opened the agent report, I found that the memory was constantly rising, and I suspected there was a memory leak situation
Is there anyone who has encountered similar problems with me, or is there a problem with where I wrote it? Thanks
- Langage dominant
- Java
- Étoiles
- 125
- Forks
- 48
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de grafana/pyroscope-java
-
Clean up dead publishing repository config and credentials in subproject build filesPeut-être pris @arnabnandy7 l’a pris il y a 24 jours. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
grafana/pyroscope-java#294 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 54/100
grafana/pyroscope-java#371 · 2 réactions ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
grafana/pyroscope-java#368 · 1 commentaire ·
-
improve asprof extractionOuverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
grafana/pyroscope-java#283 ·
-
libasyncProfiler-linux-x64.so dump in /tmpPeut-être à nouveau libre @korniltsev-grafanista l’a pris il y a 262 jours, et aucune pull request n’est ouverte. Ouverte
grafana/pyroscope-java#250 · 1 commentaire · 1 personne assignée ·
Toutes les issues de grafana/pyroscope-java
Issues similaires
-
approved bug
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
checkstyle/checkstyle#21981 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Build: the CUDA backend fails without cuDNN instead of skipping the cuDNN shim (as the cuDF shim does)Peut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
beehive-lab/TornadoVM#1248 ·
Les mainteneurs répondent en général sous 1 jour
-
good first issue help wanted ready-for-human
Difficulté 2/5 Une demi-journée Accessibilité débutants 64/100
Les mainteneurs répondent en général sous 1 jour
-
bug jdbc-v2
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
ClickHouse/clickhouse-java#3214 ·
Les mainteneurs répondent en général sous 1 jour
-
Java and Kotlin (JVM): parse gradle/wrapper/gradle-wrapper.properties with exact line locationsOuvertearea: detector eco: java help wanted lane: free-agent roadmap size: S type: parser
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
arminazimi/evergreen#355 ·
Les mainteneurs répondent en général sous 1 jour