[Ocfs-devel] Re:Re:Re: [Ocfs-users] Re: Mode context extremely poor
performance.
Michael Aubertin
maubertin at ares.fr
Wed Nov 24 10:19:42 CST 2004
David,
Thank u very much for your help. In deed it would be great to have your case number. Could you also send us the result of:
rpm -qa --changelog kernel-smp-2.4.18-e.47.6.5
rpm -qa --changelog hp_qla2x00src-7.01.01-12
rpm -qa --changelog Secure-Path-3.0CFull64-4.0RHEL2.1special
Thank U again.
Athos10.
Original message:
---------------
From:David McWhinnie <davidmcwhinnie at yahoo.com>
To:Michael Aubertin <maubertin at ares.fr>
Cc:
Yes, It was built just for us. They spent a couple
months troubleshooting our problem both on site and in
their labs (although they never did reproduce our
problem), and then gave us a new version of
securepath. Eventually the changes they made were
going to go into the next version, but I'm not sure
when. The Linux Kernel we are using is "special" from
RedHat as well, and not generally available.
I'll see if I can track down our case numbers. Maybe
from that you could try the same version.
--- Michael Aubertin wrote:
>
>
> Hi,
>
> Could you tell me where did you find your "special"
> version of SecurePath please. Is it a customized e47
> version by HP for U ?
>
> Tks again.
> Friendly.
> Michael.
>
>
>
>
> Original message:
> ---------------
> From:David McWhinnie
> To:Aubertin Michael ,
> ocfs-users at oss.oracle.com
> Cc:igaste at ares.fr, a.brunel at ilius.net,
> gpedurand at ares.fr, ocfs-devel at oss.oracle.com
>
> We had very similar problems, but was more
> pronounced
> on writes instead of reads. Have you tried without
> securepath? After working with HP and RedHat we
> found
> there was problems in both the Kernel and SecurePath
> when running OCFS.
> We are running versions.
> ocfs-2.4.18-e-smp-1.0.13-1
> kernel-smp-2.4.18-e.47.6.5
> gcc-2.96-128.7.2
> fileutils-4.1-10.20
> hp_qla2x00src-7.01.01-12 (qlogic driver)
> Secure-Path-3.0CFull64-4.0RHEL2.1special
> --- Aubertin Michael wrote:
> > Hi all,
> >
> > Completary informations, we have already applied
> > this patch:
> > $ opatch lsinventory
> > Installed Patch List:
> > =====================
> > 1) Patch 3849952 applied on Thu Nov 18 17:19:48
> CET
> > 2004
> > [ Base Bug(s): 3849952 ]
> > 2) Patch 3887769 applied on Tue Nov 09 18:01:09
> CET
> > 2004
> > [ Base Bug(s): 3588448 ]
> > 3) Patch 3802975 applied on Thu Nov 04 03:37:25
> CET
> > 2004
> > [ Base Bug(s): 3553791 ]
> >
> > The issue is already the same.
> >
> > Thank you for your help.
> >
> > Athos10.
> >
> >
> > Le lundi 22 novembre 2004 à 16:46 +0100, Aubertin
> > Michael a écrit :
> > > Hi all,
> > >
> > > I curently have a big problem. One request
> (listed
> > above) using context
> > > take up to 1000 more time than the on RAW or
> ext2
> > database. I have ran
> > > this request on a single IA32 machine with
> Redhat
> > and dbf on ext2. The
> > > average reponse time is less than a sec. The
> same
> > request on RAC 4 nodes
> > > cluster on RAW take the same average time. On
> ext2
> > idem. But on OCFS it
> > > took up to 15 sec randomly between
> > 1sec>responce_time>15sec.
> > >
> > > We tried to ran the request on a single itanium
> > (without RAC) on OCFS. -
> > > > sameproblem.
> > > We tries to ran the request on single nodes
> > without RAC with only DBF
> > > file on OCFS. -> Same problem.
> > > We tried to run several version of OCFS -> same
> > problem.
> > >
> > > We bench a few storage throuput with no revelant
> > bottle neck. And in RAW
> > > device the reponse time is perfect.
> > >
> > > I read OCFS source a recompile it in debug mode.
> I
> > can see that the same
> > > number of reading block demand (according to the
> > sql log) follow an
> > > increasing amount of ocfs_get_block2() call. In
> > consequence the request
> > > reponse time is dramaticaly increase. I tried to
> > put more verbose debug
> > > trace in ocfs_create_or_open_file() in order to
> > grab to oin.hndl
> > > releasing token, but i don't konw enough OCFS
> > desing yet to be
> > > performant, so i write to you to have help.
> > >
> > > First question: Could you help me please .....
> > ;-).
> > > Second: I see in the source you use VFS dentry
> > struture. In the RH
> > > 2.4.18 I2 kernel this structure was little
> > modified to be more "2.6"
> > > looked like. Is it cannot be the problem ?
> > (Pointer to nowhere ? Gcc
> > > BUG ?...)
> > >
> > > Thank you by advance for any help.
> > > Athos10
> > > aka
> > > Michael Aubertin.
> > >
> > > Trace log available at:
> > > -----------------------
> > > http://athos10.dyndns.org
> > >
> > >
> > > Software architecture:
> > > ---------------------
> > > Oracle 9.2.0.5
> > > OCFS tested: 1.0.11 / 1.0.12 / 1.0.13 (all have
> > the same problem).
> > > Redhat AS 2.1 kernel e-41smp ITANIUM
> > > gcc 2.96-128.7.2
> > > fileutils 4.1-10.6
> > > qlogic version 7.00.03 with HP register patch
> > >
> >
>
(ftp://ftp.hp.com/pub/softlib/software4/COL9063/co-24300-1/contrfailure.patch)
> > > secure-path-3.0.cfull64-4.0.
> > >
> > > Hardware architecture:
> > > ----------------------
> > > 2 HP EVA3000 with Continious access real time
> > replication.
> > > 2 * 4 nodes HP RX4640 Itanium entry level
> > servers.
> > >
> > >
> > > SQL Request:
> > > ------------
> > >
> > > SELECT COUNT(*) FROM SNAP.VWMT_PROFIL_MATCH_FH
> > > WHERE CONTAINS (RECH_CRITERES, ' RZFR') > 0
> > > /
> > >
> > >
> > > The table:
> > > ----------
> > >
> > >
> > > SQL> desc snap.vwmt_profil_match_a_fh
> > > Name Null? Type
> > > ----------------------- --------
> ----------------
> > > ABO_ID NOT NULL NUMBER(11)
> > > ABO_PHO NUMBER
> > > ABO_PAYS VARCHAR2(4)
> > > ABO_REGION NUMBER(11)
> > > ABO_DEPARTEMENT NUMBER(11)
> > > ABO_VILLE NUMBER(11)
> > > ABO_CP VARCHAR2(50)
> > > PROF_AGE NUMBER(4)
> > > PROF_STATUT NUMBER(11)
> > > PROF_TAILLE NUMBER(11)
> > > PROF_POIDS NUMBER(11)
> > > PROF_SILH NUMBER(4)
> > > PROF_CHEVEUX NUMBER(4)
> > > PROF_YEUX NUMBER(4)
> > > PROF_ETHN NUMBER(4)
> > > PROF_STYLE NUMBER(4)
> > > PROF_REVENUS NUMBER(4)
> > > PROF_ENFANTS NUMBER(4)
> > > PROF_ENF_SOUHAIT NUMBER(4)
> > > PROF_CAT_PROF NUMBER(4)
> > > PROF_ETUDES NUMBER(4)
> > > PROF_FUMEUR NUMBER(4)
> > > PROF_NB_PHOTOS NUMBER(4)
> > > PROF_DATE_CREATION DATE
> > > PROF_DATE_MAJ DATE
> > > PROF_NATIONALITE NUMBER(11)
> > > PROF_LANGUE NUMBER(20)
> > > PROF_ANNONCE NUMBER(11)
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
****************************************************************************************************
Ce message ou ses pieces jointes peuvent contenir des informations confidentielles a l'intention exclusive de son destinataire et est couvert par le secret professionnel.
Toute utilisation, divulgation ou reproduction de son contenu sont strictement interdits.
Si vous avez recu ce message par erreur, merci de le notifier a son expediteur et d'en detruire toute copie.
Le present message pouvant-etre altere a notre insu, le groupe ARES ne peut pas etre engage par son contenu.
www.ares.fr
****************************************************************************************************
More information about the Ocfs-devel
mailing list