switching perl version
A perl program executing in linux Redhat 7.0, perl version 5.6, oracle 8i was using 30% cpu approx. Now I'm running the same program in linux enterprise ES 4, perl v. 5.8.5, Oracle 10g. uses 60% cpu. I'd like to know what's happening because the performance is slower and the difference is wide big. Do you think this perl new version (5.8.5) takes more cpu ? I appreciate any idea you could give me to improve my performance. -- Open WebMail Project (http://openwebmail.org)
RE: switching perl version
Did you run 10046 traces on the code? Have you profiled the code? I switched to these same versions a couple of years ago, and have had no problems. rr -Original Message- From: Oscar Gomez [mailto:[EMAIL PROTECTED] Sent: Friday, September 08, 2006 9:04 AM To: dbi-users@perl.org Subject: switching perl version A perl program executing in linux Redhat 7.0, perl version 5.6, oracle 8i was using 30% cpu approx. Now I'm running the same program in linux enterprise ES 4, perl v. 5.8.5, Oracle 10g. uses 60% cpu. I'd like to know what's happening because the performance is slower and the difference is wide big. Do you think this perl new version (5.8.5) takes more cpu ? I appreciate any idea you could give me to improve my performance. -- Open WebMail Project (http://openwebmail.org) This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
Re: switching perl version
On Sep 8, 2006, at 11:26 AM, Reidy, Ron wrote: Did you run 10046 traces on the code? Have you profiled the code? I switched to these same versions a couple of years ago, and have had no problems. rr -Original Message- From: Oscar Gomez [mailto:[EMAIL PROTECTED] Sent: Friday, September 08, 2006 9:04 AM To: dbi-users@perl.org Subject: switching perl version A perl program executing in linux Redhat 7.0, perl version 5.6, oracle 8i was using 30% cpu approx. Now I'm running the same program in linux enterprise ES 4, perl v. 5.8.5, Oracle 10g. uses 60% cpu. I'd like to know what's happening because the performance is slower and the difference is wide big. Do you think this perl new version (5.8.5) takes more cpu ? I appreciate any idea you could give me to improve my performance. You've changed every aspect of your system. I think Ron's good suggestions are a minimum in terms of researching why the performance is slower. Perl is about the last place I'd look. As for the cpu numbers, higher % cpu should tranlsate to faster performance, everything else equal, which it's not in this case. In particular, I'm told by our sys admin that the Linux 2.4 kernel (i.e. RH 7.0) reports CPU differently than the 2.6 kernel (i.e. ES 4). And I/O scheduling has changed. But this is pretty far off topic for the DBI list. -Chris
RE: switching perl version
The differences are big. I won't go into them here because these are off topic, but if your DB was an 8.1 and migrated in place to 10g, you will have performance problems, especially if there were no changes made to init parameters, you changes hardware platforms (word size), etc. Another poster said Perl is the last place you should look, and I agree. Your issues are almost assuredly database centric. You should eliminate this as a candidate before you do anything else and the best way to do this is process profiling using 10046 trace files to determine the issues. Cary Milsap has a really exceptional book on this subject - http://www.oreilly.com/catalog/optoraclep/. You should get a copy and read it several times because it is a bigger subject than most can imagine. You should also be looking on metalink for answers on how to trace sessions, although the links I sent you the other day should work fine for starters. Performance issues are a large vague subject and until you can pinpoint the issues, you are like a cat chasing its tail - lots of effort, little reward or progress. rr -Original Message- From: Oscar Gomez [mailto:[EMAIL PROTECTED] Sent: Friday, September 08, 2006 9:28 AM To: Reidy, Ron Subject: RE: switching perl version Hi Ron, thanks for your reply I haven't tried the 10046 trace, because I still am studying how to do it. but what is the relationship or the reliance between the cpu performance and oracle under the new versions install. thanks a lot -- Open WebMail Project (http://openwebmail.org) -- Original Message --- From: Reidy, Ron [EMAIL PROTECTED] To: Oscar Gomez [EMAIL PROTECTED], dbi-users@perl.org Sent: Fri, 8 Sep 2006 09:26:47 -0600 Subject: RE: switching perl version Did you run 10046 traces on the code? Have you profiled the code? I switched to these same versions a couple of years ago, and have had no problems. rr -Original Message- From: Oscar Gomez [mailto:[EMAIL PROTECTED] Sent: Friday, September 08, 2006 9:04 AM To: dbi-users@perl.org Subject: switching perl version A perl program executing in linux Redhat 7.0, perl version 5.6, oracle 8i was using 30% cpu approx. Now I'm running the same program in linux enterprise ES 4, perl v. 5.8.5, Oracle 10g. uses 60% cpu. I'd like to know what's happening because the performance is slower and the difference is wide big. Do you think this perl new version (5.8.5) takes more cpu ? I appreciate any idea you could give me to improve my performance. -- Open WebMail Project (http://openwebmail.org) This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system. --- End of Original Message ---
Re: DBD::mysql 3.0004+ not resetting $sth-{Active} after fetch
Addison, Mark wrote:
Mark,
Stumbled upon your email from June, and am very sorry to not have seen
it and responded. I will have a fix for this within days with the
release of DBD::mysql 3.0007/3.0007_1
Kind regards,
Patrick
Hello,
I upgraded DBD::mysql from 2.9006-1 to 3.0006-1 and suddenly started
getting
screens full of errors like:
prepare_cached(SELECT * FROM foo) statement handle
DBIx::ContextualFetch::st=HASH(0x971cc80) still Active at
/usr/share/perl5/Ima/DBI.pm line 381
After some digging it seems that the new version of the DBD::mysql is
failing
to reset the Active attribute on the sth after fetching all the rows.
The
following test script shows this.
#!env perl
use strict;
use warnings;
use DBI;
my $dbh=DBI-connect(
'DBI:mysql:host=localhost;database=test',
'test' = '',
{ RaiseError = 1, PrintError = 1 }
);
my $sql = 'SELECT 1';
my $sth = $dbh-prepare_cached($sql);
print Prepared active:,$sth-{Active},\n;
$sth-execute;
print Executed active:,$sth-{Active},\n;
while ( $sth-fetchrow_hashref ) { }
print Fetched active:,$sth-{Active},\n;
# Prep again to see if we get Still Active warning
$sth = $dbh-prepare_cached($sql);
__END__
On a Debian System with
Linux jhary.itn.local 2.6.16-1-686 #1 Tue Mar 21 14:51:09 UTC 2006 i686
GNU/Linux
DBI 1.50
Perl v5.8.8 built for i486-linux-gnu-thread-multi
DBD::mysql 3.0006-1 or 3.0004-1
$ perl test-dbd-mysql.pl
Prepared active:
Executed active:1
Fetched active:1
prepare_cached(SELECT 1) statement handle DBI::st=HASH(0x82bb238) still
Active
at test-dbd-mysql.pl line 26
If I drop back to DBD::mysql 2.9006-1 it works again.
$ perl test-dbd-mysql.pl
Prepared active:
Executed active:1
Fetched active:
I can't test any other versions as the CPAN source won't complile on
this box
(Mysql deb doesn't seem to include mysql_config which the dbd make
wants)
and apt only offers me these versions.
Calling finish on the handle does reset the flag with any of the dbd
versions.
Playing with the mysql_server_prepare option doesn't seem to make any
difference.
Is anyone else seeing this? It seems odd that it didn't get spotted
through a
couple of release versions (although debian seem to be packaging the
developer
releases).
cheers,
mark
--
MARK ADDISON
WEB DEVELOPER
200 GRAYS INN ROAD
LONDON
WC1X 8XZ
UNITED KINGDOM
T +44 (0)20 7430 4678
F
E [EMAIL PROTECTED]
WWW.ITN.CO.UK
Please Note:
Any views or opinions are solely those of the author and do not necessarily represent
those of Independent Television News Limited unless specifically stated.
This email and any files attached are confidential and intended solely for the use of the individual
or entity to which they are addressed.
If you have received this email in error, please notify [EMAIL PROTECTED]
Please note that to ensure regulatory compliance and for the protection of our
clients and business,
we may monitor and read messages sent to and from our systems.
Thank You.
Re: DBD::mysql 3.0004+ not resetting $sth-{Active} after fetch
On Fri, 2006-09-08 at 11:56 -0400, Patrick Galbraith wrote:
Addison, Mark wrote:
Mark,
Stumbled upon your email from June, and am very sorry to not have seen
it and responded. I will have a fix for this within days with the
release of DBD::mysql 3.0007/3.0007_1
Excellent, my logs will thankyou!
Radoslaw Pociecha has put a patch in the CPAN RT at
http://rt.cpan.org/Public/Bug/Display.html?id=20009
cheers,
mark
Hello,
I upgraded DBD::mysql from 2.9006-1 to 3.0006-1 and suddenly started
getting
screens full of errors like:
prepare_cached(SELECT * FROM foo) statement handle
DBIx::ContextualFetch::st=HASH(0x971cc80) still Active at
/usr/share/perl5/Ima/DBI.pm line 381
After some digging it seems that the new version of the DBD::mysql is
failing
to reset the Active attribute on the sth after fetching all the rows.
The
following test script shows this.
#!env perl
use strict;
use warnings;
use DBI;
my $dbh=DBI-connect(
'DBI:mysql:host=localhost;database=test',
'test' = '',
{ RaiseError = 1, PrintError = 1 }
);
my $sql = 'SELECT 1';
my $sth = $dbh-prepare_cached($sql);
print Prepared active:,$sth-{Active},\n;
$sth-execute;
print Executed active:,$sth-{Active},\n;
while ( $sth-fetchrow_hashref ) { }
print Fetched active:,$sth-{Active},\n;
# Prep again to see if we get Still Active warning
$sth = $dbh-prepare_cached($sql);
__END__
On a Debian System with
Linux jhary.itn.local 2.6.16-1-686 #1 Tue Mar 21 14:51:09 UTC 2006 i686
GNU/Linux
DBI 1.50
Perl v5.8.8 built for i486-linux-gnu-thread-multi
DBD::mysql 3.0006-1 or 3.0004-1
$ perl test-dbd-mysql.pl
Prepared active:
Executed active:1
Fetched active:1
prepare_cached(SELECT 1) statement handle DBI::st=HASH(0x82bb238) still
Active
at test-dbd-mysql.pl line 26
If I drop back to DBD::mysql 2.9006-1 it works again.
$ perl test-dbd-mysql.pl
Prepared active:
Executed active:1
Fetched active:
I can't test any other versions as the CPAN source won't complile on
this box
(Mysql deb doesn't seem to include mysql_config which the dbd make
wants)
and apt only offers me these versions.
Calling finish on the handle does reset the flag with any of the dbd
versions.
Playing with the mysql_server_prepare option doesn't seem to make any
difference.
Is anyone else seeing this? It seems odd that it didn't get spotted
through a
couple of release versions (although debian seem to be packaging the
developer
releases).
cheers,
mark
--
MARK ADDISON
WEB DEVELOPER
200 GRAYS INN ROAD
LONDON
WC1X 8XZ
UNITED KINGDOM
T +44 (0)20 7430 4678
F
E [EMAIL PROTECTED]
WWW.ITN.CO.UK
Please Note:
Any views or opinions are solely those of the author and do not necessarily
represent
those of Independent Television News Limited unless specifically stated.
This email and any files attached are confidential and intended solely for
the use of the individual
or entity to which they are addressed.
If you have received this email in error, please notify [EMAIL PROTECTED]
Please note that to ensure regulatory compliance and for the protection of
our clients and business,
we may monitor and read messages sent to and from our systems.
Thank You.
Please Note:
Any views or opinions are solely those of the author and do not necessarily
represent
those of Independent Television News Limited unless specifically stated.
This email and any files attached are confidential and intended solely for the
use of the individual
or entity to which they are addressed.
If you have received this email in error, please notify [EMAIL PROTECTED]
Please note that to ensure regulatory compliance and for the protection of our
clients and business,
we may monitor and read messages sent to and from our systems.
Thank You.
RE: switching perl version
I would definitely look to Oracle rather than Perl as your culprit. I don't have anything to back this up, just a suspicion. -Original Message- From: Oscar Gomez [mailto:[EMAIL PROTECTED] Sent: Friday, September 08, 2006 10:04 AM To: dbi-users@perl.org Subject: switching perl version A perl program executing in linux Redhat 7.0, perl version 5.6, oracle 8i was using 30% cpu approx. Now I'm running the same program in linux enterprise ES 4, perl v. 5.8.5, Oracle 10g. uses 60% cpu. I'd like to know what's happening because the performance is slower and the difference is wide big. Do you think this perl new version (5.8.5) takes more cpu ? I appreciate any idea you could give me to improve my performance. -- Open WebMail Project (http://openwebmail.org)
RE: switching perl version
What (if any) hardware changes have happened? If you've moved to a machine with lots more RAM a memory intensive program that was paging and swapping could all of a sudden keep more data in memory and become more CPU intensive. That memory could be consumed by either Perl or Oracle or both. -- Jeff Horn -Original Message- From: Oscar Gomez [mailto:[EMAIL PROTECTED] Sent: Friday, September 08, 2006 10:04 AM To: dbi-users@perl.org Subject: switching perl version A perl program executing in linux Redhat 7.0, perl version 5.6, oracle 8i was using 30% cpu approx. Now I'm running the same program in linux enterprise ES 4, perl v. 5.8.5, Oracle 10g. uses 60% cpu. I'd like to know what's happening because the performance is slower and the difference is wide big. Do you think this perl new version (5.8.5) takes more cpu ? I appreciate any idea you could give me to improve my performance. -- Open WebMail Project (http://openwebmail.org)
