Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.hardware > #3265

Re: Speed ups for a disk IO bound machine

Show all headers | View raw

On 16/12/16 00:18, Peter Chant wrote:
<snip>

I am not going to go through this answering point for point - it would
be too specific and require too many questions and answers about exact
details.  I'll make a few more comments below - and I have read the bits
that I have snipped, even if I didn't reply to them.  If you want to
take any of these points further, that's fine - but we can snip the
other parts to keep the posts of manageable length.

It is good that you are willing to experiment and try new arrangements
here - getting an "optimal" system is not easy.  And of course, playing
around and learning about the options is fun!  I hope I have been able
to give you a few ideas about some possibilities you were not aware of,
some pointers about things you need to consider, and some technical
details to help you understand some of the options.

And hopefully at least some of it has been interesting to other people
in the group!

If you are looking for more help or information about raid, the Linux
raid mailing list is a good place.  It has an emphasis on md raid, but
covers other types of raid too.

> On 12/15/2016 11:55 AM, David Brown wrote:
>> On 14/12/16 21:03, Peter Chant wrote:
>>> On 12/13/2016 09:17 AM, David Brown wrote:
>>>
> 

<snip>

> Well, the old SSD is not that old its a Samsung 840 Pro. Anyway.  I have
> it and am not otherwise using it and the same goes for a 2TB HDD. So I
> can play with caching (but not necessarily RAID).  So I can add them to
> the machine and have a go.  However, this is much larger than the
> mariadb files and some others so I can try using it as a dedicated drive
> for some things and see if shifting some storage to it makes a
> difference.  With more effort I can probably play with RAID and caching.
> 

Running directly from SSD is always faster and more efficient than any
sort of caching system.  So putting the files on the SSD is a good idea.

Here are a few other pointers to consider and investigate:

1. Mariadb/MySql supports a number of different table formats.  Are the
formats you are using the best for the job?

2. Some formats need update-in-place files for efficiency.  Btrfs uses
copy-on-write, which can be slow and inefficient if the application
expects to change parts of a file.

3. RAID0 only helps speed if you have large files.  For small files and
random access, RAID0 slows things down - especially on hard disks.
RAID1 can speed up multiple small reads in parallel, but slows down
small writes a bit.

4. You can choose where to store your database files, regardless of how
the rest of your system is organised.  One simple way is to use symbolic
links for directories.  So if your database files are in /var/mariadb,
and you want them to be on a disk that is mounted /mnt/disk2, make
/var/mariadb a symbolic link pointing to /mnt/disk2/mariadb.

5. Experiment with the database files on a tmpfs.  This will give you an
idea of the maximum speeds possible, so that you know you are not aiming
unrealistically high or dealing with something completely different as
the bottleneck in the system.

> I've also looked up mysql optimisation and xfs is suggested.  So I can
> make a dedicated xfs partition and see what happens.  With or without LVM...

xfs makes sense on /big/ systems.  It makes little sense on small
severs.  The usual disk setup for a high performance xfs system is to
organise your disks in raid1 pairs, then make a linear stripe (/not/ a
raid0) on top of that for xfs.  The aim is to give low-latency parallel
access from a large number of processes - think media bank, large file
server, mail server, big database server, etc.  If you don't have at
least 4 or 6 identical drives, your server task is probably not big
enough to benefit much from xfs.

> 
> There seem to be two schools of thought on RAID1 here.  Anyway, I can
> play as far as I like provided I don't waste time or money.

You are going to be wasting time in this - but it is all experience and
part of the learning process.

<snip>

> 
>>
>> /If/ your old SSD is reasonably fast, you can first run a secure erase
>> to tell it to drop all data.  Then partition it, leaving a little extra
>> space unused - this overprovisioning can help a lot.  And use it with
>> btrfs raid1, not md raid1, so that only the actual useful data is
>> replicated.
>>
> 
> Think I'll boot on a USB stick and unplug all other drives when trying that.
> 

<snip>

> 
> The system is on a simple partition with btrfs in single.  But boot is
> ext3 or 4.  And there is a partition I consider the 'maintenance'
> partition with a full slackware install on ext3 or 4 that I hardly touch
> but is handy in case I break something.  Also you can't build a kernel
> from a rescue disk but you can with this which is nice.
> 
> You can reasonably argue that it is a waste of space especially on an
> SSD which is expensive compared to a HDD but it is a nice comfort
> blanket and doubly so on the rare occasions it is needed.

Agreed.

<snip>

>> If you have a lot of data, it takes a while to copy it all over.  And a
>> re-balance actually does a good deal more work than just a plain copy.
>> But at least it doesn't copy the unused space too.
>>
> 
> Ues, there is the checksumming for a start.  But that is a good thing.
> 

The checksumming is not very processor intensive.  But it is not
particularly useful either - so-called "bit rot" and "undetected read
errors" are extraordinarily rare (they are very different from
"unrecoverable read errors", for which unchecksummed raid1 is good
enough).  The 32 bits of checksum are peanuts compared to the levels of
checksum that already exist on the disk.  The crc /could/ be useful for
detecting possible duplicate extents, but I don't think it is easily
accessed for that at the moment.

<snip>

> 
> 
> 
>>
>> Loop devices work well in testing, especially for seeing how to add
>> disks, replace disks, resize things, etc.  Of course they are of little
>> help in speed testing.
>>
>> I usually testing using loop devices made in a tmpfs mount - but then,
>> my machines normally have lots of ram.
>>
> 
> I'd never have guessed.  :-)
> 
> 
> Anyway food for thought here from Piergorgio and yourself.
> 
> 
> 

Back to comp.os.linux.hardware | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-07 22:41 +0000
  Re: Speed ups for a disk IO bound machine Roger Blake <rogblake@iname.invalid> - 2016-12-08 16:44 +0000
    Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-10 11:24 +0000
      Re: Speed ups for a disk IO bound machine Roger Blake <rogblake@iname.invalid> - 2016-12-11 01:34 +0000
        Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-11 22:07 +0000
  Re: Speed ups for a disk IO bound machine Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> - 2016-12-10 12:43 +0100
    Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-10 20:44 +0000
      Re: Speed ups for a disk IO bound machine Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> - 2016-12-10 23:05 +0100
        Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-11 11:54 +0000
          Re: Speed ups for a disk IO bound machine Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> - 2016-12-11 14:10 +0100
            Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-11 22:46 +0000
              Re: Speed ups for a disk IO bound machine Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> - 2016-12-12 19:22 +0100
            Re: Speed ups for a disk IO bound machine David Brown <david.brown@hesbynett.no> - 2016-12-13 10:17 +0100
              Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-14 20:03 +0000
                Re: Speed ups for a disk IO bound machine David Brown <david.brown@hesbynett.no> - 2016-12-15 12:55 +0100
                Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-15 23:18 +0000
                Re: Speed ups for a disk IO bound machine David Brown <david.brown@hesbynett.no> - 2016-12-16 09:34 +0100
        Re: Speed ups for a disk IO bound machine David Brown <david.brown@hesbynett.no> - 2016-12-13 09:57 +0100
  Re: Speed ups for a disk IO bound machine David Brown <david.brown@hesbynett.no> - 2016-12-12 09:11 +0100
    Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-12 23:08 +0000
      Re: Speed ups for a disk IO bound machine David Brown <david.brown@hesbynett.no> - 2016-12-13 09:29 +0100
        Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-14 23:16 +0000
          Re: Speed ups for a disk IO bound machine David Brown <david.brown@hesbynett.no> - 2016-12-15 13:15 +0100
            Re: Speed ups for a disk IO bound machine Peter Chant <pete@petezilla.co.uk> - 2016-12-15 22:50 +0000
              Re: Speed ups for a disk IO bound machine David Brown <david.brown@hesbynett.no> - 2016-12-16 09:39 +0100

csiph-web