Re: Performance improvement suggestion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

Hi Janne, thanks for your reply.

I think that it would be good to maintain the number of configured replicas. I don't think it's interesting to decrease to size=1.

However, I think it is not necessary to write to all disks to release the client's request. Replicas could be recorded immediately in a second step.

Nowadays, more and more software are implementing parallelism for writing through specific libraries. Examples: MPI-IO, HDF5, pnetCDF, etc...

This way, even if the cluster has multiple disks, the objects will be written in PARALLEL. The greater the number of processes recording at the same time, the greater the storage load, regardless of the type of disk used (HDD, SSD or NVMe).

I think and suggest that it is very useful to have the initial recording only be done on one disk and the replicas be done after the client is released (asynchronously).

Rafael.

 

De: "Janne Johansson" <icepic.dz@xxxxxxxxx>
Enviada: 2024/02/01 04:08:05
Para: anthony.datri@xxxxxxxxx
Cc: acozyurt@xxxxxxxxx, quaglio@xxxxxxxxxx, ceph-users@xxxxxxx
Assunto: Re: Re: Performance improvement suggestion
 
> I’ve heard conflicting asserts on whether the write returns with min_size shards have been persisted, or all of them.

I think it waits until all replicas have written the data, but from
simplistic tests with fast network and slow drives, the extra time
taken to write many copies is not linear to what it takes to write the
first, so unless you do go min_size=1 (not recommended at all), the
extra copies are not slowing you down as much as you'd expect. At
least not if the other drives are not 100% busy.

I get that this thread started on having one bad drive, and that is
another scenario of course, but having repl=2 or repl=3 is not about
writes taking 100% - 200% more time than the single write, it is less.

--
May the most significant bit of your life be positive.
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx

[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux