bristol@mailman.lug.org.uk
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.lug.org.uk/mailman/listinfo/bristol
or, via email, send a message with subject or body 'help' to
bristol-request@mailman.lug.org.uk
You can reach the person managing the list at
bristol-owner@mailman.lug.org.uk
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bristol digest..."
Today's Topics:
1. Re: swapfile by default on ubuntu (Jon Chesterfield)
2. Re: Postgres optimised h/w (Alex Butcher)
3. Re: Postgres optimised h/w (Alex Butcher)
4. Re: Postgres optimised h/w (Alex Butcher)
5. Re: Postgres optimised h/w (Alex Butcher)
6. Re: Postgres optimised h/w (Alex Butcher)
----------------------------------------------------------------------
Message: 1
Date: Sat, 17 Dec 2016 10:27:09 +0000
From: Jon Chesterfield <jonathanchesterfield@gmail.com>
To: bristol@mailman.lug.org.uk
Subject: Re: [bristol] swapfile by default on ubuntu
Message-ID:
<CAOUYtQBPi2S0B8DUjyADt-F7DEhgyNfZXOqtNfE8xvGF0sZVMw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I think this is fairly consistent with the Ubuntu world view.
If it's the only OS a swap file is more convenient. btrfs isn't the default
filesystem so whatever exciting problems it has being on swap won't be
visible.
If it's not the only OS, it was probably installed with custom
partitioning. I wouldn't trust a default button to leave other systems
unharmed, so have never tried - maybe the installer looks for contiguous
free space on the intended drive, maybe it doesn't. Anyway, if using custom
partitioning the swap partition is still available.
An interesting question is whether the installer will (accidentally?) make
the swap file even when a partition is present. If so, I guess the user
gets to delete it and raise it as a bug.
Overall it's probably a harmless change though. Thanks for sharing :)
Jon
Message: 5
Date: Fri, 16 Dec 2016 19:32:53 +0000
From: Sebastian <sebsebseb_mageia@gmx.com>
To: <bristol@mailman.lug.org.uk>, <sebsebseb_mageia@gmx.com>
Subject: [bristol] Swapfile by default instead of partiton for...
Message-ID: <4dedee82-b4b2-461a-ae48-0315e21332c9@gmx.com>
Content-Type: text/plain; charset=utf-8; format=flowed
HI
Been some intereresting news today, Ubuntu news, that for Ubuntu 17.04
will be a swapfile by default instead of a partition. Not quite sure how
wthat would work with multiple distros if stored inside Ubuntu. Also
looking at where I found out again, some comments saying how that woudn't
really work with BTFS it seems. Anyway wanted to share here for some
general comments to do with that, (and actually doing so now, was going to
maybe earlier on it's own or later on in another email),
http://www.omgubuntu.co.uk/2016/12/ubuntu-17-04-drops-
swaps-swap-partitions-swap-files
Regards
Sebastian
--
Sent using Dekko from my Ubuntu device
------------------------------
Subject: Digest Footer
_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol
------------------------------
End of Bristol Digest, Vol 673, Issue 8
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.lug.org.uk/mailman/private/bristol/attachments/20161217/5e8d37c7/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 17 Dec 2016 11:07:24 +0000 (GMT)
From: Alex Butcher <lug@assursys.co.uk>
To: mark chard <machard.1984@gmail.com>, Bristol and Bath Linux User
Group <bristol@mailman.lug.org.uk>
Cc: Martin Moore <martinm@it-helps.co.uk>
Subject: Re: [bristol] Postgres optimised h/w
Message-ID:
<alpine.LRH.2.11.1612171059370.753@zlgugi.of5.nffheflf.cev>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 16 Dec 2016, mark chard via Bristol wrote:
> Ssd's are a good move but be careful which you purchase with as read/write
> throughput may be a restrictive factor.
Eh? A 10K 2.5" 4.6ms HDD will probably do about 130 IOPS:
IOPS=1/Tio
Tio = time per IO
Ta = access time, aka one average seek
Tl = rotational latency, aka half a rotation
Tt = transfer time, i.e. block size divided by sustained transfer rate
Tio=Ta+Tl+Tt
Ta = 4.6ms = 0.0046s
Tl = (1/(10000RPM/60s)/2)=3ms=0.003s
Tt = 512bytes/198MB/s=0.000002466s to 512bytes/112MB/s=0.00000436s
Tio = 0.0076s + 0.000002466s = 0.007602466s to 0.0076s + 0.00000436s =
0.0070436s
IOPS= 1/0.007602466s=131.536267311 to 1/0.00760436s=131.503505883
Even the consumer-grade Samsung 850 Pro in my desktop is rated for 90000
IOPS.
> In my mind a nice RAID6 array of 10k 6GB/s SAS disks might be what you are
> looking for here.
Given Martin's note that his database is rarely written to, RAID6 /might/
work for him. But given that'd need a minimum of four drives to implement,
I'd suggest using RAID10 instead, which is one of the more usual choices for
database storage, given its better write performance and reliability
characteristics.
Best Regards,
Alex
------------------------------
Message: 3
Date: Sat, 17 Dec 2016 11:11:12 +0000 (GMT)
From: Alex Butcher <lug@assursys.co.uk>
To: Martin Moore <martinm@it-helps.co.uk>, Bristol and Bath Linux
User Group <bristol@mailman.lug.org.uk>
Cc: Chris Boot <bootc@bootc.net>
Subject: Re: [bristol] Postgres optimised h/w
Message-ID:
<alpine.LRH.2.11.1612171108010.753@zlgugi.of5.nffheflf.cev>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On Fri, 16 Dec 2016, Martin Moore via Bristol wrote:
> Are most decent RAID controllers admin-able from a running system or is it
> a BIOS level thing still?
I wouldn't dare comment on 'most', but the decent ones (LSI/Dell, Adaptec)
are.
> Also need how-swap.
This is standard for decent RAID controllers.
> According to Wikipedia, RAID6 is no faster at reading the RAID1 – in which
> case RAID1 would be fine. Does this sound right?
The main things that count when it comes to read performance is the number
of drives that your data is striped across and their individual performance,
rather than the RAID level per se.
Best Regards,
Alex
------------------------------
Message: 4
Date: Sat, 17 Dec 2016 11:20:08 +0000 (GMT)
From: Alex Butcher <lug@assursys.co.uk>
To: debian@invux.com, Bristol and Bath Linux User Group
<bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Postgres optimised h/w
Message-ID:
<alpine.LRH.2.11.1612171111350.753@zlgugi.of5.nffheflf.cev>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 16 Dec 2016, Steve King via Bristol wrote:
>> I would also recommend a hardware RAID controller for a database: MD
>> RAID is great but far less flexible, and the more processing and IO you
>> can farm off to dedicated hardware the faster your database server will
>> go.
>>
>
> In what way is MDRAID less flexible than hardware raid?
> I have never found hardware raid offers more performance or more
> flexibility, plus you are at the mercy of the hardware vendor if you hit a
> problem.
In ye olde days, the embedded CPU for performing parity calculations for
RAID5/6/etc arrays was a useful way of offloading that from the main CPU.
These days, such embedded CPUs are vastly less powerful than a modern main
CPU, which can almost do partity calculations in its sleep.
Mind you, in ye olde (kernel < 2.6.15) days, Linux's md RAID had some
horrible misbehaviours that were quite likely to threaten your availability
(see the 'Recovery' section of md(4) for the gory details). That alone was
probably sufficient to justify hardware RAID controllers for many.
> I can give you several reasons why MDRAID is more flexible than hardware
> raid, including its support for asymmetric SSD/NonSSD: --write-mostly
>
> Plus the cost of the things. And in my experience they don't give much of
> a performance increase anyway.
The main justifications for hardware RAID controllers are, in my view, the
battery/flash-backed write buffers and the lower operational costs (i.e. the
controller indicates which drive has failed, your data centre tech pulls
it and pops in a new one and the re-construction starts automatically). I'm
happy to use md RAID at home, but wouldn't dream of using it at work.
> Steve
Best Regards,
Alex
------------------------------
Message: 5
Date: Sat, 17 Dec 2016 11:31:24 +0000 (GMT)
From: Alex Butcher <lug@assursys.co.uk>
To: Amias Channer <me@amias.net>, Bristol and Bath Linux User Group
<bristol@mailman.lug.org.uk>
Cc: Chris Boot <bootc@bootc.net>
Subject: Re: [bristol] Postgres optimised h/w
Message-ID:
<alpine.LRH.2.11.1612171120190.753@zlgugi.of5.nffheflf.cev>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 16 Dec 2016, Amias Channer via Bristol wrote:
> On 16 December 2016 at 11:33, Chris Boot via Bristol
> <bristol@mailman.lug.org.uk> wrote:
>> The *only* downside of SSD now is cost.
>
> i'm not sure i really agree with that, SSD is good for reads but
> writes can be a problem when they get old.
>
> There are lots of really crap SSD drives around ,
There certainly are amongst consumer offerings, but generally not amongst
enterprise SSDs.
The high-end, but still consumer-grade Samsung 850 PRO in my desktop is
rated for 10 years of service or 150Terabytes Written (TBW) (whichever comes
first). That's only 0.164 Diskful Writes Per Day (DWPD).
According to some information from about 18 months ago, Dell's enterprise
offerings are rated at about 1 DWPD for 3 years (for their 'read intensive'
models) upto 25 DWPD over 5 years (for their 'write intensive' models).
<http://www.storagesearch.com/dwpd.html> and
<https://laur.ie/blog/2015/06/ssds-a-gift-and-a-curse/> are worth reading.
> i used to do testing
> for storage startup and from that experience
> i could only recommend the samsung evo or intel drives,
Samsung's EVO is intended for mid-range/consumer desktops, not server use.
Samsung do have enterprise models with better endurance and performance than
their consumer models.
Intel do produce some great enterprise SSDs, but they also produce desktop
SSDs too, so choice of model is important.
> Look for drives that can advertise IOPS for performance not MB's
IOPS and DWPD, yes.
Best Regards,
Alex
------------------------------
Message: 6
Date: Sat, 17 Dec 2016 11:33:50 +0000 (GMT)
From: Alex Butcher <lug@assursys.co.uk>
To: Martin <inkubus@interalpha.co.uk>, Bristol and Bath Linux User
Group <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Postgres optimised h/w
Message-ID:
<alpine.LRH.2.11.1612171131350.753@zlgugi.of5.nffheflf.cev>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 16 Dec 2016, Martin via Bristol wrote:
> On Fri, 2016-12-16 at 16:26 +0000, Steve King via Bristol wrote:
>>>
>>> I would also recommend a hardware RAID controller for a database: MD
>>> RAID is great but far less flexible, and the more processing and IO you
>>> can farm off to dedicated hardware the faster your database server will
>>> go.
>>>
>>
>> In what way is MDRAID less flexible than hardware raid?
>> I have never found hardware raid offers more performance or more
>> flexibility, plus you are at the mercy of the hardware vendor if you hit a
>> problem.
> ^^^^^^^^^^^^^ THISTHISTHIS! What he said!
>
> I have recovered RAID systems (personally and advised people in doing
> so) that were theoretically broken past the point of repair.
Whoever you were working for was doing it wrong.
RAID is for availability and performance, not backups.
If the time to recover from backup in the event of unanticipated multiple
drive failure (i.e. total array failure) is too long for business needs,
then they should have had two (or more!) resilient servers providing the
service they're depending on.
> - Martin
Best Regards,
Alex
------------------------------
Subject: Digest Footer
_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol
------------------------------
End of Bristol Digest, Vol 673, Issue 10
****************************************
Tidak ada komentar:
Posting Komentar