Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potentially Creating Large Amount of String Objects #598

Open
huanggx-sea opened this issue Apr 12, 2021 · 3 comments
Open

Potentially Creating Large Amount of String Objects #598

huanggx-sea opened this issue Apr 12, 2021 · 3 comments

Comments

@huanggx-sea
Copy link

huanggx-sea commented Apr 12, 2021

Hi,

We're using strimzi kafka which uses jmx_exporter as a javaagent to export the metrics to /metrics.

And we find out that Receiver.recordBean under JmxCollector in jmx_exporter keeps creating a large amount of String objects

public void recordBean(...){
    ...
    for(Rule rule:config.rules){
        ...
        String matchName=beanName+(rule.attrNameSnakeCase?attrNameSnakeCase:attrName)+": "+matchBeanValue;
        ...
    }
    ...
}

Arthas shows that recordBean is called about 10k per minute
and config.rules in our case is 21 long, which ends up about 210k String per minute.

And we can see Young GC moving the memory from 6GB to 500MB happens about 12 minutes a time.

In the heap dump, there are lots of:

kafka.server<type=socket-server-metrics, listener=TLS-9093, networkProcessor=29><>expired-connections-killed-count: 0.0
kafka.server<type=socket-server-metrics, listener=TLS-9093, networkProcessor=29><>incoming-byte-rate: 0.0
kafka.server<type=socket-server-metrics, listener=TLS-9093, networkProcessor=29><>request-size-avg: NaN
kafka.network<type=RequestMetrics, name=RequestQueueTimeMs, request=AlterClientQuotas><>98thPercentile: 0.0
...

which seems to be the content of matchName here.

Any idea how to fix this problem?
Many Thanks.

@fstab
Copy link
Member

fstab commented May 2, 2021

Hi, thanks a lot for your analysis. I will certainly look into it as soon as time allows. Meanwhile, if you have a proposal how to reduce the number of strings, please post it here for discussion or create a PR.

@huanggx-sea
Copy link
Author

Hi, thanks for your reply! To be honest, we don't have much experience in in Java programming.

I'm not sure whether we can use the same memory space for the String matchName in the inner loop

for(Rule rule:config.rules){
        ...
        String matchName=beanName+(rule.attrNameSnakeCase?attrNameSnakeCase:attrName)+": "+matchBeanValue;
        ...
}

This would at least make the number of String not proportional to the number of rules.

@dhoard
Copy link
Collaborator

dhoard commented Jul 4, 2023

This logic was changed slightly in 0.19.0 so that the attribute snake case name is only created if required by the rule.

if (rule.attrNameSnakeCase) {
attributeName = toSnakeAndLowerCase(attrName);
} else {
attributeName = attrName;
}

@huanggx-sea can you retest using 0.19.0?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants