[asterisk-users] Asterisk RT on Disk On Module PerformanceandDurability

Douglas Garstang
Mon, 09 Oct 2006 14:00:33 -0000

I'd be curious to know what you come up with, because we're using MySQL,
and I'd rather not!

> -----Original Message-----
> From: Aaron Daniel [mailto:amdtech@shsu.edu]
> Sent: Monday, October 09, 2006 2:48 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [asterisk-users] Asterisk RT on Disk On Module
> PerformanceandDurability
>
>
> Very very carefully ;)  I'm thinking pizza, and maybe some red-bull...
> very little time for sleep
>
> Aaron
>
> On Mon, 2006-10-09 at 14:19 -0600, Douglas Garstang wrote:
> > I'm just going to jump in here, and ask a stoopid question.
> >
> > How could you possibly write a multi-user front end in AJAX without
> > using a database backend like MySQL?
> >
> > Doug.
> >         -----Original Message-----
> >         From: Erick Perez [mailto:eaperezh@gmail.com]
> >         Sent: Monday, October 09, 2006 1:58 PM
> >         To: Asterisk Users Mailing List - Non-Commercial Discussion
> >         Subject: Re: [asterisk-users] Asterisk RT on Disk On Module
> >         Performance andDurability
> >
> >
> >         Jeremy, Cohen, Kris, thanks to all of you.
> >
> >         Indeed after reading the Sandisk paper it shed a
> lot of light
> >         on this matter. The whole idea is to have a large
> scale system
> >         with no moving parts (we call a large system something
> >         with 250 users, at least down here ;-)  )
> >
> >         the whole idea is for a customer that needs an IVR in 4
> >         languages with autoattendant, extensive CDR and
> plotted usage
> >         patterns as well as voicemail. Voicemail will be
> used *a lot*,
> >         probably about one thousand voicemails per day and the
> >         customer does not want VM-to-Email (God knows why!).
> >
> >         Oh, and the whole idea of the database is because the
> >         developers are working in an AJAX based interface that does
> >         the asterisk config/plotting/vm/day-to-day stuff
> with ARA, so
> >         a db is needed.
> >         I started learning asterisk with flat files...it works for
> >         me...but hey...times are changing.
> >
> >         Who knows, maybe the whole thing can be fitted in
> ram (except
> >         for the vm part)...we'll see. I had to ask anyway,
> but i don't
> >         like Dbs either....it adds and extra breakup layer (maybe Im
> >         kind of outdated).
> >
> >         Smaller iPBXs will definitely be CF and RAM based and I, at
> >         least, will force VMtoEmail and do all the
> processing in RAM.
> >
> >         Again,
> >
> >         Thanks to all of you.
> >
> >         P.D. I will later follow this thread with the full working
> >         configs that will take place at user premises. And for the
> >         sake of the test. I will try to kill a sandisk USB with the
> >         full config.
> >
> >
> >         On 10/8/06, Kristian Kielhofner <kris@krisk.org> wrote:
> >                 Jeremy McNamara wrote:
> >                 > Tzafrir Cohen wrote:
> >                 >  > Hmmmm, I'm not sure that this is
> exactly the data
> >                 you're after.
> >                 >>
> >                 >> You're looking for the ammounts of writes
for the
> >                 disk block that gets
> >                 >> the most writes.
> >                 >>
> >                 >> E.g: for a standard ext3 filesystem, the
journal
> >                 area would probably
> >                 >> have very frequent writes, whereas most of
the
> >                 system would remain
> >                 >> mostly unchanged.
> >                 >
> >                 >
> >                 > Again, if the embedded system is setup properly,
> >                 there is NO writing to
> >                 > the flash during normal operations, thus
> the device
> >                 won't be killed by
> >                 > its alleged 2 million write limitation.
> >                 >
> >                 > Kris and I had a quick discussion on this topic,
> >                 off-list, and his
> >                 > original flash-based device is still in constant
> >                 operation after 2 years
> >                 > and I have flash modules that I purposely tried
to
> >                 kill with writes. It
> >                 > took significant effort to start causing error
> >                 situations, which were
> >                 > very easily detected before the system
> would become
> >                 unusable.
> >                 >
> >                 > Erick, you should focus on having a quick action
> >                 restoration plan and
> >                 > extra DOMs always readily available.  Then when a
> >                 failure situation is
> >                 > detected, you can react very quickly.
> >                 >
> >                 >
> >                 >
> >                 >
> >                 > Jeremy McNamara
> >
> >                 Jeremy, Erick -
> >
> >                        I have always pointed to this SanDisk
> >                 whitepaper:
> >
> >
> http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures
> /RS-MMC/WPaperWearLevelv1.0.pdf
> >
> >                        While it specifically discusses their
> >                 industrial line of CF cards, it
> >                 is pretty obvious that flash can, and often
> does, last
> >                 much longer than
> >                 other components in a system when properly
> >                 implemented.  You will notice
> >                 that the SHORTEST expected life of a CF
> card in their
> >                 test scenarios was
> >                 over 70 years!  How long is your power
> supply going to
> >                 last?  Even if
> >                 the consumer level cards had 1/10 the life
> expectancy,
> >                 that is still
> >                 seven years.  I expect to get at least that from my
> >                 original AstLinux
> >                 system.  It's been two so far, I'll let you
know how
> >                 it is doing in
> >                 another five years :).
> >
> >                        JFFS (and similar FSs) are not
> appropriate for
> >                 CF cards or DOMs.  They
> >                 are meant to be used directly on flash memory and do
> >                 their own wear
> >                 leveling and in some cases, compression.
> All kinds of
> >                 commercial
> >                 devices use JFFS2.  If you are using a CF
> or DOM with
> >                 Linux, ext2 is the
> >                 best FS to use.  CF cards and DOMs use
> their own wear
> >                 leveling, so none
> >                 is required in the operating system or file
> >                 system.  CF cards and DOMs
> >                 hide wear leveling from you and expose themselves as
> >                 an ordinary IDE device.
> >
> >                        I echo Jeremy's conclusions.  With a
properly
> >                 designed operating
> >                 system, decent flash memory, and a reasonable usage
> >                 pattern, I can tell
> >                 you (with a great amount of certainty) that in most
> >                 situations, CF cards
> >                 will outlast just about any hard drive (even SCSI)
> >                 when used 24/7.
> >                 These days, it really is pretty tough to
> trash flash.
> >
> >                        However, if you are running a MySQL
> cluster or
> >                 something with several,
> >                 multi-gigabyte databases, no type of flash
> memory will
> >                 last very long! :)
> >
> >                        To get back to answering your question, I
> >                 HIGHLY recommend that you
> >                 avoid MySQL and realtime on your box with a
> >                 DOM.  Nothing against either
> >                 (MySQL or Realtime), but they will probably
> make your
> >                 device more
> >                 complicated than it needs to be while substantially
> >                 shortening the life
> >                 of your DOM.  If you absolutely have to use
> MySQL, you
> >                 might have better
> >                 luck using a MySQL storage engine that uses fewer
> >                 writes than InnoDB,
> >                 but I am no expert on that.
> >
> >                 --
> >                 Kristian Kielhofner
> >                 _______________________________________________
> >                 --Bandwidth and Colocation provided by
> Easynews.com --
> >
> >                 asterisk-users mailing list
> >                 To UNSUBSCRIBE or update options visit:
> >
http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
>
>         --
>         ------------------------------------------------------------
>         Erick Perez
>         Panama Sistemas
>         Integradores de Telefonia IP y Soluciones Para Centros de
>         Datos
>         Panama, Republica de Panama
>         Cel Panama. +(507) 6694-4780
>         ------------------------------------------------------------
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
--
Aaron Daniel
Computer Systems Technician
Sam Houston State University
amdtech@shsu.edu
(936) 294-4198

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit: