On Tue, Mar 13, 2018 at 12:58 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Mon, Mar 12, 2018 at 6:23 PM, Ondrej Valousek <
> ondrej.valou...@s3group.com> wrote:
>
>> Hi,
>>
>> Gluster will never perform well for small files.
>>
>> I believe there is  nothing you can do with this.
>>
>
> It is bad compared to a disk filesystem but I believe it is much closer to
> NFS now.
>
> Andreas,
>      Looking at your workload, I am suspecting there to be lot of LOOKUPs
> which reduce performance. Is it possible to do the following?
>
> # gluster volume profile <volname> info incremental
> #execute your workload
> # gluster volume profile <volname> info incremental >
> /path/to/file/that/you/need/to/send/us
>
> If the last line in there is LOOKUP, mostly we need to enable nl-cache
> feature and see how it performs.
>

Please attach this as extra information along with what Nitya asked in the
previous mail.


>
>
>> Ondrej
>>
>>
>>
>> *From:* gluster-users-boun...@gluster.org [mailto:gluster-users-bounces@
>> gluster.org] *On Behalf Of *Andreas Ericsson
>> *Sent:* Monday, March 12, 2018 1:47 PM
>> *To:* Gluster-users@gluster.org
>> *Subject:* [Gluster-users] Expected performance for WORM scenario
>>
>>
>>
>> Heya fellas.
>>
>>
>>
>> I've been struggling quite a lot to get glusterfs to perform even
>> halfdecently with a write-intensive workload. Testnumbers are from gluster
>> 3.10.7.
>>
>>
>>
>> We store a bunch of small files in a doubly-tiered sha1 hash fanout
>> directory structure. The directories themselves aren't overly full. Most of
>> the data we write to gluster is "write once, read probably never", so 99%
>> of all operations are of the write variety.
>>
>>
>>
>> The network between servers is sound. 10gb network cards run over a 10gb
>> (doh) switch. iperf reports 9.86Gbit/sec. ping reports a latency of 0.1 -
>> 0.2 ms. There is no firewall, no packet inspection and no nothing between
>> the servers, and the 10gb switch is the only path between the two machines,
>> so traffic isn't going over some 2mbit wifi by accident.
>>
>>
>>
>> Our main storage has always been really slow (write speed of roughly
>> 1.5MiB/s), but I had long attributed that to the extremely slow disks we
>> use to back it, so now that we're expanding I set up a new gluster cluster
>> with state of the art NVMe SSD drives to boost performance. However,
>> performance only hopped up to around 2.1MiB/s. Perplexed, I tried it first
>> with a 3-node cluster using 2GB ramdrives, which got me up to 2.4MiB/s. My
>> last resort was to use a single node running on ramdisk, just to 100%
>> exclude any network shenanigans, but the write performance stayed at an
>> absolutely abysmal 3MiB/s.
>>
>>
>>
>> Writing straight to (the same) ramdisk gives me "normal" ramdisk speed (I
>> don't actually remember the numbers, but my test that took 2 minutes with
>> gluster completed before I had time to blink). Writing straight to the
>> backing SSD drives gives me a throughput of 96MiB/sec.
>>
>>
>>
>> The test itself writes 8494 files that I simply took randomly from our
>> production environment, comprising a total of 63.4MiB (so average file size
>> is just under 8k. Most are actually close to 4k though, with the occasional
>> 2-or-so MB file in there.
>>
>>
>>
>> I have googled and read a *lot* of performance-tuning guides, but the
>> 3MiB/sec on single-node ramdisk seems to be far beyond the crippling one
>> can cause by misconfiguration of a single system.
>>
>>
>>
>> With this in mind; What sort of write performance can one reasonably hope
>> to get with gluster? Assume a 3-node cluster running on top of (small)
>> ramdisks on a fast and stable network. Is it just a bad fit for our
>> workload?
>>
>>
>>
>> /Andreas
>>
>> -----
>>
>> The information contained in this e-mail and in any attachments is 
>> confidential and is designated solely for the attention of the intended 
>> recipient(s). If you are not an intended recipient, you must not use, 
>> disclose, copy, distribute or retain this e-mail or any part thereof. If you 
>> have received this e-mail in error, please notify the sender by return 
>> e-mail and delete all copies of this e-mail from your computer system(s). 
>> Please direct any additional queries to: communicati...@s3group.com. Thank 
>> You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland 
>> no. 378073. Registered Office: South County Business Park, Leopardstown, 
>> Dublin 18.
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-users
>>
>
>
>
> --
> Pranith
>



-- 
Pranith
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-users

Reply via email to