Hi. No offence, but as topic author wrote, he has 30MB/s. Just kept it in
mind when wrote about 100.
7 авг. 2017 г. 3:01 пользователь "Eric Green" <eric.lee.gr...@gmail.com>
> > On Aug 5, 2017, at 21:03, Ivan Kudryavtsev <kudryavtsev...@bw-sw.com>
> > Hi, I think Eric's comments are too tough. E.g. I have 11xSSD 1TB with
> > linux soft raid 5 and Ext4 and it works like a charm without special
> > tunning.
> > Qcow2 also not so bad. LVM2 does it better of course (if not being
> > snapshotted). Our users have different workloads and nobody claims disk
> > performance is a problem. Read/write 100 MB/sec over 10G connection is
> > a problem at all for the setup specified above.
> 100 MB/sec is the speed of a single vintage 2010 5200 RPM SATA-2 drive.
> For many people, that is not a problem. For some, it is. For example, I
> have a 12x-SSD RAID10 for a database. This RAID10 is on a SAS2 bus with 4
> channels thus capable of 2.4 gigaBYTES per second raw throughput. Yes, I
> have validated that the SAS2 bus is the limit on throughput for my SSD
> array. If I provided a qcow2 volume to the database instance that only
> managed 100MB/sec, my database people would howl.
> I have many virtual machines that run quite happily with thin qcow2
> volumes on 12-disk RAID6 XFS datastores (spinning storage) with no problem,
> because they don't care about disk throughput, they are there to process
> data, or provide services like DNS or a Wiki knowledge base, or otherwise
> do things that aren't particularly time-critical in our environment. So
> it's all about your customer and his needs. For maximum throughput, qcow2
> on a ext4 soft RAID capable of doing 100Mb/sec is very... 2010 spinning
> storage... and people who need more than that, like database people, will
> be extremely dissatisfied.
> Thus my suggestions of ways to improve performance via providing a custom
> disk offering for those cases where disk performance and specifically write
> performance is a problem -- switching to 'sparse' rather than 'thin' as the
> provisioning mechanism (which greatly speeds writes since now only the
> filesystem block allocation mechanisms get invoked, rather than qcow2's
> block allocation mechanisms, and qcow2 now only has a single allocation
> zone which greatly speeds its own lookups), using a different underlying
> filesystem that has proven to have more consistent performance (xfs isn't
> much faster than ext4 under most scenarios but doesn't have the lengthy
> dropouts in performance that come with lots of writes on ext4), and
> possibly flipping on async caching in the disk offering if data integrity
> isn't a problem (for example, for an Elasticsearch instance, the data is
> all replicated across multiple nodes on multiple datastores anyhow, so if I
> lose an Elasticsearch node's data so what? I just destroy that instance and
> create a new one to join to the cluster!). And of course there's always the
> option of simply avoiding qcow2 altogether and providing the data via iSCSI
> or NFS directly to the instance, which may be what you need to do for
> something like a database that has some very specific performance and
> throughput requirements.