[asterisk-users] Asterisk RT on Disk On Module Performance
andDurability
Aaron Daniel
amdtech at shsu.edu
Mon Oct 9 13:47:44 MST 2006
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 at 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 at 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 at shsu.edu
(936) 294-4198
More information about the asterisk-users
mailing list