We don't have thousands but these RBDs are in a pool backed by ~600ish.
I can see the fd count is up well past 10k, closer to 15k when I use a
decent number of RBDs (eg. 16 or 32) and seems to increase more the bigger
the file I write. Procs are almost 30k when writing a 50GB file across that
numb
/etc/libvirt/qemu.conf:
max_files=
I expect this should always work, even on systemd b0rked systems...
Only solves the problem for QEMU, not for other librbd users.
Jan
> On 03 Sep 2015, at 14:48, Vasiliy Angapov wrote:
>
> And what to do for those with systemd? Because systemd totally ign
And what to do for those with systemd? Because systemd totally ignores
limits.conf and manages limits on per-service basis...
What actual services should be tuned WRT LimitNOFILE?
Or should the DefaultLimitNOFILE increased in /etc/systemd/system.conf?
Thanks in advance!
2015-09-03 17:46 GMT+08:00
You're like the 5th person here (including me) that was hit by this.
Could I get some input from someone using CEPH with RBD and thousands of OSDs?
How high did you have to go?
I only have ~200 OSDs and I had to bump the limit up to 1 for VMs that have
multiple volumes attached, this doesn'
Hi Jan,
Thanks for the advice, hit the nail on the head.
I checked the limits and watched the no. of fd's and as it reached the soft
limit (1024) thats when the transfer came to a grinding halt and the vm
started locking up.
After your reply I also did some more googling and found another old th
1) Take a look at the number of file descriptors the QEMU process is using, I
think you are over the limits
pid=pid of qemu process
cat /proc/$pid/limits
echo /proc/$pid/fd/* | wc -w
2) Jumbo frames may be the cause, are they enabled on the rest of the network?
In any case, get rid of NetworkM
Hi ceph-users,
Hoping to get some help with a tricky problem. I have a rhel7.1 VM guest
(host machine also rhel7.1) with root disk presented from ceph 0.94.2-0
(rbd) using libvirt.
The VM also has a second rbd for storage presented from the same ceph
cluster, also using libvirt.
The VM boots fin
