[Info-Ingres] Ingres 2.6 on Solaris 10: createdb slow

[izena at mixmail.com]

Surely you could have already done it, but just in case some simple
checks. I am not a system administrator but this has helped me before
to have some track of what was happening. Sometimes, inadvertely, some
data flows such as trasaction, data, etc  that should go to
independant physical devices or channels turn to share one. Sometimes
it is not easy to see or  detect depending on how the phisical layer
is logically map to the system.

Use df -k to see the underlying mapping of logical to phisical
devices. Then use "iostat 1" (configured to list the interesting
devices used by ingres: db, log, jnl et al) and see, for example, what
happens when log data is put into disk. (Known the device of logging
system, you will see periodically some data transfers to it) You could
see Cpu raising more than it should in this moment and/or other data
writing stopped (wrongly waiting for device or channel) that will warn
about some issue there.

As I said I am not a system admin, and this could have no sense in new
systems or simply on yours (or be wrong).

Anyway, hope it helps

Carlos


On 23 abr, 11:05, William Yuan <y... at ariel.its.unimelb.edu.au> wrote:
> Hi David,
>
>         I tend to agree with you, but RAID5 is what the System Admin group chose
>         to use on the filesystems (along with ufs). We are using high-speed 15k
>         disks and the bonnie++ disk benchmarks were as follows:
>
> MOP (Dec AlphaServer ES47, DUnix 5.1B):
>
> > Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
> >                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> > Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
> > mop             16G 21326  44 34862  16 15841   7 35222  79 70801  18 551.1   2
> >                     ------Sequential Create------ --------Random Create--------
> >                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> >               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
> >                  16  1434  33 17575 100  3690  93  2099  51 15927  99  1555  44
>
> AVALON2 (Sun V890, Solaris 10 Zoned):
>
> > Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
> >                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> > Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
> > avalon          32G 57564  93 57542  26 15372  10 40575  93 88694  25 865.1   5
> >                     ------Sequential Create------ --------Random Create--------
> >                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> >               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
> >                  16  3408  28 +++++ +++  3233  24  4106  33 +++++ +++  1934  20
>
> 1. The +++ in the output is where this test was so fast the speed was
>    unmeasurable due to rounding/accuracy errors.)
> 2. The "size" is different due to it being set to be twice the memory in the
>         machine to remove memory caching effects.
>
>         We are seeing fairly good throughput on the Solaris box, in general it's
>         50-200% faster on disk ops. I don't know how much of the Bonnie benchmarks
>         involve simulation of high disk contention or multiple writes.
>
>         Thanks for your reply and I'll check out the link.
>
> Kind Regards,
>
>         William
>
>
>
> On Mon, 23 Apr 2007, David Richard wrote:
>
> > Hi William,
>
> > Are you sure that you want to use RAID 5 when you need very fast disk
> > writes?
>
> > Take a look athttp://www.baarf.com/to see why RAID 5 is very bad write
> > intensive disk operations!
>
> > HTH
>
> > Richard
>
> > ************************************************************************
> > DISCLAIMER
> > The information contained in this e-mail is confidential and is intended
> > for the recipient only.
> > If you have received it in error, please notify us immediately by reply
> > e-mail and then delete it from your system. Please do not copy it or
> > use it for any other purposes, or disclose the content of the e-mail
> > to any other person or store or copy the information in any medium.
> > The views contained in this e-mail are those of the author and not
> > necessarily those of Admenta UK Group.
>
> > Admenta UK plc is a company incorporated in England and Wales
> > under company number 3011757 and whose registered office
> > is at Sapphire Court, Walsgrave Triangle, Coventry CV2 2TX
> > ************************************************************************
>
> > _______________________________________________
> > Info-Ingres mailing list
> > Info-Ing... at kettleriverconsulting.com
> >http://www.kettleriverconsulting.com/mailman/listinfo/info-ingres
>
> Kind Regards,
>
>         William
> --------------------------------------------------------------------------
> | William Yuan                       Email: y... at unimelb.edu.au          |
> | DBA-Ingres Team Leader/IT Analyst  Tel:  +61 3 8344 2862               |
> | Information Services               Fax:  +61 3 8344 2885               |
> | The University of Melbourne        Web: ariel.its.unimelb.edu.au/~yuan |
> | Carlton, Victoria  3053            +++ Carlton Gold & U2.com member +++|
> --------------------------------------------------------------------------