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 <[email protected]> wrote: > > > Op 9 februari 2017 om 9:13 schreef Özhan Rüzgar Karaman < > [email protected]>: > > > > > > 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 > > [email protected] > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >
_______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
