Slowness in Performance of ElasticSearch/Kibana

I am running elasticsearch and kibana at V9.2.0:

and have datasets that are very small:

I am using edge with Kibana and I notice as more documents have been loaded that I can refresh the webpage (using edge refresh button) and it can take up to 30-45s to load the page again. It never used to take this long.

The server is linuxmint pretty fully uptodate running in VMware workstation 17.5 with 4 CPUs and 32GB of RAM. The laptop features a 13700H with 96GB of RAM and 990 Pro SSDs. I was not expecting this slowdown so early on. I was wondering if anyone had any ideas on this ?

What I have done is load the following settings for JVM this afternoon:

-Xms8g
-Xmx8g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=30
-XX:G1HeapRegionSize=4m
-XX:ConcGCThreads=2
-XX:ParallelGCThreads=4
-XX:+UseStringDeduplication
-XX:+UnlockExperimentalVMOptions
-XX:G1ReservePercent=15
-XX:+AlwaysPreTouch

and restarted elasticsearch. I was wondering if anyone has any ideas for performance improvement over and above what has been tried. It is probably too soon to know if these changes above are worthwhile but I’m thinking the use of the G1GC might be the main thing of benefit here.

Geoffrey Brown, Te Puke, NZ.

Hi @geoffrey

Apologies,

It's not clear what the actual issue is..

Exactly what page are you loading / refreshing?

Are you running Discover?

Are you just talking Loading Kibana home page

Are you searching documents?

Is Kibana on the same host?

If you try Firefox are you seeing the same thing?

So Im just doing some pie charts and graphs from the timeframe 22 Sep till now so will be retrieving date from the dmarc_aggregate-2025-09 (3k/1.4MB) and dmarc_aggregate-2025-10 (8k/2.4MB) indexes. The output is below:

If I click the edge refresh button (not the refresh in kibana) then this is where I can get the delay redrawing the screen. Its a custom dashboard with nothing too exceptional going on in my opinion:

Yes just loading Kibana dashboard I have created. Yes to document searching as there is an ES|QL query at top that selects a subset of the data and the tables also have columns that are not displayed but effectively filter the data I am interested in. Very basic however.

On the linux desktop all looks normal:

I will try firefox tomorrow for viewing and changing dashboard in Kibana and see how it goes. I just tried edge and firefox now and both are responsive. The delay was happening occasionally in edge (the 30-45s). Not all the time. When updates to the dmarc indexes happen it will typically be <10 docs added. The worst number of documents added to an index at one time would be 350 - small numbers.

Many thanks…

Geoffrey.

Since you’re running a single node cluster many things will not go as planned.

  • Can you return cluster health api ?

The truth is it shouldnt matters for a small dataset like this, but let’s try to focus on potential overheads limits.

  • VM itself what is writing / using IO
  • How is the storage configured ?
    • Hardware SSD (AHCI, TRIM and guest OS config)
    • VM configuration
    • Virtualized System configuration

You should try to play with fio utility and check if you have abnormal values for SSDs i’ve ran countless lab clusters on 990s Pro and shouldnt be an issue :wink:

I think for cluster health this is what you are wanting ?

Hardware SSD is Samsung 990 Pro 4TB x 2. Using the second (non OS) drive for VM. In Linux disk appears as ext4:

FIO write test (the takeaway seems to be ~1.3GB/s):

And for reads seems to me to get 1.4GB/s:

uname -a:

Linux linuxmint 6.8.0-85-generic #85-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 18 15:26:59 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Does that help @grumo35 ?

Many thanks…

Hi @geoffrey

I'm still a bit confused whether you're saying that reloading the entire Kibana app is slow since you're running a refresh on edge..

Or you're saying when you refresh your dashboard it's slow..

The first is all about pulling down the whole kibana app, Not really my expertise

With chrome or Firefox you can open the dev tools and see what's taking the longest from the network and load and render perspective.

The second just refreshing the dashboard is about how long the queries take, which you can inspect the queries and see which ones are taking long and you could even put them in the profiler.

1 Like

In addition to what others have written:

I have nothing specifically against those settings, but you also wrote:

without really providing any evidence? What makes you think this? Is there something in one of the gc.log files?

Generally I’d suggest to start with the OOTB settings, tune the heap sizes maybe, and only change other stuff based on experience or some specific evidence.

Also:

You can also set the dashboard to auto-refresh on a specific interval, or click the dashboards own refresh button?

Your elastic/kibana-running VM (they are both running in same VM?) is the only VM running on the laptop ? The laptop’s itself is doing anything interesting, aside from running Edge?

As well as other suggestions, when it’s slow, please try to get dump of the hot threads /_nodes/hot_threads if you can, via curl if necessary. And maybe snapshot of “top” output on both VM and host (or equivalent of top).

Of advice given, I’d do this first:

btw Edge has much the same thing too - Click the three dots → More Tools → Developer Tools.

In passing, you might wish to set the 2 indices that seem to have an unallocated replica to have 0 replicas, a GET on _cat/indices should show you which, just to get cluster state to green.

Good luck!

Your elastic/kibana-running VM (they are both running in same VM?) is the only VM running on the laptop ? The laptop’s itself is doing anything interesting, aside from running Edge?

Yes elastic and kibana are running in the same VM. Only this one VM running on laptop and using the same laptop for MS Edge browser.

What I have done is moved the VM from my laptop to an Intel NUC and upgraded to V17.6.1 from V17.5 of VMware Workstation. Also changed the VM config to 8 processors (from 4) and left at 32GB RAM. Ever since I have done this using the edge refresh button to update the browser is consistently fast. Having said that, ever since the changes to the JVM config, whilst still running the VM on my laptop, I didn’t see the long delays in webpage refresh.

Anyway, on this Intel NUC (12th Gen), I have also setup metricbeat on the linux mint guest and this is reporting back to the same elastic DB. I figured with this metricbeat history I can perhaps do some more diagnosis if the issue rears its head again as metrics related to the garbage collection come through in the metricbeat data.

Geoffrey Brown, Te Puke, NZ.