IDS Forum

Re: Ridiculous Crashes : 7.31xD on HP 11.0

Posted By:
Date:

----- Original Message -----
To: malcolmw@fast24.co.uk
At: 3/26 8:29

Several commercial applications, notably SAP and PeopleSoft, have 10,000-30,000
tables, that's the main reason. Also there are instances, like our development
servers here, where you may have over 100 databases with a few dozen to a
hundred tables each yielding thousands of DD entries.

Art S. Kagel

----- Original Message -----
From: Malcolm Weallans <malcolmw@fast24.co.uk>
At: 3/26 5:51

> Hello,
> I am very interested in this question as at the moment I am working on a
> problem in this area. Our problem is that we have evidence from onstat of
> data dictionary thrashing on one node of a large network of
> machines. The other nodes appear to be OK. On investigation of the
> failing node we discovered that the dictionary cache was thrashing due to
> the fact that there are 4 copies of the database on this node but this is
> the only node with 4 copies. We have increased the number of
> caches(DD_HASHSIZE) to 31 and the size(DD_HASMAX) to 32 and reduced the
> amount of swapping going on.
> My query is why would anybody set large numbers for DD_HASHSIZE and or
> DD_HASHMAX? We have about 80 tables per Database. Even allowing for about
> 30 system tables that still only gets to 110. We are nowhere near the 8000
> figure talked of elsewhere. Or have I missed something?
>
> regards
>
> Malcolm
>
> At 06:14 PM 25-03-03 +0100, Michael Mueller wrote:
> >Hi,
> >
> >The reason why I "believe" this is that I have been working for Informix
> > in the support area for more than 10 years and know the source code
> >of the server quite well. I also have been working on some bugs in this
> >area.
> >
> >DD_HASHSIZE configures the size of a hash list which looks like this:
> >
> > list[0] -> e -> e -> e-> e -> e
> > list[1] -> e -> e ->
> > ...
> > list[DD_HASHSIZE-1] -> e -> e -> e-> e
> >
> >Every e is an entry containing a table name + a pointer to the table
> >data (This is what onstat -g dic shows). A table is added to the cache
> >by computing its hash value n. The table then goes into list[n]. This
> >computation is done by adding all the character codes of the table name
> >and by taking the sum modulo DD_HASHSIZE. The critical point about the
> >hash list is that the chains shouldn't get too long and that entries are
> >distributed more or less evenly.
> >
> >It seems that some people believe that this can be achieved in a better
> >way if DD_HASHSIZE is a prime number. But I don't think this is true.
> >(You could play around with different values of DD_HASHSIZE and look at
> >the hash list using onstat -g dic.)
> >
> >If you still have contact to people who told you this I would be
> >interested in what their arguments are.
> >
> >Michael
> >
> >ART KAGEL, BLOOMBERG/ 65E 55TH wrote:
> > >>From the Informix Administrator's Reference P 1-35:
> > >
> > > DD_HASHSIZE ....
> > >
> > > range of values Any positive prime number
> > >
> > > Belief has nothing to do with it. BTW, when this was undocumented it
> > was I who
> > > spoke to the developers to determine the appropriate range of values
before
> > > publishing the parameter in my article for TechNotes (Vol 8, no 3). So,
> > I know
> > > of what I speak.
> > >
> > > Art S. Kagel
> > >
> > > ----- Original Message -----
> > > From: Michael Mueller <michael.mueller@kay-mueller.de>
> > > At: 3/25 3:53
> > >
> > >
> > >>Hi,
> > >>
> > >>I know that Informix made people believe that cache parameters like
> > >>DD_HASHSIZE must be a prime number. But I seen no reason for this. I
> > >>even doubt that it makes any difference. The last thing I would expect
> > >>is a crash if it is not. If a bug is sensitive to this parameter, my
> > >>only conclusion is that it is probably related to the cache mechanism.
> > >>Maybe it goes away if the cache is made so big that nothing is ever
> > >>thrown out of the cache.
> > >>
> > >>Michael
> > >>
> > >>Art S. Kagel wrote:
> > >>
> > >>>On Fri, 21 Mar 2003 11:38:46 -0500, Rudy wrote:
> > >>>
> > >>>
> > >>>
> > >>>>Guys,
> > >>>>
> > >>>>I'm going nuts over this one...
> > >>>>
> > >>>>For the past few months, a specific development instance (out of our 40
> > >>>>odd) has been crashing periodically. Informix Tech support has suggested
> > >>>>that its something to do with the DD_HASHMAX & DD_HASHSIZE parameters
> > >>>>... and they are probably right because the problem has reduced after
> > >>>>fiddling with them. However, the problem has not gone away. Besides, I'm
> > >>>
> > >>><SNIP>
> > >>>
> > >>>Yes, the problem is likely the DD_HASHSIZE which MUST BE A PRIME NUMBER!
> > >>>None of the values below (8001, 8003) is prime except 4001! Try 8009 if
> > >>>you want a value about double the 4001 number. Were you having problems
> > >>>when it was 4001 or only since trying to change it?
> > >>>
> > >>>
> > >>>
> > >>>># DD_HASHSIZE 4001
> > >>>># rudy Mon Mar 17 16:33:21 EST 2003. Further changes (attempt both prime
> > >>>>numbers)
> > >>>># DD_HASHSIZE 8001
> > >>>># DD_HASHMAX 257
> > >>>>DD_HASHSIZE 8003
> > >>>>DD_HASHMAX 20
> > >>>
> > >>>
> > >>>Art S. Kagel
> > >>>
> > >>
> > >
> > >
> > >
> >
> >
> >--
> >
> >=== Michael Mueller ==================
> >Tel. + 49 8171 63600
> >Fax. + 49 8171 63615
> >Web: http://www.mm.kay-mueller.de
> > http://www.planets.kay-mueller.de
> >======================================
> >
> >

Messages In This Thread

• Redbrick
  Loo, Peter -- Friday, 17 January 2003, at 4:22 a.m.
  • Re: Redbrick
    Obnoxio The Clown -- Friday, 17 January 2003, at 5:41 a.m.
    • Re: Ridiculous Crashes : 7.31xD on HP 11.0
      ART KAGEL, BLOOMBERG/ 65E 55TH -- Wednesday, 26 March 2003, at 8:32 a.m.
    • Re: shmat: : out of shared memory segments, ch....
      Art Kagel -- Monday, 13 July 2009, at 9:49 p.m.
      • RE: shmat: : out of shared memory segments, ch....
        Knox, Ernest -- Monday, 13 July 2009, at 9:59 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.