Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

Catalyst benchmark 5.7 VS 5.8

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


fayland at gmail

Sep 27, 2009, 10:56 PM

Post #1 of 19 (2301 views)
Permalink
Catalyst benchmark 5.7 VS 5.8

I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8

here is the result from our server: http://scsys.co.uk:8001/34323

the background is
Catalyst 5.7011 VS Catalyst 5.80013
CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
RAM: 4G
OS: Centos5

from the top, each httpd takes 20M more RAM in 5.8 compared with 5.7

5.7
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22979 apache 16 0 167m 142m 4248 S 17.0 3.5 0:06.07 httpd

5.8
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24813 apache 15 0 190m 165m 4000 S 15.6 4.1 0:02.56 httpd


in this case, I really can't let my boss agree me to upgrade the Catalyst.

is it normal? any thoughts?

Thanks.
--
Fayland Lam // http://www.fayland.org/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Sep 28, 2009, 3:23 AM

Post #2 of 19 (2224 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Fayland Lam wrote:
> from the top, each httpd takes 20M more RAM in 5.8 compared with 5.7

No, that'll be 20Mb of RAM _in total_, as all of those pages should be
shared between your apache processes (given that you're preloading your
application in the parent process).

top totally doesn't show how much RAM is shared by copy on write at all,
and so is misleading you here.

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


toby.corkindale at strategicdata

Sep 28, 2009, 5:39 AM

Post #3 of 19 (2225 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

(Apologies for top-posting.. have momentarily lost the option to change quoting styles it seems..)

Fayland, I was looking at the benchmarks that you linked, and was just wondering which version of Perl you're running against?

(CentOS 5 was one of the operating systems that came with the badly-patched Perl with the slow bless performance..
although I'm sure it's been patched by now?
ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
)

Cheers,
Toby

----- Original Message -----
From: Fayland Lam <fayland [at] gmail>
To: catalyst [at] lists
Sent: Mon, 28 Sep 2009 15:56:36 +1000 (EST)
Subject: [Catalyst] Catalyst benchmark 5.7 VS 5.8

I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8

here is the result from our server: http://scsys.co.uk:8001/34323

the background is
Catalyst 5.7011 VS Catalyst 5.80013
CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
RAM: 4G
OS: Centos5

from the top, each httpd takes 20M more RAM in 5.8 compared with 5.7

5.7
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22979 apache 16 0 167m 142m 4248 S 17.0 3.5 0:06.07 httpd

5.8
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24813 apache 15 0 190m 165m 4000 S 15.6 4.1 0:02.56 httpd


in this case, I really can't let my boss agree me to upgrade the Catalyst.

is it normal? any thoughts?

Thanks.
--
Fayland Lam // http://www.fayland.org/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


toby.corkindale at strategicdata

Sep 28, 2009, 5:39 AM

Post #4 of 19 (2224 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Spam detection software, running on the system "mail.somewhere.com", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: (Apologies for top-posting.. have momentarily lost the option
to change quoting styles it seems..) Fayland, I was looking at the benchmarks
that you linked, and was just wondering which version of Perl you're running
against? [...]

Content analysis details: (5.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
3.2 RCVD_ILLEGAL_IP Received: contains illegal IP address
0.4 SPF_HELO_FAIL SPF: HELO does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/Why?s=helo&id=mx.messagefire.com&ip=65.61.166.80&r=mail.somewhere.com]
1.5 WEIRD_PORT URI: Uses non-standard port number for HTTP
Attachments: message-rfc822.eml (5.37 KB)


swatt at infobal

Sep 28, 2009, 7:12 AM

Post #5 of 19 (2230 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Toby Corkindale wrote:
> (CentOS 5 was one of the operating systems that came with the badly-patched Perl with the slow bless performance..
> although I'm sure it's been patched by now?
> ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
> )
>
This issue is still listed as open for Centos;
http://bugs.centos.org/view.php?id=2357

I was surprised at this, but I had checked a couple of months back and
no progress. I gave up on Centos in 1997 because of this, and am
surprised how long this is taking.

All the best
Stuart
--
Stuart Watt
ARM Product Developer
Information Balance


davidslv at gmail

Sep 28, 2009, 8:11 AM

Post #6 of 19 (2221 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Sorry to interrupt, but that is a !!WOW!!

I used CentOS a few weeks ago and i have to say that it could be better if
it was updated... But seems that they are with internal problems ...

2009/9/28 Stuart Watt <swatt [at] infobal>

> Toby Corkindale wrote:
>
> (CentOS 5 was one of the operating systems that came with the badly-patched Perl with the slow bless performance..
> although I'm sure it's been patched by now?
> ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
> )
>
>
> This issue is still listed as open for Centos;
> http://bugs.centos.org/view.php?id=2357
>
> I was surprised at this, but I had checked a couple of months back and no
> progress. I gave up on Centos in 1997 because of this, and am surprised how
> long this is taking.
>
> All the best
> Stuart
> --
> Stuart Watt
> ARM Product Developer
> Information Balance
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>


--
David Silva - http://davidslv.com/


fayland at gmail

Sep 28, 2009, 7:31 PM

Post #7 of 19 (2199 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Toby Corkindale wrote:
> (Apologies for top-posting.. have momentarily lost the option to change quoting styles it seems..)
>
> Fayland, I was looking at the benchmarks that you linked, and was just wondering which version of Perl you're running against?
>
> (CentOS 5 was one of the operating systems that came with the badly-patched Perl with the slow bless performance..
> although I'm sure it's been patched by now?
> ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
> )


Thanks for your update. but it doesn't help on the benchmark since they
are run on the same condition. so 5.7 is really better than 5.8 under siege.

Thanks.


>
> Cheers,
> Toby
>
> ----- Original Message -----
> From: Fayland Lam <fayland [at] gmail>
> To: catalyst [at] lists
> Sent: Mon, 28 Sep 2009 15:56:36 +1000 (EST)
> Subject: [Catalyst] Catalyst benchmark 5.7 VS 5.8
>
> I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8
>
> here is the result from our server: http://scsys.co.uk:8001/34323
>
> the background is
> Catalyst 5.7011 VS Catalyst 5.80013
> CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
> RAM: 4G
> OS: Centos5
>
> from the top, each httpd takes 20M more RAM in 5.8 compared with 5.7
>
> 5.7
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 22979 apache 16 0 167m 142m 4248 S 17.0 3.5 0:06.07 httpd
>
> 5.8
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 24813 apache 15 0 190m 165m 4000 S 15.6 4.1 0:02.56 httpd
>
>
> in this case, I really can't let my boss agree me to upgrade the Catalyst.
>
> is it normal? any thoughts?
>
> Thanks.


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


fayland at gmail

Sep 28, 2009, 7:32 PM

Post #8 of 19 (2198 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Tomas Doran wrote:
> Fayland Lam wrote:
>> from the top, each httpd takes 20M more RAM in 5.8 compared with 5.7
>
> No, that'll be 20Mb of RAM _in total_, as all of those pages should be
> shared between your apache processes (given that you're preloading your
> application in the parent process).
>
> top totally doesn't show how much RAM is shared by copy on write at all,
> and so is misleading you here.
>

do you know how to do a real benchmark? the siege result shows 5.7 is
better under pressure.

Thanks.


> Cheers
> t0m
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


andrew at cleverdomain

Sep 28, 2009, 9:02 PM

Post #9 of 19 (2205 views)
Permalink
Re: Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

On Monday 28 September 2009 09:31:13 pm Fayland Lam wrote:
> Toby Corkindale wrote:
> > Fayland, I was looking at the benchmarks that you linked, and was just
> > wondering which version of Perl you're running against?
> >
> > (CentOS 5 was one of the operating systems that came with the
> > badly-patched Perl with the slow bless performance.. although I'm sure
> > it's been patched by now?
> > ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
> > )
>
> Thanks for your update. but it doesn't help on the benchmark since they
> are run on the same condition. so 5.7 is really better than 5.8 under
> siege.
>
That doesn't follow. If your perl is broken and very slow at doing something
that 5.8 does much more often, then 5.8 can be slower for you without being
slower for everyone else.

I have a real app and a suitable test system at hand -- I'll run some benches
of my own and at least add a few more data points to the mix.

Andrew

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


andrew at cleverdomain

Sep 28, 2009, 9:07 PM

Post #10 of 19 (2201 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

On Monday 28 September 2009 12:56:36 am Fayland Lam wrote:
> I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8

Benchmark, as requested. View this message at http://p3m.org/pfn/3499 if your
mailer is too high-tech for fixed-width text.


The Setup:

Linux 2.6 OpenVZ, on Quad 2.2GHz Opteron.
Perl 5.10.0 + debian patches.
FastCGI via Apache 2.2, mpm_event, mod_fastcgi.
The two test instances were running on the same machine, with the same perl
and the same checkout of the app, but different local::lib directories.

FastCGI was set to 10 processes. The page I was hitting was from a real
checkout of a real production app, however it was the front page of the
site, which is fairly light on dynamic content. I figured this was
appropriate since it would better show any differences in Catalyst rather
than spending a lot of time in the backend. The code still hits several
models, 3 actions, and a view, but perhaps it was a little too fast since,
as you'll see below, my throughput was ultimately limited by the number of
running processes. Each instance was given a "warmup" run (the results of
which were discarded) before the following tests were run. My tool collects
statistics on the return status, but for all tests the returns were all 200
(success) so I've left out that row.

|| 20 requests/second (20 threads) for 60s
| Metric || Catalyst 5.7010 || Catalyst 5.8011
|===================||==========================||==========================
| Hits || 1200 || 1200
| Throughput || 20.00 req/s || 20.00 req/s
| Latency (mean) || 0.072s || 0.074s
| Latency (SD) || 0.013s || 0.017s
| Latency (Q1-Q3) || 0.064 - 0.078s || 0.066 - 0.080s

|| 40 requests/second (40 threads) for 60s
| Metric || Catalyst 5.7010 || Catalyst 5.8011
|===================||==========================||==========================
| Hits || 2400 || 2400
| Throughput || 40.00 req/s || 40.00 req/s
| Latency (mean) || 0.083s || 0.088s
| Latency (SD) || 0.020s || 0.024s
| Latency (Q1-Q3) || 0.069 - 0.095s || 0.072 - 0.100s

|| 80 requests/second (80 threads) for 60s
| Metric || Catalyst 5.7010 || Catalyst 5.8011
|===================||==========================||==========================
| Hits || 4675 || 4637
| Throughput || 77.92 req/s || 77.28 req/s
| Latency (mean) || 0.688s || 0.708s
| Latency (SD) || 0.178s || 0.187s
| Latency (Q1-Q3) || 0.617 - 0.800s || 0.726 - 0.811s

The difference between 5.7 and 5.8 in these results is consistently in favor
of 5.7, but by a margin of between 0% and 5% which is not a whole lot in my
book. By my unscientific measure (i.e. looking at "top") of memory usage,
5.7 used 138MB of RAM (for fcgi-pm + 10x fcgi children) whereas 5.8 used
184MB, so that's a 33% expansion, which is a more significant issue. I have
a feeling that most of that is shared, and so the difference wouldn't
increase much with an increase in the number of processes, but I haven't
investigated that yet.

Questions?

Andrew "hobbs" Rodland

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


fayland at gmail

Sep 28, 2009, 10:22 PM

Post #11 of 19 (2202 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Thanks for that. (Toby Corkindale too)

I'll do more research and update you later.

Thanks.

Andrew Rodland wrote:
> On Monday 28 September 2009 12:56:36 am Fayland Lam wrote:
>> I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8
>
> Benchmark, as requested. View this message at http://p3m.org/pfn/3499 if your
> mailer is too high-tech for fixed-width text.
>
>
> The Setup:
>
> Linux 2.6 OpenVZ, on Quad 2.2GHz Opteron.
> Perl 5.10.0 + debian patches.
> FastCGI via Apache 2.2, mpm_event, mod_fastcgi.
> The two test instances were running on the same machine, with the same perl
> and the same checkout of the app, but different local::lib directories.
>
> FastCGI was set to 10 processes. The page I was hitting was from a real
> checkout of a real production app, however it was the front page of the
> site, which is fairly light on dynamic content. I figured this was
> appropriate since it would better show any differences in Catalyst rather
> than spending a lot of time in the backend. The code still hits several
> models, 3 actions, and a view, but perhaps it was a little too fast since,
> as you'll see below, my throughput was ultimately limited by the number of
> running processes. Each instance was given a "warmup" run (the results of
> which were discarded) before the following tests were run. My tool collects
> statistics on the return status, but for all tests the returns were all 200
> (success) so I've left out that row.
>
> || 20 requests/second (20 threads) for 60s
> | Metric || Catalyst 5.7010 || Catalyst 5.8011
> |===================||==========================||==========================
> | Hits || 1200 || 1200
> | Throughput || 20.00 req/s || 20.00 req/s
> | Latency (mean) || 0.072s || 0.074s
> | Latency (SD) || 0.013s || 0.017s
> | Latency (Q1-Q3) || 0.064 - 0.078s || 0.066 - 0.080s
>
> || 40 requests/second (40 threads) for 60s
> | Metric || Catalyst 5.7010 || Catalyst 5.8011
> |===================||==========================||==========================
> | Hits || 2400 || 2400
> | Throughput || 40.00 req/s || 40.00 req/s
> | Latency (mean) || 0.083s || 0.088s
> | Latency (SD) || 0.020s || 0.024s
> | Latency (Q1-Q3) || 0.069 - 0.095s || 0.072 - 0.100s
>
> || 80 requests/second (80 threads) for 60s
> | Metric || Catalyst 5.7010 || Catalyst 5.8011
> |===================||==========================||==========================
> | Hits || 4675 || 4637
> | Throughput || 77.92 req/s || 77.28 req/s
> | Latency (mean) || 0.688s || 0.708s
> | Latency (SD) || 0.178s || 0.187s
> | Latency (Q1-Q3) || 0.617 - 0.800s || 0.726 - 0.811s
>
> The difference between 5.7 and 5.8 in these results is consistently in favor
> of 5.7, but by a margin of between 0% and 5% which is not a whole lot in my
> book. By my unscientific measure (i.e. looking at "top") of memory usage,
> 5.7 used 138MB of RAM (for fcgi-pm + 10x fcgi children) whereas 5.8 used
> 184MB, so that's a 33% expansion, which is a more significant issue. I have
> a feeling that most of that is shared, and so the difference wouldn't
> increase much with an increase in the number of processes, but I haven't
> investigated that yet.
>
> Questions?
>
> Andrew "hobbs" Rodland
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


tobias.kremer at gmail

Sep 29, 2009, 12:28 AM

Post #12 of 19 (2196 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

On Mon, Sep 28, 2009 at 12:23 PM, Tomas Doran <bobtfish [at] bobtfish> wrote:
> top totally doesn't show how much RAM is shared by copy on write at all, and
> so is misleading you here.

So, what's a better way to find out how much memory is shared? On our
production servers "top" shows

VIRT: 70116, RES: 64m, SHR: 3480

and I hope that 3480 is really not the amount of memory that is shared
because that'd be quite low.

Thanks!

--Tobias

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


catalyst at fadetoblack

Sep 29, 2009, 1:32 AM

Post #13 of 19 (2204 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Toby Corkindale wrote:
> (CentOS 5 was one of the operating systems that came with the
> badly-patched Perl with the slow bless performance..
> although I'm sure it's been patched by now?
> ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
> )

Was patched last year - stop spreading FUD.

The RHEL/CentOS perl build isn't the best one is the world but it's adequate
enough for most uses. Too much FUD will just scare decision makers who don't
understand the technical details and just see perl + RHEL = fail.

Carl


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


catalyst at fadetoblack

Sep 29, 2009, 1:44 AM

Post #14 of 19 (2202 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Tobias Kremer wrote:
> So, what's a better way to find out how much memory is shared? On our
> production servers "top" shows
>
> VIRT: 70116, RES: 64m, SHR: 3480
>
> and I hope that 3480 is really not the amount of memory that is shared
> because that'd be quite low.

It's a different type of shared. That's amount of memory used through shared
OS libraries.

What everybody else in this thread is referring to as "shared" memory is
actually the amount of memory that hasn't needed to be duplicated because of
the copy-on-write semantics within the Linux kernel. Unfortunately there's
currently no easy way I know of to get these figures on Linux.

Carl


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


andrew at cleverdomain

Sep 29, 2009, 2:19 AM

Post #15 of 19 (2194 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

On Tuesday 29 September 2009 03:44:33 am Carl Johnstone wrote:
> What everybody else in this thread is referring to as "shared" memory is
> actually the amount of memory that hasn't needed to be duplicated because
> of the copy-on-write semantics within the Linux kernel. Unfortunately
> there's currently no easy way I know of to get these figures on Linux.

In my experience with linux+perl+fastcgi, "VmHWM - (VmExe + VmLib)" (stats
from /proc/*/status) gives a reasonable upper bound on the incremental cost of
a process -- that is, how much your "free memory" total will go up or down if
you add or remove one process. It's a loose upper bound because the stuff that
it knows to subtract is quite unlikely to become unshared, but there's a bunch
of data that's probably being shared that it doesn't know about. For an
example: the formula above gives 14,900kB when applied to an instance of a
beta app that I happen to have at hand; actually killing an instance gives an
increase in free memory (as reported by "free") of 11,400kB, so the error is
3,500kB. The error depends on the app, but it's otherwise pretty consistent,
which makes this a good enough tool to use for a "kill processes that start
chewing memory" script.

Andrew

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Sep 29, 2009, 4:41 AM

Post #16 of 19 (2201 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Tobias Kremer wrote:
> and I hope that 3480 is really not the amount of memory that is shared
> because that'd be quite low.

Shared memory indicates things which are shared at a library linking
level (e.g. libc is a shared object which both processes will share).

This has nothing to do with the copy-on-write memory which is shared.
(I.e. your parent process loads the application, then calls fork - each
process sees 'its own copy' of all the RAM, but only pages written to
are copied - the rest remain "shared").

Cheers
t0m


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Sep 29, 2009, 4:43 AM

Post #17 of 19 (2194 views)
Permalink
Re: Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Fayland Lam wrote:
> Tomas Doran wrote:

>> top totally doesn't show how much RAM is shared by copy on write at
>> all, and so is misleading you here.
>
> do you know how to do a real benchmark? the siege result shows 5.7 is
> better under pressure.

I didn't actually do any 'real' benchmarking for this, I just pointed
out that the conclusions you were drawing from top were rubbish.

Andrew and Tobys memory benchmarks make sense and are much nearer what
I'd expect.

1.5Mb more per process is much more reasonable than the 20Mb you were
speculating initially.

Cheers
t0m


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


autarch at urth

Sep 29, 2009, 7:03 AM

Post #18 of 19 (2200 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

On Tue, 29 Sep 2009, Carl Johnstone wrote:

> What everybody else in this thread is referring to as "shared" memory is
> actually the amount of memory that hasn't needed to be duplicated because of
> the copy-on-write semantics within the Linux kernel. Unfortunately there's
> currently no easy way I know of to get these figures on Linux.

http://www.selenic.com/smem/

This can give you some good numbers on shared memory.


-dave

/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


toby.corkindale at strategicdata

Sep 29, 2009, 5:27 PM

Post #19 of 19 (2183 views)
Permalink
Re: Catalyst benchmark 5.7 VS 5.8 [In reply to]

Carl Johnstone wrote:
> Toby Corkindale wrote:
>> (CentOS 5 was one of the operating systems that came with the
>> badly-patched Perl with the slow bless performance..
>> although I'm sure it's been patched by now?
>> ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
>> )
>
> Was patched last year - stop spreading FUD.

OK, well do you want to get CentOS to close the bug on it then? :P

http://bugs.centos.org/view.php?id=2357

(I sent an email to some CentOS-using friends asking them what's up and
I see they added a note to the bottom of the bug just yesterday..)
For those of us not using Centos, but helping others, we can only go on
what we read. It IS the official bugtracker for centos, isn't it? If we
can't trust it, what CAN we trust?)

> The RHEL/CentOS perl build isn't the best one is the world but it's adequate
> enough for most uses. Too much FUD will just scare decision makers who don't
> understand the technical details and just see perl + RHEL = fail.

Well, that pretty much WAS the case for quite a long time :(

Glad to hear it's finally fixed up though.

tjc

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.