Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

SSD disk for DB

 

 

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded


josu.lazkano at gmail

Oct 8, 2012, 4:22 AM

Post #1 of 38 (2136 views)
Permalink
SSD disk for DB

Hello all,

I am configuring my new backend, and want to know your opinion about
put the DB on a SSD disk.

This is a small 8GB disk, is this a good idea? I read that if I write
lots of times on a SSD, it use to break faster than a normal disk.

I will appreciate your experience on this configuration.

Thanks and best regards.

--
Josu Lazkano
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


ron at ronfrazier

Oct 8, 2012, 5:21 AM

Post #2 of 38 (2106 views)
Permalink
Re: SSD disk for DB [In reply to]

I started a discussion on this earlier this year, which I thought
ended up with some decent info:
http://www.gossamer-threads.com/lists/engine?post=500144;list=mythtv

A few of the takeaway's from that thread.

1) I saw a huge performance boost from database which gave me much
better performance in mythweb and the mythfrontend program guide and
watch recordings screens. A few of the posts alluded that you might be
able to get the same results by having your entire DB cached in
memory, but there wasn't much discussion towards that end.

2) I discussed write-wear on the drives and measuring it. In short, I
did not find it necessary to do most of the things websites advocate
you do. I did align the partition to a 1MB boundary to be safe (not
sure if any newer drives would require a larger alignment than that).
I also mounted the partition with noatime (though I do that for all
drives, not just SSDs). The only thing I found to be causing
significant wear were the mysql temporary tables created by the myth
scheduler running several times an hour. I solved this my moving /tmp
to memory, but other's said it could just as well be solved by
configuring mysql to put temp tables in memory by altering some
settings in my.cnf

Keeping the above in mind, read through that thread for the details.

--
Ron Frazier
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mikep at randomtraveller

Oct 8, 2012, 7:29 AM

Post #3 of 38 (2099 views)
Permalink
Re: SSD disk for DB [In reply to]

On 08/10/12 12:22, Josu Lazkano wrote:
> Hello all,
>
> I am configuring my new backend, and want to know your opinion about
> put the DB on a SSD disk.
>
> This is a small 8GB disk, is this a good idea? I read that if I write
> lots of times on a SSD, it use to break faster than a normal disk.
>
> I will appreciate your experience on this configuration.
>
> Thanks and best regards.
>
I would make the distinction here between a Flash disk and a Solid State Disk
(SSD). What you have said above is true for Flash disks like SDHC, Compact
Flash, etc but is not true for SSDs. These can be treated just like a normal
hard disk.

It should be noted that SSDs haven't been around long enough for long-term
reliability patterns to become visible yet but given they run cooler and have no
moving parts I believe they will last at least as long as a traditional disk.

I have just bought three 36Gb SSDs which will be the only drives in two servers
and my main front end. The two I have installed so far have given me no trouble
at all. None of these will have high disk I/O, though.

--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


linux at thehobsons

Oct 8, 2012, 9:16 AM

Post #4 of 38 (2103 views)
Permalink
Re: SSD disk for DB [In reply to]

Mike Perkins wrote:

>I would make the distinction here between a Flash disk and a Solid
>State Disk (SSD). What you have said above is true for Flash disks
>like SDHC, Compact Flash, etc but is not true for SSDs. These can be
>treated just like a normal hard disk.

Well sort of.

An SSD is also subject to the same wear issues as other flash drive
types - but the crucial difference is that they have wear levelling
<stuff> built in. So while a flash drive (pen drive, SD card, etc)
would wear out quickly if you write to the same blocks repeatedly, an
SSD will automatically remap stuff internally to move those active
blocks to less used physical storage. They also have spare blocks
which are used both to improve performance (instead of waiting while
a block is erased, just write the data on a spare block and update
the map), and to deal with defects/aged cells.

So an SSD is still subject to wear, but the wear is automatically
shared across all it's physical blocks - unlike flash drives where
it's easy to wear out one block while still having plenty of life
left in the rest of the drive.

As you say, SSDs haven't been out long enough to get much by way of
real world feedback on durability yet.

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


ajp at cantabrian

Oct 8, 2012, 10:28 AM

Post #5 of 38 (2097 views)
Permalink
Re: SSD disk for DB [In reply to]

>Hello all,

>I am configuring my new backend, and want to know your opinion about put
the DB on a SSD disk.

>This is a small 8GB disk, is this a good idea? I read that if I write lots
of times on a SSD, it use to break faster than a normal disk.

>I will appreciate your experience on this configuration.

>Thanks and best regards.

From my reading at lot of it comes down to the make and model of SSD that
you have. A good brand/model SSD should not break down any sooner in fact my
reading is they are more reliable

--
Josu Lazkano
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2441/5316 - Release Date: 10/07/12

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


ron at ronfrazier

Oct 8, 2012, 11:29 AM

Post #6 of 38 (2091 views)
Permalink
Re: SSD disk for DB [In reply to]

On Mon, Oct 8, 2012 at 10:29 AM, Mike Perkins
<mikep [at] randomtraveller> wrote:

> I would make the distinction here between a Flash disk and a Solid State
> Disk (SSD).

Good catch. For some reason I read it as 80GB (a common size for SSDs).

>What you have said above is true for Flash disks like SDHC,
> Compact Flash, etc but is not true for SSDs. These can be treated just like
> a normal hard disk.

Not entire true. They are still subject to wear out, but due to wear
leveling you are talking about sectors going bad in years, rather than
flash drives, where in the pathological case you could see sectors
failing in just days. That said, you still do have to take some steps
to get the best life out of the drive.

Anything that writes lots of data on a regular basis would be better
done on a HDD. While things like video recording would be the obvious
case, you likely wouldn't even think to try that due to the limited
capacity. But as I mentioned in my previous post, the mysql temporary
tables generated by the myth scheduler can actually eat through the
rated life of the drive in just a few years.

Now I hear people say sometimes "well, in a couple years SSDs will be
faster and cheaper, so who cares". Well, in 3 or 4 years, I'll bet
that a 40GB SSD will still be more than plenty of space for a
dedicated mythtv system to run in. I'd also bet that the perceived
increase in performance would be negligible too. On my Win7 system, I
really don't perceive a difference between my 3rd gen Intel SSD and
the 1st gen that I bought 3 years before that. So my thinking is, in
3-4 years, unless you enjoy throwing money away you probably wouldn't
have a compelling reason to replace your working SSD in your myth
system. So I think it's well worth it to try and make the drive last
as long as possible since it takes minimal effort.

--
Ron Frazier
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


ylee at pobox

Oct 8, 2012, 12:53 PM

Post #7 of 38 (2086 views)
Permalink
Re: SSD disk for DB [In reply to]

Ronald Frazier <ron [at] ronfrazier> says:
> The only thing I found to be causing significant wear were the mysql
> temporary tables created by the myth scheduler running several times
> an hour. I solved this my moving /tmp to memory, but other's said it
> could just as well be solved by configuring mysql to put temp tables
> in memory by altering some settings in my.cnf

Be careful with this. I found that mysql would sometimes create
temporary files of up to 3.5GB in size when running certain functions,
such as if a SQL statement in Custom Edit is accidentally made too
broad[1] or the "Time" search from Schedule Recordings. As my systems
do not have more than 2GB of RAM, I had to move away from mounting
/tmp in memory in /etc/fstab with tmpfs to back to disk.

[1] An example is

program.title = ('Family Guy') OR program.title = ('The Simpsons')

If the above is incorrectly written as

program.title = ('Family Guy' OR 'The Simpsons')

mythbackend essentially writes its entire scheduling data to disk as
it searches through it. mythfrontend itself has a 10,000-line limit on
search returns (<URL:http://code.mythtv.org/trac/ticket/4626>), which
is more than sufficient for any sane query but not in this case.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jra at baylink

Oct 8, 2012, 2:23 PM

Post #8 of 38 (2090 views)
Permalink
Re: SSD disk for DB [In reply to]

----- Original Message -----
> From: "Ronald Frazier" <ron [at] ronfrazier>

> >What you have said above is true for Flash disks like SDHC,
> > Compact Flash, etc but is not true for SSDs. These can be treated
> > just like a normal hard disk.
>
> Not entire true. They are still subject to wear out, but due to wear
> leveling you are talking about sectors going bad in years, rather than
> flash drives, where in the pathological case you could see sectors
> failing in just days. That said, you still do have to take some steps
> to get the best life out of the drive.

Nope: SSDs are made of *RAM*. If you want them to retain anything at all
they have to be battery backed. And being made of RAM, they aren't subject
to wear-leveling or anything; they don't wear any more than main memory
does.

In fact, unless you need a whole lot of ephemeral storage on a system
where it's impractical to install it as main memory and make a ramdisk
out of it, they have little justification -- especially at their price,
which is uniformly pretty high.

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


matt at mossholder

Oct 8, 2012, 2:30 PM

Post #9 of 38 (2083 views)
Permalink
Re: SSD disk for DB [In reply to]

On Mon, Oct 8, 2012 at 5:23 PM, Jay Ashworth <jra [at] baylink> wrote:

> Nope: SSDs are made of *RAM*. If you want them to retain anything at all
> they have to be battery backed. And being made of RAM, they aren't subject
> to wear-leveling or anything; they don't wear any more than main memory
> does.
>
> In fact, unless you need a whole lot of ephemeral storage on a system
> where it's impractical to install it as main memory and make a ramdisk
> out of it, they have little justification -- especially at their price,
> which is uniformly pretty high.
>
> Cheers,
> -- jra
>

No, these days most SSDs are made of Flash memory. It is persistent memory,
and does not require current to retain data.

--Matt


douglasw0 at gmail

Oct 8, 2012, 2:40 PM

Post #10 of 38 (2086 views)
Permalink
Re: SSD disk for DB [In reply to]

On Mon, Oct 8, 2012 at 4:23 PM, Jay Ashworth <jra [at] baylink> wrote:

> ----- Original Message -----
> > From: "Ronald Frazier" <ron [at] ronfrazier>
>
> > >What you have said above is true for Flash disks like SDHC,
> > > Compact Flash, etc but is not true for SSDs. These can be treated
> > > just like a normal hard disk.
> >
> > Not entire true. They are still subject to wear out, but due to wear
> > leveling you are talking about sectors going bad in years, rather than
> > flash drives, where in the pathological case you could see sectors
> > failing in just days. That said, you still do have to take some steps
> > to get the best life out of the drive.
>
> Nope: SSDs are made of *RAM*. If you want them to retain anything at all
> they have to be battery backed. And being made of RAM, they aren't subject
> to wear-leveling or anything; they don't wear any more than main memory
> does.
>
> In fact, unless you need a whole lot of ephemeral storage on a system
> where it's impractical to install it as main memory and make a ramdisk
> out of it, they have little justification -- especially at their price,
> which is uniformly pretty high.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth Baylink
> jra [at] baylink
> Designer The Things I Think RFC
> 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land
> Rover DII
> St Petersburg FL USA #natog +1 727 647
> 1274
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

No offence Jay, but you might want to check your source on this comment
since I FULLY believe you've got some misinformation here.

SSD's are not "made of RAM", they execute somewhat similar to RAM, yes,
since both are "solid state" but that's about as far as the similarities
extend. While you are correct that 'RAM' is not subject to wear-leveling,
SSD's absolutely are subject to wear leveling...just like your flash drive
or USB stick is.

Re: Battery Backed...er...no. You can power your system off, disconnect
your SSD Disk and carry it across country to your friend's house, plug it
back in and it will still have data...there's no "internal battery" that
will discharge on you in a few years and thus cause you to lose your data
when you power off or unplug your machine...the technology is VERY
different.

Regarding an in memory disk: I'm going to jump out into an area I have
VERY LITTLE experience with and say: You can't "store" your Myth TV
Database within a ramdisk. The moment that machine goes off and/or needs
rebooted, that ramdisk is gone and so is whatever you've copied to
it...randisks are for TEMPORARY storage only (like /tmp). There are things
you could do (upon startup say) to copy your MYSQL tables to a RAMDISK at
startup and then use them (you'd have to have some kind of system that
copies them back / syncs them periodically). I have no idea how any of
this would work, but I suspect it's possible...still, SSD would be a much
"safer" method of working with any of this as an SSD is handled LIKE A
HARDDRIVE by the OS instead of like RAM.

--Doug


Hall.JamesR at gmail

Oct 8, 2012, 3:04 PM

Post #11 of 38 (2087 views)
Permalink
Re: SSD disk for DB [In reply to]

This is hilarious, thanks for making my day. :)

On Mon, Oct 8, 2012 at 5:23 PM, Jay Ashworth <jra [at] baylink> wrote:

> ----- Original Message -----
> > From: "Ronald Frazier" <ron [at] ronfrazier>
>
> > >What you have said above is true for Flash disks like SDHC,
> > > Compact Flash, etc but is not true for SSDs. These can be treated
> > > just like a normal hard disk.
> >
> > Not entire true. They are still subject to wear out, but due to wear
> > leveling you are talking about sectors going bad in years, rather than
> > flash drives, where in the pathological case you could see sectors
> > failing in just days. That said, you still do have to take some steps
> > to get the best life out of the drive.
>
> Nope: SSDs are made of *RAM*. If you want them to retain anything at all
> they have to be battery backed. And being made of RAM, they aren't subject
> to wear-leveling or anything; they don't wear any more than main memory
> does.
>
> In fact, unless you need a whole lot of ephemeral storage on a system
> where it's impractical to install it as main memory and make a ramdisk
> out of it, they have little justification -- especially at their price,
> which is uniformly pretty high.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth Baylink
> jra [at] baylink
> Designer The Things I Think RFC
> 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land
> Rover DII
> St Petersburg FL USA #natog +1 727 647
> 1274
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>


joe at thefrys

Oct 8, 2012, 3:08 PM

Post #12 of 38 (2088 views)
Permalink
Re: SSD disk for DB [In reply to]

> > >What you have said above is true for Flash disks like SDHC,
>> > > Compact Flash, etc but is not true for SSDs. These can be treated
>> > > just like a normal hard disk.
>> >
>> > Not entire true. They are still subject to wear out, but due to wear
>> > leveling you are talking about sectors going bad in years, rather than
>> > flash drives, where in the pathological case you could see sectors
>> > failing in just days. That said, you still do have to take some steps
>> > to get the best life out of the drive.
>>
>> Nope: SSDs are made of *RAM*. If you want them to retain anything at all
>> they have to be battery backed. And being made of RAM, they aren't
>> subject
>> to wear-leveling or anything; they don't wear any more than main memory
>> does.
>>
>> In fact, unless you need a whole lot of ephemeral storage on a system
>> where it's impractical to install it as main memory and make a ramdisk
>> out of it, they have little justification -- especially at their price,
>> which is uniformly pretty high.
>
>
> No offence Jay, but you might want to check your source on this comment
> since I FULLY believe you've got some misinformation here.
>
> SSD's are not "made of RAM", they execute somewhat similar to RAM, yes,
> since both are "solid state" but that's about as far as the similarities
> extend. While you are correct that 'RAM' is not subject to wear-leveling,
> SSD's absolutely are subject to wear leveling...just like your flash drive
> or USB stick is.
>
> Re: Battery Backed...er...no. You can power your system off, disconnect
> your SSD Disk and carry it across country to your friend's house, plug it
> back in and it will still have data...there's no "internal battery" that
> will discharge on you in a few years and thus cause you to lose your data
> when you power off or unplug your machine...the technology is VERY
> different.
>
> Regarding an in memory disk: I'm going to jump out into an area I have
> VERY LITTLE experience with and say: You can't "store" your Myth TV
> Database within a ramdisk. The moment that machine goes off and/or needs
> rebooted, that ramdisk is gone and so is whatever you've copied to
> it...randisks are for TEMPORARY storage only (like /tmp). There are things
> you could do (upon startup say) to copy your MYSQL tables to a RAMDISK at
> startup and then use them (you'd have to have some kind of system that
> copies them back / syncs them periodically). I have no idea how any of
> this would work, but I suspect it's possible...still, SSD would be a much
> "safer" method of working with any of this as an SSD is handled LIKE A
> HARDDRIVE by the OS instead of like RAM.
>

Actually you are both right and wrong. Any storage media based on solid
state storage would be considered an SSD. There are definitely SSD's based
on volatile memory coupled with a battery to preserve data during reboots
and short outages, however they are generally only used in special
applications. These days its rare to hear someone talk about that type of
SSD in the context of consumer products.


jra at baylink

Oct 8, 2012, 3:47 PM

Post #13 of 38 (2090 views)
Permalink
Re: SSD disk for DB [In reply to]

----- Original Message -----
> From: "Matt Mossholder" <matt [at] mossholder>

> No, these days most SSDs are made of Flash memory. It is persistent
> memory, and does not require current to retain data.

<sigh>

I see they've allowed the abbreviation to become muddled.

SSD meant, very specifically, something built out of RAM, for *quite a long
time* before anything of any practical size was built out of Flash.

https://en.wikipedia.org/wiki/Solid-state_drive

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jra at baylink

Oct 8, 2012, 3:50 PM

Post #14 of 38 (2085 views)
Permalink
Re: SSD disk for DB [In reply to]

----- Original Message -----
> From: "Douglas Wagner" <douglasw0 [at] gmail>

> No offence Jay, but you might want to check your source on this
> comment since I FULLY believe you've got some misinformation here.

My source was 30 years of industry experience and following the vendor
market, Doug. See the Wikipedia article I quoted; RAM based SSDs date to
the late 70s and early-mid 80s; Flash wasn't remotely practical until 1995.

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


bkamen at benjammin

Oct 8, 2012, 3:52 PM

Post #15 of 38 (2096 views)
Permalink
Re: SSD disk for DB [In reply to]

On 2012-10-08 5:50 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Douglas Wagner" <douglasw0 [at] gmail>
>
>> No offence Jay, but you might want to check your source on this
>> comment since I FULLY believe you've got some misinformation here.
>
> My source was 30 years of industry experience and following the vendor
> market, Doug. See the Wikipedia article I quoted; RAM based SSDs date to
> the late 70s and early-mid 80s; Flash wasn't remotely practical until 1995.

I'd have to chime in too - I remember SSD's for the IBM PC's I used to repair for businesses back in the 80's.

MMMm, RAM Cards with battery backups plugged into ISA Card slots... hahaha...

Ancient.

-Ben
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jra at baylink

Oct 8, 2012, 3:52 PM

Post #16 of 38 (2086 views)
Permalink
Re: SSD disk for DB [In reply to]

----- Original Message -----
> From: "Joseph Fry" <joe [at] thefrys>

> Actually you are both right and wrong. Any storage media based on solid
> state storage would be considered an SSD. There are definitely SSD's based
> on volatile memory coupled with a battery to preserve data during reboots
> and short outages, however they are generally only used in special
> applications. These days its rare to hear someone talk about that type
> of SSD in the context of consumer products.

Well, perhaps. But in fact, one of the most common places that RAM-SSDs
were used was *underneath fast-moving tables in big databases*, so you might
understand why that was where my mind went first.

That was when it was impractical to buy a motherboard that would take
256GB of SDRAM, much less of a problem today. Today, you put it on a
ramdisk, and make your bootscripts copy it in and out.

And make sure you have a *really* good UPS. :-)

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


ron at ronfrazier

Oct 8, 2012, 5:36 PM

Post #17 of 38 (2069 views)
Permalink
Re: SSD disk for DB [In reply to]

On Mon, Oct 8, 2012 at 3:53 PM, Yeechang Lee <ylee [at] pobox> wrote:
> Ronald Frazier <ron [at] ronfrazier> says:
>> The only thing I found to be causing significant wear were the mysql
>> temporary tables created by the myth scheduler running several times
>> an hour. I solved this my moving /tmp to memory, but other's said it
>> could just as well be solved by configuring mysql to put temp tables
>> in memory by altering some settings in my.cnf
>
> Be careful with this. I found that mysql would sometimes create
> temporary files of up to 3.5GB in size when running certain functions,
> such as if a SQL statement in Custom Edit is accidentally made too
> broad[1] or the "Time" search from Schedule Recordings. As my systems
> do not have more than 2GB of RAM, I had to move away from mounting
> /tmp in memory in /etc/fstab with tmpfs to back to disk.
>
> [1] An example is
>
> program.title = ('Family Guy') OR program.title = ('The Simpsons')
>
> If the above is incorrectly written as
>
> program.title = ('Family Guy' OR 'The Simpsons')
>
> mythbackend essentially writes its entire scheduling data to disk as
> it searches through it. mythfrontend itself has a 10,000-line limit on
> search returns (<URL:http://code.mythtv.org/trac/ticket/4626>), which
> is more than sufficient for any sane query but not in this case.

Good point. However, I wonder how mysql and myth would react to
running out of memory for the temp table? I'd assume mysql would just
generate an error (rather than crash), and that mythfrontend would
likewise detect the failed query. I'd say that it might be preferable
to have it error out on some monstrously huge query that I almost
surely didn't intend, rather than just going and going and going and
going and then getting me a ridiculously huge result set 5 minutes
later.

--
Ron Frazier
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


ron at ronfrazier

Oct 8, 2012, 5:38 PM

Post #18 of 38 (2067 views)
Permalink
Re: SSD disk for DB [In reply to]

On Mon, Oct 8, 2012 at 5:23 PM, Jay Ashworth <jra [at] baylink> wrote:
> Nope: SSDs are made of *RAM*. If you want them to retain anything at all
> they have to be battery backed.

Where have YOU been the last 5 years?
:-)

--
Ron Frazier
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


ylee at pobox

Oct 8, 2012, 6:04 PM

Post #19 of 38 (2071 views)
Permalink
Re: SSD disk for DB [In reply to]

Ronald Frazier <ron [at] ronfrazier> says:
> I wonder how mysql and myth would react to running out of memory for
> the temp table? I'd assume mysql would just generate an error
> (rather than crash), and that mythfrontend would likewise detect the
> failed query.

I've seen mythbackend both crash and not crash in such
circumstances. Another way to generate extra-large results is
previewing a schedule change without making any changes; I find
mythbackend crashes roughly half the time (on 0.25) in such cases,
with a

QMYSQLResult::cleanup: unable to free statement handle

on the console, and a message in dmesg like

mythbackend[7071]: segfault at a1 ip 00000000000000a1 sp
00007fd06ef7b1d8 error 14 in mythbackend[400000+1aa000]
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


nick.rout at gmail

Oct 8, 2012, 6:27 PM

Post #20 of 38 (2064 views)
Permalink
Re: SSD disk for DB [In reply to]

On Tue, Oct 9, 2012 at 2:04 PM, Yeechang Lee <ylee [at] pobox> wrote:
> Ronald Frazier <ron [at] ronfrazier> says:
>> I wonder how mysql and myth would react to running out of memory for
>> the temp table? I'd assume mysql would just generate an error
>> (rather than crash), and that mythfrontend would likewise detect the
>> failed query.
>
> I've seen mythbackend both crash and not crash in such
> circumstances. Another way to generate extra-large results is
> previewing a schedule change without making any changes; I find
> mythbackend crashes roughly half the time (on 0.25) in such cases,
> with a

Man it's great that people find bugs and test systems to the max, but
I now have a vision of Yeechang hunched over his mythbox trying to
find new ways to crash-test it. It was just sudden vision, like
something out of an xkcd cartoon.

Sorry just had to share that!

>
> QMYSQLResult::cleanup: unable to free statement handle
>
> on the console, and a message in dmesg like
>
> mythbackend[7071]: segfault at a1 ip 00000000000000a1 sp
> 00007fd06ef7b1d8 error 14 in mythbackend[400000+1aa000]
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jedi at mishnet

Oct 8, 2012, 7:02 PM

Post #21 of 38 (2066 views)
Permalink
Re: SSD disk for DB [In reply to]

On Mon, Oct 08, 2012 at 01:22:26PM +0200, Josu Lazkano wrote:
> Hello all,
>
> I am configuring my new backend, and want to know your opinion about
> put the DB on a SSD disk.
>
> This is a small 8GB disk, is this a good idea? I read that if I write
> lots of times on a SSD, it use to break faster than a normal disk.

My master backend seems to be much happier on an SSD. The database
is much more responsive. I wouldn't go for anything as tiny as 8G for
a backend though. You might want to have some room for backups and such.

[deletia]
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jedi at mishnet

Oct 8, 2012, 7:08 PM

Post #22 of 38 (2070 views)
Permalink
Re: SSD disk for DB [In reply to]

On Mon, Oct 08, 2012 at 04:40:15PM -0500, Douglas Wagner wrote:
> On Mon, Oct 8, 2012 at 4:23 PM, Jay Ashworth <jra [at] baylink> wrote:
>
> > ----- Original Message -----
> > > From: "Ronald Frazier" <ron [at] ronfrazier>
> >
> > > >What you have said above is true for Flash disks like SDHC,
> > > > Compact Flash, etc but is not true for SSDs. These can be treated
> > > > just like a normal hard disk.
> > >
> > > Not entire true. They are still subject to wear out, but due to wear
> > > leveling you are talking about sectors going bad in years, rather than
> > > flash drives, where in the pathological case you could see sectors
> > > failing in just days. That said, you still do have to take some steps
> > > to get the best life out of the drive.
> >
> > Nope: SSDs are made of *RAM*. If you want them to retain anything at all
> > they have to be battery backed. And being made of RAM, they aren't subject
> > to wear-leveling or anything; they don't wear any more than main memory
> > does.
> >
> > In fact, unless you need a whole lot of ephemeral storage on a system
> > where it's impractical to install it as main memory and make a ramdisk
> > out of it, they have little justification -- especially at their price,
> > which is uniformly pretty high.

[deletia]

> No offence Jay, but you might want to check your source on this comment
> since I FULLY believe you've got some misinformation here.

It sounds like his information is a bit out of date. I worked with an
enterprise grade SSD device in 2001 that fits his description. A Crucial
or OCZ SSD is nothing like that though.

[deletia]

SSD's are great for random IO which is what you tend to hit hard with
most databases.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


gary.buhrmaster at gmail

Oct 8, 2012, 7:33 PM

Post #23 of 38 (2062 views)
Permalink
Re: SSD disk for DB [In reply to]

On Mon, Oct 8, 2012 at 7:08 PM, jedi <jedi [at] mishnet> wrote:
....
> SSD's are great for random IO which is what you tend to hit hard with
> most databases.

Random *read* I/O (because the seek time is closer to zero).
Whether they are great for *write* I/O depends on their designs
(the seek time is still closer to zero, but (re)writing blocks
may take some time in some designs, and databases tend
to insist on durable writes (data committed to "disk") in order
to insure ACID compliance). As with much else, your mileage
will vary.

I will note that for most MythTV users, a well tuned cache
essentially eliminates all (read) I/O too (we are not talking
about a one PB database, more like a few hundred megabytes,
which can fit in memory cache). Unfortunately, the mysql
defaults in most distros really suck, so that putting the database
on SSD looks to be a great win. There are some good (initial)
suggestions on the MythTV wiki regarding mysql tuning.

Gary
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jra at baylink

Oct 8, 2012, 8:07 PM

Post #24 of 38 (2066 views)
Permalink
Re: SSD disk for DB [In reply to]

----- Original Message -----
> From: "Ronald Frazier" <ron [at] ronfrazier>

> On Mon, Oct 8, 2012 at 5:23 PM, Jay Ashworth <jra [at] baylink> wrote:
> > Nope: SSDs are made of *RAM*. If you want them to retain anything at
> > all they have to be battery backed.
>
> Where have YOU been the last 5 years?
> :-)

The question is really 'where was everyone else the last 30?'. :-) SSDs
didn't become "generally" flash until about 2008 or so. So the term
meant '5.25" disk box full of DRAM' a *lot* longer than it's meant what
everyone uses it for now.

Not my fault you young whippersnappers weren't paying attention. ;-)

Cheers,
-- jr 'get offa my lawn, yes' a
--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jra at baylink

Oct 8, 2012, 8:10 PM

Post #25 of 38 (2062 views)
Permalink
Re: SSD disk for DB [In reply to]

----- Original Message -----
> From: "Gary Buhrmaster" <gary.buhrmaster [at] gmail>

> On Mon, Oct 8, 2012 at 7:08 PM, jedi <jedi [at] mishnet> wrote:
> ....
> > SSD's are great for random IO which is what you tend to hit hard
> > with
> > most databases.
>
> Random *read* I/O (because the seek time is closer to zero).
> Whether they are great for *write* I/O depends on their designs
> (the seek time is still closer to zero, but (re)writing blocks
> may take some time in some designs, and databases tend
> to insist on durable writes (data committed to "disk") in order
> to insure ACID compliance). As with much else, your mileage
> will vary.

Note too that you have to *know that your device isn't lying to you
about whether it's written the data*; this is often more information than
you can get without (sometimes destructive) testing, from consumer component
vendors. And we already know that Flash SSD controller manufacturers
lie about some things (though I'm damned if I remember what; bit the
Linux driver people a couple years ago).

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.