thr3ads.net - Ocfs users - [Ocfs-users] Mode context extremely poor performance. [Nov 2004]

If this information is useful, please help other people find it:
Share via:

Aubertin Michael

2004-Nov-22 09:53 UTC

[Ocfs-users] Mode context extremely poor performance.

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',
   'pctfree 0 tablespace TBS_SNAP_INDEX');
    ctx_ddl.set_attribute('SYS.TEXT_STORAGE', 'I_TABLE_CLAUSE',
    'pctfree 0 tablespace TBS_SNAP_INDEX');
    ctx_ddl.set_attribute('SYS.TEXT_STORAGE', 'K_TABLE_CLAUSE',
    'pctfree 0tablespace TBS_SNAP_DATA');
    ctx_ddl.set_attribute('SYS.TEXT_STORAGE', 'N_TABLE_CLAUSE',
    'pctfree 0 tablespace TBS_SNAP_DATA');
    ctx_ddl.set_attribute('SYS.TEXT_STORAGE', 'P_TABLE_CLAUSE',
    'pctfree 0 tablespace TBS_SNAP_DATA');
    ctx_ddl.set_attribute('SYS.TEXT_STORAGE', 'R_TABLE_CLAUSE',
--    'compress pctfree 0 pctused 99
    'pctfree 0 pctused 99 tablespace TBS_SNAP_INDEX');
end;
/



-- 
Aubertin Michael <maubertin@ares.fr>



****************************************************************************************************
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
****************************************************************************************************

Aubertin Michael

2004-Nov-23 05:42 UTC

head link

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

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',
>    'pctfree 0 tablespace TBS_SNAP_INDEX');
>     ctx_ddl.set_attribute('SYS.TEXT_STORAGE',
'I_TABLE_CLAUSE',
>     'pctfree 0 tablespace TBS_SNAP_INDEX');
>     ctx_ddl.set_attribute('SYS.TEXT_STORAGE',
'K_TABLE_CLAUSE',
>     'pctfree 0tablespace TBS_SNAP_DATA');
>     ctx_ddl.set_attribute('SYS.TEXT_STORAGE',
'N_TABLE_CLAUSE',
>     'pctfree 0 tablespace TBS_SNAP_DATA');
>     ctx_ddl.set_attribute('SYS.TEXT_STORAGE',
'P_TABLE_CLAUSE',
>     'pctfree 0 tablespace TBS_SNAP_DATA');
>     ctx_ddl.set_attribute('SYS.TEXT_STORAGE',
'R_TABLE_CLAUSE',
> --    'compress pctfree 0 pctused 99
>     'pctfree 0 pctused 99 tablespace TBS_SNAP_INDEX');
> end;
> /
> 
> 
> -- 
Aubertin Michael <maubertin@ares.fr>



****************************************************************************************************
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
****************************************************************************************************

David McWhinnie

2004-Nov-23 09:13 UTC

head link

[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@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

Michael Aubertin

2004-Nov-24 10:22 UTC

head link

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

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@yahoo.com>
To:Michael Aubertin <maubertin@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@oss.oracle.com
> Cc:igaste@ares.fr, a.brunel@ilius.net,
> gpedurand@ares.fr, ocfs-devel@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
****************************************************************************************************

Reasonably Related Threads

Search for more reasonably related threads

Ocfs users - Nov 2004 - Mode context extremely poor performance.

[Ocfs-users] Mode context extremely poor performance.

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

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

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

Reasonably Related Threads