[Ocfs-devel] Re: [Ocfs-users] Re: Mode context extremely poor performance.

BRUNEL Antoine a.brunel at ilius.net
Tue Nov 23 09:17:29 CST 2004


Hello

I already tried without using the Secure Path agent, and without accessing 
devices through '/dev/spdev' links.... but without success.
And our problems are more related to small reads....

thanks for your update anyway


----- Original Message ----- 
From: "David McWhinnie" <davidmcwhinnie at yahoo.com>
To: "Aubertin Michael" <maubertin at ares.fr>; <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>
Sent: Tuesday, November 23, 2004 4:13 PM
Subject: Re: [Ocfs-users] Re: Mode context extremely poor performance.


> 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 <maubertin at ares.fr> 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)
>> >  PROF_ANNONCE_VOC                 NUMBER(4)
>> >  AUTH_ACCES                       DATE
>> >  ANN_DATE_MAJ                     DATE
>> >  ABO_PSEUDO                       VARCHAR2(50)
>> >  PROF_LOOK                        NUMBER(4)
>> >  PROF_VIDEO                       NUMBER(4)
>> >  PERSO_ROMANTIQUE                 NUMBER(4)
>> >  PERSO_ATTIRANT                   NUMBER(20)
>> >  PERSO_MARIAGE                    NUMBER(4)
>> >  PERSO_CHEVEUXSTYLE               NUMBER(4)
>> >  PERSO_RELIGION                   NUMBER(4)
>> >  INSC_DATE_INSC                   DATE
>> >  RECH_AGE_MINI                    NUMBER
>> >  RECH_AGE_MAXI                    NUMBER
>> >  RECH_TAILLE_MINI                 NUMBER
>> >  RECH_TAILLE_MAXI                 NUMBER
>> >  RECH_POIDS_MINI                  NUMBER
>> >  RECH_POIDS_MAXI                  NUMBER
>> >  RECH_CRITERES                    VARCHAR2(4000)
>> >  ZERANK                           NUMBER
>> >
>> >
>> > The index:
>> > ----------
>> >
>> >
>> >
>> > create index
>> SNAP.CTX_PROFIL_MATCH_${ROLE}_${SEX}_01
>> > on SNAP.vwmt_PROFIL_match_${ROLE}_${SEX}
>> (RECH_CRITERES)
>> > indextype is ctxsys.context PARAMETERS ('MEMORY
>> 50M STORAGE
>> > text_storage')
>> > /
>> >
>> >
>> > with:
>> > -----
>> >
>> >
>> > BEGIN
>> ctx_ddl.create_preference('SYS.TEXT_STORAGE',
>> >     'BASIC_STORAGE');
>> ctx_ddl.set_attribute('SYS.TEXT_STORAGE',
>> > 'I_INDEX_CLAUSE',
>> >  'pctfree 0 tablespace TBS_SNAP_INDEX');
>> >     ctx_ddl.set_attribute('SYS.TEXT_STORAGE',
>> 'I_ROWID_INDEX_CLAUSE',
>>
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 



More information about the Ocfs-devel mailing list