tiegen

@hagen1778 Thanks for your kindly replying. I just begin transfering to the new vm architecture, and Vmalert needs about 400 CPU utilization on the almost empty storage. I'm a little...

Reloading issue may be affected by lots of rule files. It's now about twice cpu than normal after merging part of rules file. [pprof.zip](https://github.com/VictoriaMetrics/VictoriaMetrics/files/9167201/pprof.zip)

Sorry for the late reply. Here is the profile: [heap.pb.gz](https://github.com/VictoriaMetrics/VictoriaMetrics/files/9186487/heap.pb.gz) I'm using the latest release version: `vmalert-20220714-170947-tags-v1.79.0-0-gd3116d986`

Sorry, I haven't been focusing on this part lately, and just noticed that you have been replying for a long time. In my scenario, there are more than 1000 individual...

Hello, is there any progress? :)

Hello, please let me know when it is released :)

@kcpeppe Sorry to bother you. Do you have plan to fix the issue? If not, maybe i could provide some help. Removing CMSInitialMark from GenerationalHeapParser is the simplest way, right?

@kcpeppe Thank you, I will wait for it to be fixed.

I think the problem maybe caused by this [part](https://github.com/microsoft/gctoolkit/blob/2a57be7c241ebe6364572f48bab48e19512820ce/vertx/src/main/java/com/microsoft/gctoolkit/vertx/DataSourceVerticle.java#L38) , It caused repeat undeploy if several Parser consumes **END_OF_DATA_SENTINEL**. Are these codes duplicate with dataSourceBus.close() ?

> I think the problem maybe caused by this [part](https://github.com/microsoft/gctoolkit/blob/2a57be7c241ebe6364572f48bab48e19512820ce/vertx/src/main/java/com/microsoft/gctoolkit/vertx/DataSourceVerticle.java#L38) , It caused repeat undeploy if several Parser consumes **END_OF_DATA_SENTINEL**. > > Are these codes duplicate with dataSourceBus.close() ? @kcpeppe...