We also get 2ms for writes, INtel S3500 Journals (5 journals on 1 SSD) and 4TB OSDs...
On 10 September 2015 at 16:41, Jan Schermer <[email protected]> wrote: > What did you tune? Did you have to make a human sacrifice? :) Which > release? > The last proper benchmark numbers I saw were from hammer and the latencies > were basically still the same, about 2ms for write. > > Jan > > > On 10 Sep 2015, at 16:38, Haomai Wang <[email protected]> wrote: > > > > On Thu, Sep 10, 2015 at 10:36 PM, Jan Schermer <[email protected]> wrote: > >> >> On 10 Sep 2015, at 16:26, Haomai Wang <[email protected]> wrote: >> >> Actually we can reach 700us per 4k write IO for single io depth(2 copy, >> E52650, 10Gib, intel s3700). So I think 400 read iops shouldn't be a >> unbridgeable problem. >> >> >> Flushed to disk? >> > > of course > > >> >> >> CPU is critical for ssd backend, so what's your cpu model? >> >> On Thu, Sep 10, 2015 at 9:48 PM, Jan Schermer <[email protected]> wrote: >> >>> It's certainly not a problem with DRBD (yeah, it's something completely >>> different but it's used for all kinds of workloads including things like >>> replicated tablespaces for databases). >>> It won't be a problem with VSAN (again, a bit different, but most people >>> just want something like that) >>> It surely won't be a problem with e.g. ScaleIO which should be >>> comparable to Ceph. >>> >>> Latency on the network can be very low (0.05ms on my 10GbE). Latency on >>> good SSDs is 2 orders of magnitute lower (as low as 0.00005 ms). Linux is >>> pretty good nowadays at waking up threads and pushing the work. Multiply >>> those numbers by whatever factor and it's still just a fraction of the >>> 0.5ms needed. >>> The problem is quite frankly slow OSD code and the only solution now is >>> to keep the data closer to the VM. >>> >>> Jan >>> >>> > On 10 Sep 2015, at 15:38, Gregory Farnum <[email protected]> wrote: >>> > >>> > On Thu, Sep 10, 2015 at 2:34 PM, Stefan Priebe - Profihost AG >>> > <[email protected]> wrote: >>> >> Hi, >>> >> >>> >> while we're happy running ceph firefly in production and also reach >>> >> enough 4k read iop/s for multithreaded apps (around 23 000) with qemu >>> 2.2.1. >>> >> >>> >> We've now a customer having a single threaded application needing >>> around >>> >> 2000 iop/s but we don't go above 600 iop/s in this case. >>> >> >>> >> Any tuning hints for this case? >>> > >>> > If the application really wants 2000 sync IOPS to disk without any >>> > parallelism, I don't think any network storage system is likely to >>> > satisfy him — that's only half a millisecond per IO. 600 IOPS is about >>> > the limit of what the OSD can do right now (in terms of per-op >>> > speeds), and although there is some work being done to improve that >>> > it's not going to be in a released codebase for a while. >>> > >>> > Or perhaps I misunderstood the question? >>> > _______________________________________________ >>> > 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 >>> >> >> >> >> -- >> >> Best Regards, >> >> Wheat >> >> >> > > > -- > > Best Regards, > > Wheat > > > > _______________________________________________ > ceph-users mailing list > [email protected] > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > -- Andrija Panić
_______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
