On Wed, Feb 27, 2019 at 11:21 AM Leo David <[email protected]> wrote: > > Thank you Sahina, I'm in that conversation too :). > On the other hand... > In this case, setting this option on, would only make sense in multi-node > setups, and not in single instance ones, where we only have one hypervisor > accsessing the volume. > Please correct me if this is wrong. > Have a nice day,
In single instance deployments too, the option ensures all writes (with o-direct flag) are flushed to disk and not cached. > > Leo > > > On Tue, Feb 26, 2019, 08:24 Sahina Bose <[email protected]> wrote: >> >> >> >> >> On Fri, Sep 14, 2018 at 3:35 PM Paolo Margara <[email protected]> >> wrote: >>> >>> Hi, >>> >>> but performance.strict-o-direct is not one of the option enabled by gdeploy >>> during installation because it's supposed to give some sort of benefit? >> >> >> See >> https://lists.ovirt.org/archives/list/[email protected]/message/VS764WDBR2PLGGDZVRGBEM6OJCAFEM3R/ >> on why the option is set. >> >>> >>> Paolo >>> >>> >>> Il 14/09/2018 11:34, Leo David ha scritto: >>> >>> performance.strict-o-direct: on >>> This was the bloody option that created the botleneck ! It was ON. >>> So now i get an average of 17k random writes, which is not bad at all. >>> Below, the volume options that worked for me: >>> >>> performance.strict-write-ordering: off >>> performance.strict-o-direct: off >>> server.event-threads: 4 >>> client.event-threads: 4 >>> performance.read-ahead: off >>> network.ping-timeout: 30 >>> performance.quick-read: off >>> cluster.eager-lock: enable >>> performance.stat-prefetch: on >>> performance.low-prio-threads: 32 >>> network.remote-dio: off >>> user.cifs: off >>> performance.io-cache: off >>> server.allow-insecure: on >>> features.shard: on >>> transport.address-family: inet >>> storage.owner-uid: 36 >>> storage.owner-gid: 36 >>> nfs.disable: on >>> >>> If any other tweaks can be done, please let me know. >>> Thank you ! >>> >>> Leo >>> >>> >>> On Fri, Sep 14, 2018 at 12:01 PM, Leo David <[email protected]> wrote: >>>> >>>> Hi Everyone, >>>> So i have decided to take out all of the gluster volume custom options, >>>> and add them one by one while activating/deactivating the storage domain & >>>> rebooting one vm after each added option :( >>>> >>>> The default options that giving bad iops ( ~1-2k) performance are : >>>> >>>> performance.stat-prefetch on >>>> cluster.eager-lock enable >>>> performance.io-cache off >>>> performance.read-ahead off >>>> performance.quick-read off >>>> user.cifs off >>>> network.ping-timeout 30 >>>> network.remote-dio off >>>> performance.strict-o-direct on >>>> performance.low-prio-threads 32 >>>> >>>> After adding only: >>>> >>>> >>>> server.allow-insecure on >>>> features.shard on >>>> storage.owner-gid 36 >>>> storage.owner-uid 36 >>>> transport.address-family inet >>>> nfs.disable on >>>> >>>> The performance increased to 7k-10k iops. >>>> >>>> The problem is that i don't know if that's sufficient ( maybe it can be >>>> more improved ) , or even worse than this there might be chances to into >>>> different volume issues by taking out some volume really needed options... >>>> >>>> If would have handy the default options that are applied to volumes as >>>> optimization in a 3way replica, I think that might help.. >>>> >>>> Any thoughts ? >>>> >>>> Thank you very much ! >>>> >>>> >>>> Leo >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Sep 14, 2018 at 8:54 AM, Leo David <[email protected]> wrote: >>>>> >>>>> Any thoughs on these ? Is that UI optimization only a gluster volume >>>>> custom configuration ? If so, i guess it can be done from cli, but I am >>>>> not aware of the corect optimized parameters of the volume.... >>>>> >>>>> >>>>> On Thu, Sep 13, 2018, 18:25 Leo David <[email protected]> wrote: >>>>>> >>>>>> Thank you Jayme. I am trying to do this, but I am getting an error, >>>>>> since the volume is replica 1 distribute, and it seems that oVirt >>>>>> expects a replica 3 volume. >>>>>> Would it be another way to optimize the volume in this situation ? >>>>>> >>>>>> >>>>>> On Thu, Sep 13, 2018, 17:49 Jayme <[email protected]> wrote: >>>>>>> >>>>>>> I had similar problems until I clicked "optimize volume for vmstore" in >>>>>>> the admin GUI for each data volume. I'm not sure if this is what is >>>>>>> causing your problem here but I'd recommend trying that first. It is >>>>>>> suppose to be optimized by default but for some reason my ovirt 4.2 >>>>>>> cockpit deploy did not apply those settings automatically. >>>>>>> >>>>>>> On Thu, Sep 13, 2018 at 10:21 AM Leo David <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Everyone, >>>>>>>> I am encountering the following issue on a single instance >>>>>>>> hyper-converged 4.2 setup. >>>>>>>> The following fio test was done: >>>>>>>> >>>>>>>> fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 >>>>>>>> --name=test --filename=test --bs=4k --iodepth=64 --size=4G >>>>>>>> --readwrite=randwrite >>>>>>>> The results are very poor doing the test inside of a vm with a >>>>>>>> prealocated disk on the ssd store: ~2k IOPS >>>>>>>> Same test done on the oVirt node directly on the mounted ssd_lvm: ~30k >>>>>>>> IOPS >>>>>>>> Same test done, this time on the gluster mount path: ~20K IOPS >>>>>>>> >>>>>>>> What could be the issue that the vms have this slow hdd performance ( >>>>>>>> 2k on ssd !! )? >>>>>>>> Thank you very much ! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Leo David >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>>>>>> oVirt Code of Conduct: >>>>>>>> https://www.ovirt.org/community/about/community-guidelines/ >>>>>>>> List Archives: >>>>>>>> https://lists.ovirt.org/archives/list/[email protected]/message/FCCIZFRWINWWLQSYWRPF6HNKPQMZB2XP/ >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, Leo David >>> >>> >>> >>> >>> -- >>> Best regards, Leo David >>> >>> >>> _______________________________________________ >>> Users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>> oVirt Code of Conduct: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: >>> https://lists.ovirt.org/archives/list/[email protected]/message/5HKQQKX3BJLZ3HQ5SCHPLPON24OGMGSS/ >>> >>> _______________________________________________ >>> Users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>> oVirt Code of Conduct: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: >>> https://lists.ovirt.org/archives/list/[email protected]/message/E2KCDRMU2KESRNC35YXQUB365B4BF3BU/ _______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/[email protected]/message/K6VVFN36N5NJP3Y5FJKVHO3EVTLPG3HT/
