#History with External MariaDB is extremely slow
1 messages Β· Page 1 of 1 (latest)
What are the MariaDB settings? What hardware is it hosted on? What's top -co%CPU look like on that hardware? How large is the database/tables? Is MariaDB running on the same host as HA? If not, how are they connected? How much data and what kind are you requesting? Why are you not using SQLite? There's butt load of variables.
Running on N150 in Proxmox,
Running mariadb because SQLITE was even slower as heck as well as that I wanted to have much longer data retention and because have some other applications using mariadb
For instance when I am requesting 2 weeks of data its already crunching gears
The current hardware settings
I forgot I put out this thread, my apologies π
And MariaDB
Note that modifying purge_keep_days is generally not a good idea. In my experience things become slow at a certain size (1g+) no matter which recorder database you use. Due to long term stats it's also not needed: https://www.home-assistant.io/blog/2023/12/06/release-202312/#history-dashboard-showing-long-term-statistics
Use InfluxDB/VictoriaMetrics if you need highly granular statistics.
2 Sockets is wrong for the N150. kvm64 is also a poor and slow choice. Either use host or AES v2.
Ahhh that was all set by the helper-scripts script I used
.raw disks are a bad idea and slow too: https://gist.github.com/Impact123/3dbd7e0ddaf47c5539708a9cbcaab9e3#why-not-use-local-for-guest-disks
Seems like you have it on network storage too π
How large is the database? How large is buffer pool size? You usually want to have all the data in RAM.
I dont have access to it right now but I haven't done changes to the database, just purely logged it in into the recordersettings which did all the creation for me
Yes its on network storage poor beelink is running out of space while my NAS is doing nothing but plex π
Cool I'll read this through when I have the time
Go here and select System Information at the top right: https://my.home-assistant.io/redirect/repairs/
Then share the recorder info at the end there.
It was just annoying that I wanted to compare long term data, example; what was the commute time last year/month/week around this time
It wasn't there
The issue is all your settings are kind of bad π
Not everything goes into the Long Term stats but you can customize entities to go there. Just depends what you store exactly.
Check! It was all default settings done by the helper-scripts so that explains why,
I wanted to go about optimizing it all this weekend in any case because I keep running into issues due to numpy
The recorder database is very inefficient for storing this kind of data. LTS summarizes it and makes it manageable.
Right now tho I think I am at 15gbs of data?
Then you probably want to give the Database 16G of RAM and modify its settings accordingly.
Wuuuuuffff okay. Thats 100% of ram π
I'd first check if the recorder data goes into LTS or not though. You can likely just reduce the purge days to the default.
Sooo, first of, home assistant side,
You mentioned the 2 sockets are wrong?
And the HOST or AES V2, which one would you recommend?
If you go to node > Summary you can see the CPU layout of your node.
Ahhhhhhhhhhhhh 4 cores 1 socket
Makes sense
For a N150 just give the VM 2 to 4 cores and use host or the default AES v2 model.
Only recently migrated to proxmox, have been rawdogging raspberry pi's for the past what, 4 years? π
I generally always give at least 2 cores to things. Over allocating is fine. You don't limit a process on your PC to a core either, right?
Yeah, its not doing a whole lot at the moment other than that
Ur correct π
This is already great advice π₯°
I give frigate a core and a 0.5 CPU limit to reduce its overall usage for example. Opengrok too. The rest just get what they need with sane minimums.
For a VM if you give it 4G then you can consider it gone. The VM will use it for caches and such. For a CT it will only use what it actually needs as the kernel is shared with it. It's just a fancy isolated process.
Yeah the ram on hass was constantly bumping into 100% so I kept upping it
It was already a godsend going from 2gb to 4
I gave my VictoriaMetrics CT 32G and 8 cores for example. It only temporarily needs that if I go back years in grafana. A VM would be a bad idea here.
π
Ok changed it, hope it doesn't break so the household doesn't get upset π
If it's just a single node you can use host too.
Yeah, more nodes will be added later down the road
But yknow, ram prices π
So, mariadb size I'll have to take a look at buffersize
You can also try this: https://github.com/major/MySQLTuner-perl
It already seems a bit faster, or its just placebo
Thanks! Now I can finally also update whisper and piper π
People on the internet are quite contradicting about .raw vs .qcow2
Ok.. strange, I gave the MariaDB LXC 40GBs but the container only tells me theres 20GB total available..
But this of course is more of a proxmoxproblem than a hass problem π
Which is now also fixed.
My point is to use neither. If you have to use file based disks pick QCOW2 as it supports thin provisioning and snapshots.
The best is a raw block volume. ZFS or LVM-Thin.