Forgot to mention, we are running hammer.
I'm not expecting anything super fast with this setup but 30MB/sec read is horrible.
The rbd pool has a replica of 2 not 3
The weights are set based on their size (Proxmox does this by default) so you can easily ascertain their sizes by looking at the...
Yes, also tried krbd. Both of those seem to help but very little.
Thanks for the help, let me know if you need more info.
# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable...
There is another unsolved thread with similar issue. https://forum.proxmox.com/threads/slow-backups.25065/
That user did not have issues when the backup was written to a local disk, only when written to nfs.
If you backup to a local disk, does your problem go away too?
7 mechanical disks in each node using xfs
3 nodes so 21 OSDs total
I've started moving journals to SSD which is only helping write performance.
CEPH nodes still running Proxmox 3.x
I have client nodes running 4.x and 3.x, both have the same issue.
Using 10G IPoIB, separate public/private...
Can you change configuration then restart mons, osds and vms?
Or do you need to stop all vms, stop osds and mons, change configuration and start everything back up?
Anyone tried setting up lvm cache? Its a fairly new cache tier based on dm-cache
Theoretically we should be able to add an SSD cache to any logical volume that Proxmox has created for VM disks.
It supports writethrough and writeback cache modes.
With writethrough no data is lost if the cache...
Live migration never worked properly in OpenVZ so it might as well have not existed there either.
Seeking help on OpenVZ forum was useless:
https://forum.openvz.org/index.php?t=msg&th=10595&goto=45480
A couple years ago I came to the realization that OpenVZ was going nowhere so I migrated all...
Here someone mentions that they mount NFS backup storage backed by zfs with specific options:
https://forum.proxmox.com/threads/nfs-mount-share-recommendations-can-proxmox-create-a-wiki-entry-for-nfs.18301/#post-93367
No idea if that would help you but if you tried this you would likely want a...
I've not messed with NFS for a long time so I can't really suggest anything specific, just some things to research on your own.
Look into Jumbo Frames, increase MTU, NFS mount options: rsize, wsize and noatime.
I believe that once you make the changes to /etc/hosts that q-wulf mentions you can simply reboot all your nodes and things should work ok.
Last time I changed the network after setting up clustering was many years ago back in Proxmox 1.X and thats how I did it.
No idea if anything has changed...
vzdump supports hook scripts, I bet you could write one to mount a backup filesystem from some FC volume.
Here is one of my hook scripts.
At the beginning of the backup it ssh to another server to mount an encrypted disk then mount that disk locally using SSHFS.
When backing up individual...
Those other tests do not perform the exact same IO patterns that the backup process performs so while helpful they are not conclusive. The particular IO patterns created by the backup process might perform better by changing some NFS mount option. Or maybe the backup process would perform better...
You established that you can write to the nas at a reasonable speed and writing locally did not seem to make a difference. I'd conclude that its not an IO writing issue.
The proxmox backup reads the vm disk through the kvm process, if the guest OS can read quickly then vzdump should read...
I agree with this and also feel the mobile version requires excessive vertical scrolling. It would be great if you could invest some time into improving the template to reduce the need for scrolling.
Is your VM doing IO during the backup?
Did you try backing up to local storage without the tmp folder option? It would be really helpful to know the results of that test.
Is it possible to log into the nas and monitor its IO during a backup? Like running "vmstat 1" in the nas itself. I'd be...
I suspect that backing up to the same system where your images are stored is why its so slow.
Its demonstrated really well in your log files, when you write little data to the backup file your reads are high, when you write lots to the backup file your reads are low:
Faster reads, lower writes...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.