Hi, But the latest lvm version doesn't worries about the aligned?
2016-05-27 18:37 GMT+02:00 Ken Gaillot <kgail...@redhat.com>: > On 05/27/2016 12:58 AM, Ulrich Windl wrote: >> Hi! >> >> Thanks for this info. We actually run the "noop" scheduler for the SAN >> storage (as per menufacturer's recommendation), because on "disk" is actually >> spread over up to 40 disks. >> Other settings we changes was: >> queue/rotational:0 >> queue/add_random:0 >> queue/max_sectors_kb:128 (manufacturer's recommendation, before up to 1MB >> transfers were seen) >> queue/read_ahead_kb:0 >> >> And we apply those setting (where available) the the whole stack (disk >> devices, multipath device, LV). >> >> Regards, >> Ulrich > > I don't have anything to add about clvm specifically, but some general > RAID tips that are often overlooked: > > If you're using striped RAID (i.e. >1), it's important to choose a > stripe size wisely and make sure everything is aligned with it. Somewhat > counterintuitively, smaller stripe sizes are better for large reads and > writes, while larger stripe sizes are better for small reads and writes. > There's a big performance penalty by setting a stripe size too small, > but not much penalty from setting it too large. > > Things that should be aligned: > > * Partition sizes. A disk's first usable partition will generally start > at (your stripe size in kilobytes * 2) sectors. > > * LVM physical volume metadata (via the --metadatasize option to > pvcreate). It will set the metadata size to the next 64K boundary above > the value, so set it to be just under the size you want, ex. > --metadatasize 1.99M will get a metadata size of 2MB. > > * The filesystem creation options (varies by fs type). For example, with > ext3/ext4, where N1 is stripe size in kilobytes / 4, and N2 is $N1 times > the number of nonparity disks in the array, use -E > stride=$N1,stripe-width=$N2. For xfs, where STRIPE is the stripe size in > kilobytes and NONPARITY is the number of nonparity disks in the array, > use -d su=${STRIPE}k,sw=${NONPARITY} -l su=${STRIPE}k. > > If your RAID controller has power backup (BBU or supercapacitor), mount > filesystems with the nobarrier option. > >>>>> "Carlos Xavier" <cbas...@connection.com.br> schrieb am 25.05.2016 um 22:25 >> in >> Nachricht <01da01d1b6c3$8f5c3dc0$ae14b940$@com.br>: >>> Hi. >>> >>> I have been running OCFS2 on clusters for quite long time. >>> We started running it over DRBD and now we have it running on a Dell >>> storage. >>> Over DRBD it showed a very poor performance, most because the way DRBD >>> works. >>> To improve the performance we had to change the I/O Scheduler of the disk to >> >>> "Deadline" >>> >>> When we migrate the system to the storage, the issue show up again. >>> Sometimes the system was hanging due to disk access, to solve the issue I >>> changed the I/O Schedule To Deadline and the trouble vanished. >>> >>> Regards, >>> Carlos. >>> >>> >>>> -----Mensagem original----- >>>> De: Kristoffer Grönlund [mailto:kgronl...@suse.com] >>>> Enviada em: quarta-feira, 25 de maio de 2016 06:55 >>>> Para: Ulrich Windl; users@clusterlabs.org >>>> Assunto: Re: [ClusterLabs] Performance of a mirrored LV (cLVM) with OCFS: >>> Attempt to monitor it >>>> >>>> Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> writes: >>>> >>>>> cLVM has never made a good impression regarding performance, so I wonder >> if >>> there's anything we >>>> could do to improve the4 performance. I suspect that one VM paging heavily >> >>> on OCFS2 kills the >>>> performance of the whole cluster (that hosts Xen PV guests only). Anyone >>> with deeper insights? >>>> >>>> My understanding is that this is a problem inherent in the design of CLVM >>> and there is work ongoing to >>>> mitigate this by handling clustering in md instead. See this LWN article >> for >>> more details: >>>> >>>> http://lwn.net/Articles/674085/ >>>> >>>> Cheers, >>>> Kristoffer >>>> >>>> -- >>>> // Kristoffer Grönlund >>>> // kgronl...@suse.com > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org -- .~. /V\ // \\ /( )\ ^`~'^ _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org