Hi Wido;
Thanks for fast response rbd ls -l reads all images header for its sizes yes it makes sense you are right.
My main problem is when i refresh a rbd storage pool using virsh over kvm(Ubuntu 14.04.5) it takes too much time then the old days and i suspect that virsh makes "rbd ls -l" over Ceph storage so thats why i asked.
Does virsh use same "rbd ls -l" for pool refresh?
So in this case below 22 second is normal for virsh rbd pool refresh?
root@kvmt1:~# time virsh pool-refresh 01b375db-d3f5-33c1-9389-8bf226c887e8
Pool 01b375db-d3f5-33c1-9389-8bf226c887e8 refreshed
real 0m22.504s
user 0m0.012s
sys 0m0.004s
Thanks
Özhan
On Thu, Feb 9, 2017 at 11:30 AM, Wido den Hollander <wido@xxxxxxxx> wrote:
> Op 9 februari 2017 om 9:13 schreef Özhan Rüzgar Karaman <oruzgarkaraman@xxxxxxxxx>:
>
>
> Hi;
> I am using Hammer 0.49.9 release on my Ceph Storage, today i noticed that
> listing an rbd pool takes to much time then the old days. If i have more
> rbd images on pool it takes much more time.
>
It is the -l flag that you are using in addition. That flag opens each RBD image and stats the header of it to get the size.
A regular 'rbd ls' will only read the RADOS object rbd_directory, but it is the -l flag which causes the RBD tool to iterate over all the images and query their header.
> ______________________________
> My clusters health is ok and currently there is no load on the cluster.
> Only rbd images are used to serve to vm's.
>
> I am sending some information below. My level.db size is also 280 mb, i
> also compacted level.db to 40 mb size but again "rbd ls -l" output is too
> slow.
>
> This timing is important for my vm deploy time to complete because when i
> refresh a pool/datastore it takes nearly to 20 seconds or more for 350 rbd
> images+snapshots.
>
> Thanks for all help
>
> Regards
> Ozhan Ruzgar
>
> root@mont3:/var/lib/ceph/mon/ceph-mont3/store.db# ceph -s
> cluster 6b1cb3f4-85e6-4b70-b057-ba7716f823cc
> health HEALTH_OK
> monmap e1: 3 mons at
> {mont1=172.16.x.x:6789/0,mont2=172.16.x.x:6789/0,mont3= 172.16.x.x:6789/0}
> election epoch 126, quorum 0,1,2 mont1,mont2,mont3
> osdmap e20509: 40 osds: 40 up, 40 in
> pgmap v20333442: 1536 pgs, 3 pools, 235 GB data, 63442 objects
> 700 GB used, 3297 GB / 3998 GB avail
> 1536 active+clean
> client io 0 B/s rd, 3785 kB/s wr, 314 op/s
>
> root@mont1:~# time rbd ls -l cst2|wc -l
> 278
>
> real 0m11.970s
> user 0m0.572s
> sys 0m0.316s
> root@mont1:~# time rbd ls -l cst3|wc -l
> 15
>
> real 0m0.396s
> user 0m0.020s
> sys 0m0.032s
> root@mont1:~# time rbd ls -l cst4|wc -l
> 330
>
> real 0m16.630s
> user 0m0.668s
> sys 0m0.336s
_________________
> ceph-users mailing list
> ceph-users@xxxxxxxxxxxxxx
> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph. com
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
