Do you have historical data from these OSDs to see when/if the DB used on osd.73 ever filled up? To account for this OSD using the slow storage for DB, all we need to do is show that it filled up the fast DB at least once. If that happened, then something spilled over to the slow storage and has been there ever since.
On Sat, Feb 16, 2019 at 1:50 AM Konstantin Shalygin <k0ste@xxxxxxxx> wrote:
On 2/16/19 12:33 AM, David Turner wrote:
> The answer is probably going to be in how big your DB partition is vs
> how big your HDD disk is. From your output it looks like you have a
> 6TB HDD with a 28GB Blocks.DB partition. Even though the DB used size
> isn't currently full, I would guess that at some point since this OSD
> was created that it did fill up and what you're seeing is the part of
> the DB that spilled over to the data disk. This is why the official
> recommendation (that is quite cautious, but cautious because some use
> cases will use this up) for a blocks.db partition is 4% of the data
> drive. For your 6TB disks that's a recommendation of 240GB per DB
> partition. Of course the actual size of the DB needed is dependent on
> your use case. But pretty much every use case for a 6TB disk needs a
> bigger partition than 28GB.
My current db size of osd.33 is 7910457344 bytes, and osd.73 is
2013265920+4685037568 bytes. 7544Mbyte (24.56% of db_total_bytes) vs
6388Mbyte (6.69% of db_total_bytes).
Why osd.33 is not used slow storage at this case?
k
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
