eaccelerator-developers — list to eAccelerator developers, discuss and control the project and code.

Re: [eAccelerator-developers] 0.9.5 Beta2 is out

[Rodolfo G. G. <ro...@eq...>]

On Tue, 11 Apr 2006, Bart Vanbrabant wrote:
> Beta2 of the 0.9.5 release is out. Get is while it's hot and fresh. More
> information like release notes and changelog can be found on the website:
> https://www.eaccelerator.net/wiki/Release-0.9.5-beta2

Hi Bart,

exiting! it's been working with Prado 2.1 (www.xisc.com) with all the 
cases which didn't work previously (and still don't work with Zend 
Platform nor with APC). Good work!.

Regards,
Rodolfo.

[eAccelerator-developers] 0.9.5 Beta2 is out

[Bart V. <bar...@zo...>]

Hello everyone,

Beta2 of the 0.9.5 release is out. Get is while it's hot and fresh. More
information like release notes and changelog can be found on the website:=

https://www.eaccelerator.net/wiki/Release-0.9.5-beta2

For the people who don't like the sf.net to download eAccelerator you
can get it from here (server is located in Europe):
http://bart.eaccelerator.net/source/0.9.5/

mvg,

Bart

--=20
Bart Vanbrabant <bar...@zo...>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1

Re: [eAccelerator-developers] http://eaccelerator.net/wiki/Faq

[Steve B. <st...@bl...>]

<jumping in>

It does *something* with php-cgi.exe, because on my setup (W2K3, PHP 5.12),
not only does the disk cache fill up with scripts as pages are requested,
but the speed is roughly 40% faster with eA enabled.  Plus, if I delete the
cache, the initial page requests are at the regular (slow) speed, then as
the cache starts getting hits again, the speeds for subsequent requests are
much faster.

So, it may not be doing everything it would on a php_mod setup, but it IS
doing something to speed things up.  Of course, this is disk-only cache...
apparently shared memory doesn't work on my setup.

Steve

On 3/28/06, Bart Vanbrabant <bar...@zo...> wrote:
>
> Vyacheslav Chernousov wrote:
> > Hi all.
> >
> > I see new page in wiki - http://eaccelerator.net/wiki/Faq
> >
> > Latest question is about EA working with php-cgi or php-cli. And I was
> > wondered  with  answer:  "This  is  not  yet supported and it won't be
> > supported in the near future."
> >
> > I'm using php-cgi and php-cli (5.1.2) with latest EA from SVN and
> > it works good for me. At least I see compiled scripts in
> > eaccelerator.cache_dir and also:
> >
> > ~ # php -v
> > PHP 5.1.2-gentoo (cli) (built: Mar 16 2006 12:54:26)
> > Copyright (c) 1997-2006 The PHP Group
> > Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
> >     with eAccelerator v0.9.5-dev, Copyright (c) 2004-2006 eAccelerator,
> by eAccelerator
> >     with Xdebug v2.0.0beta5, Copyright (c) 2002, 2003, 2004, 2005, by
> Derick Rethans
> >
> >
> > ~ # php-cgi -v
> > PHP 5.1.2-gentoo (cgi-fcgi) (built: Mar 16 2006 13:06:55)
> > Copyright (c) 1997-2006 The PHP Group
> > Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
> >     with eAccelerator v0.9.5-dev, Copyright (c) 2004-2006 eAccelerator,
> by eAccelerator
> >     with Xdebug v2.0.0beta5, Copyright (c) 2002, 2003, 2004, 2005, by
> Derick Rethans
> >
> >
> > Is this the error in FAQ?
> >
> >
> >
> You can load eAccelerator in the cgi/cli version, hence the line in the
> output. But eAccelerator will never initialize it's cache. eAccelerator
> needs a process that keeps running and all other php processes that need
> to access the cache have to be forked from the main process. Only
> mod_php and php-fastcgi can offer that.
>
> gr,
>
> Bart
>
> --
> Bart Vanbrabant <bar...@zo...>
> PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1
>
>
>
>
>


--
Take care,
Steve
~~~~~~~
"I try to think, but nothing happens!" -- Curly
The Three Stooges

Re: [eAccelerator-developers] http://eaccelerator.net/wiki/Faq

[Bart V. <bar...@zo...>]

Vyacheslav Chernousov wrote:
> Hi all.
>
> I see new page in wiki - http://eaccelerator.net/wiki/Faq
>
> Latest question is about EA working with php-cgi or php-cli. And I was
> wondered  with  answer:  "This  is  not  yet supported and it won't be
> supported in the near future."
>
> I'm using php-cgi and php-cli (5.1.2) with latest EA from SVN and
> it works good for me. At least I see compiled scripts in
> eaccelerator.cache_dir and also:
>
> ~ # php -v
> PHP 5.1.2-gentoo (cli) (built: Mar 16 2006 12:54:26)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>     with eAccelerator v0.9.5-dev, Copyright (c) 2004-2006 eAccelerator,=
 by eAccelerator
>     with Xdebug v2.0.0beta5, Copyright (c) 2002, 2003, 2004, 2005, by D=
erick Rethans
>
>
> ~ # php-cgi -v
> PHP 5.1.2-gentoo (cgi-fcgi) (built: Mar 16 2006 13:06:55)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>     with eAccelerator v0.9.5-dev, Copyright (c) 2004-2006 eAccelerator,=
 by eAccelerator
>     with Xdebug v2.0.0beta5, Copyright (c) 2002, 2003, 2004, 2005, by D=
erick Rethans
>
>
> Is this the error in FAQ?
>    =20
>
>  =20
You can load eAccelerator in the cgi/cli version, hence the line in the
output. But eAccelerator will never initialize it's cache. eAccelerator
needs a process that keeps running and all other php processes that need
to access the cache have to be forked from the main process. Only
mod_php and php-fastcgi can offer that.

gr,

Bart

--=20
Bart Vanbrabant <bar...@zo...>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1

[eAccelerator-developers] http://eaccelerator.net/wiki/Faq

[Vyacheslav C. <ma...@ch...>]

Hi all.

I see new page in wiki - http://eaccelerator.net/wiki/Faq

Latest question is about EA working with php-cgi or php-cli. And I was
wondered  with  answer:  "This  is  not  yet supported and it won't be
supported in the near future."

I'm using php-cgi and php-cli (5.1.2) with latest EA from SVN and
it works good for me. At least I see compiled scripts in
eaccelerator.cache_dir and also:

~ # php -v
PHP 5.1.2-gentoo (cli) (built: Mar 16 2006 12:54:26)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with eAccelerator v0.9.5-dev, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
    with Xdebug v2.0.0beta5, Copyright (c) 2002, 2003, 2004, 2005, by Derick Rethans


~ # php-cgi -v
PHP 5.1.2-gentoo (cgi-fcgi) (built: Mar 16 2006 13:06:55)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with eAccelerator v0.9.5-dev, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
    with Xdebug v2.0.0beta5, Copyright (c) 2002, 2003, 2004, 2005, by Derick Rethans


Is this the error in FAQ?
    

-- 
Vyacheslav Chernousov
E-mail/MSN: ma...@ch...
ICQ: 37687443
AIM: chernousovdotcom

[eAccelerator-developers] http://eaccelerator.net/wiki/Faq

[Vyacheslav C. <ma...@ch...>]

Hi all.

I see new page in wiki - http://eaccelerator.net/wiki/Faq

Latest question is about EA working with php-cgi or php-cli. And I was
wondered  with  answer:  "This  is  not  yet supported and it won't be
supported in the near future."

I'm using php-cgi and php-cli (5.1.2) with latest EA from SVN and
it works good for me. At least I see compiled scripts in
eaccelerator.cache_dir and also:

~ # php -v
PHP 5.1.2-gentoo (cli) (built: Mar 16 2006 12:54:26)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with eAccelerator v0.9.5-dev, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
    with Xdebug v2.0.0beta5, Copyright (c) 2002, 2003, 2004, 2005, by Derick Rethans


~ # php-cgi -v
PHP 5.1.2-gentoo (cgi-fcgi) (built: Mar 16 2006 13:06:55)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with eAccelerator v0.9.5-dev, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
    with Xdebug v2.0.0beta5, Copyright (c) 2002, 2003, 2004, 2005, by Derick Rethans


Is this the error in FAQ?
    

-- 
Vyacheslav Chernousov
E-mail/MSN: ma...@ch...
ICQ: 37687443
AIM: chernousovdotcom

[eAccelerator-developers] Solaris 10 x86

[Joseph B. <jo...@th...>]

Hello,

 

When compiling on Solaris 10, using Sun Studio 11, I get the error message
below:

 

/opt/SUNWspro/bin/ld -G -h eaccelerator.so -o .libs/eaccelerator.so
eaccelerator.lo optimize.lo encoder.lo loader.lo opcodes.lo content.lo mm.lo
webui.lo session.lo shm.lo debug.lo cache.lo ea_restore.lo ea_store.lo  -lc

ld: fatal: symbol `_fini' is multiply-defined:

        (file /opt/SUNWspro/prod/lib/crti.o type=FUNC; file eaccelerator.lo
type=FUNC);

ld: fatal: File processing errors. No output written to
.libs/eaccelerator.so

gmake: *** [eaccelerator.la] Error 1

 

 

I solved it by declaring _fini in eaccelerator.c as static.  Then it linked.
Not sure if that's the proper answer, but it does seem to work.

 

-Joseph Benden

 

 

[eAccelerator-developers] yay! eA-svn & control panel up-n-running on OSX

[OpenMacNews <ope...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

with:

	eA-svn (r187)

modified w/:

% perl -pi -e 's/isAdminAllowed\(\)\)/isAdminAllowed\(TSRMLS_C\)\)/g'
ea_info.c

per:

	http://eaccelerator.net/ticket/24

	OSX 10.4.5
	Apache 22x HEAD (worker mpm)
	PHP 5.1.2 (threaded)

eA, for the 1st time (for me ...) builds w/o error, and control panel
works. :-D

take a look:

	http://tinyurl.com/o46mc

cool!

richard

- --

/"\
\ /  ASCII Ribbon Campaign
 X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iEYEAREDAAYFAkQfmisACgkQlffdvTZxCMYgyACgx17scSA9ZVK4leQqXyOBa6DA
0cYAn3ECsMcVSkc2SU6/eqQlib1hdVGT
=6SuV
-----END PGP SIGNATURE-----

Re: [eAccelerator-developers] low frequency segfault on AMD64

[Oliver S. <ol...@re...>]

OK. 5 days later and we are a lot closer to being able to narrow this down.

Firstly we now have both the 32bit and 64bit servers running without 
segfaults.

Note again our environment:

 >> FreeBSD 5.3-RELEASE FreeBSD 5.3-RELEASE #4:
 >> Fri May  6 14:07:48 BST 2005 amd64
 >>
 >> Apache/2.0.55 (FreeBSD)
 >>
 >> eA installed from the current 0.9.4rc_1 ports with a tweaked Makefile
 >> (version number and MD5 changed, and all patches removed).
 >>
 >> PHP 5.1.2 (cli) (built: Mar  8 2006 00:09:12)
 >> Copyright (c) 1997-2006 The PHP Group
 >> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
 >>     with eAccelerator v0.9.5-beta1, Copyright (c) 2004-2005

Here is what we did to achieve that:

- In FreeBSD you need to set both kern.ipc.shmall and kern.ipc.shmmax 
with kern.ipc.shmall = kern.ipc.shmmax / PageSize

(you can see the page size as the last figure in the output below, it is 
1024 for 32bit machines and 2048 64bit machines).

for a 32bit machine the settings for 256MB of shared mem look like this:

root@piha# sysctl -a | egrep 'shm|Type'
kern.ipc.shmmax: 268435456
kern.ipc.shmmin: 1
kern.ipc.shmmni: 192
kern.ipc.shmseg: 128
kern.ipc.shmall: 262144
kern.ipc.shm_use_phys: 0
kern.ipc.shm_allow_removed: 0
         Type  InUse MemUse HighUse Requests  Size(s)
           shm    38    49K    165K  5083325  1024


The above setting will allow you to run 128MB of eA shared mem:
eaccelerator.shm_size="128"

AND still be able to

apachectl graceful

without crashing apache (ie you need 2x the shm for graceful). If you 
have less shm configured in kernel or have the kern.ipc.shmall 
configured wrong apache will fail to restart, because eA cannot allocate 
the shm it needs.


HOWEVER!!

*** if we use graceful will get these low freqency segfaults ***

also if we use

apachectl restart

we still get the segfaults!!

the only reliable way we have been able to restart apache without 
getting segfaults is with this script:

<script>
#!/usr/local/bin/bash
# restart apache slowly while cleaning eaccelerator cache

/usr/local/etc/rc.d/apache2.sh stop
find /tmp/eaccelerator -type f -exec rm {} \;
/usr/local/etc/rc.d/apache2.sh start
</script>

if we use that script...we get ZERO segfaults! 100% reliability...which 
is much better than anything we have ever had with eA0.9.x.

BUT if we use any other restart method...we get the low freq segfaults 
coming in within a few minutes of the (graceful or not) restart.

Now I am hoping that this information will help people who are:
a) getting low freq segfaults
b) operating 64bit machines (although we actually get the same symptoms 
on both 32bit and 64bit so the arch issue might be a red herring)
c) are using FreeBSD
d) have highly loaded production servers

I am also hoping that this may trigger a discussion/further tests 
together with the eA dev team to figure out why we can't use

apachectl graceful
apachectl restart
/usr/local/etc/rc.d/apache2.sh restart

all of which would be better ways of restarting.

One final point, which I think is also a red herring is that we are now 
running SO MUCH shm on these machines the eA never runs out (the most it 
reaches is about 60% full). We don't think this is related to the 
segfaults because we were getting them both on machines with tons of shm 
and ones which were "swapping").


Hope this is useful and look forward to feedback...

Oliver

Re: [eAccelerator-developers] eAccelerator scales towards useless

[dormando <dor...@ry...>]

> I think he likes eAccelerator and he has found a problem and he wants to
> invest time in finding the problem and helping resolve it.
> Personally I like that more then people donating money to eA, I'm not
> going to work more on eA when the project gets more money so eA won't
> improve. Donations are nice, but help into making eA a better product is
> even nicer. When people help finding bugs, eA will improve!
> 
> cheers,
> 
> Bart
> 

^^^ This is the part that makes sense. I want to make eA better, not 
just for me, but for everyone who uses it. Then money we save on servers 
will help hire people (helping people get jobs) and make our users 
happy. I don't see any of that either, and never will. The point is; do 
things -> improve eA -> do other things -> happier users on a faster 
site. Part of the process.

Bart, I'm still working on a reproducable test case... I'm going to 
draft one of the PHP programmers to give me a hand later this week if I 
can't figure it out myself. If you can figure it out sooner, though... ;)

-Dormando

Re: [eAccelerator-developers] low frequency segfault on AMD64

[Ramon v. A. <ra...@hy...>]

I'm opening a new thread for this to prevent thread-hijjacking, quoting 
original message in full.

Oliver Schonrock wrote:

> We have installed 0.9.5-beta1 on an AMD64 production machine.
>
> This machine is quite busy and runs with 128MB of eA cache.
>
> FreeBSD 5.3-RELEASE FreeBSD 5.3-RELEASE #4:
> Fri May  6 14:07:48 BST 2005 amd64
>
> Apache/2.0.55 (FreeBSD)
>
> eA installed from the current 0.9.4rc_1 ports with a tweaked Makefile 
> (version number and MD5 changed, and all patches removed).
>
> PHP 5.1.2 (cli) (built: Mar  8 2006 00:09:12)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>     with eAccelerator v0.9.5-beta1, Copyright (c) 2004-2005 
> eAccelerator, by eAccelerator
>
> we are getting about 30 of these per day:
>
> [Thu Mar 09 17:24:01 2006] [notice] child pid 19220 exit signal 
> Segmentation fault (11)

We're getting them on both our AMD64's and our Intel-Xeon's (32bit).
Roughly 30-40 a day. Haven't tried 0.9.5_beta1 on our 32bit hosts though.

> The exact same configuration is running on a 32bit Athlon production 
> machine with no segfaults.
>
> I know this is not very helpful, because I haven't provided a trace, 
> but I don't have a way of doing that on this production machine. We 
> haven't been able to track down the script that causes the segfault 
> either, as far as we can tell it seems "random".
>
> We would like to help track this down. Are there any known issues on 
> 64bit in 0.9.5-beta1?
>
> Could this be one of those famous "concurrency isssues"?

AFAIK there's an outstanding bug that eaccelerator causes apache to 
segfault with signal 11 under load.

>
> Are there any tips anyone has on how we can narrow down the 
> problem/provide a trace given this is a production environment (we 
> don't have a 64bit dev machine)?

Any tips on producing a helpful trace to debug this would be useful, I 
can setup a host in both environments (32/64 bit) for tracing if 
neccesary. For the time being those would be on php-4.3.11 though.
We're working on an upgrade to php5.

Regards,

Ramon

-- 
mail:    ra...@hy...
gsm:     +31 (0) 6 48261300
msn:     rja...@ho...
www:     http://ramon71.hyves.nl

-- 
mail:    ra...@hy...
gsm:     +31 (0) 6 48261300
msn:     rja...@ho...
www:     http://ramon71.hyves.nl

[eAccelerator-developers] low frequency segfault on AMD64

[Oliver S. <oli...@re...>]

Hi

We have installed 0.9.5-beta1 on an AMD64 production machine.

This machine is quite busy and runs with 128MB of eA cache.

FreeBSD 5.3-RELEASE FreeBSD 5.3-RELEASE #4:
Fri May  6 14:07:48 BST 2005 amd64

Apache/2.0.55 (FreeBSD)

eA installed from the current 0.9.4rc_1 ports with a tweaked Makefile 
(version number and MD5 changed, and all patches removed).

PHP 5.1.2 (cli) (built: Mar  8 2006 00:09:12)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
     with eAccelerator v0.9.5-beta1, Copyright (c) 2004-2005 
eAccelerator, by eAccelerator

we are getting about 30 of these per day:

[Thu Mar 09 17:24:01 2006] [notice] child pid 19220 exit signal 
Segmentation fault (11)

The exact same configuration is running on a 32bit Athlon production 
machine with no segfaults.

I know this is not very helpful, because I haven't provided a trace, but 
I don't have a way of doing that on this production machine. We haven't 
been able to track down the script that causes the segfault either, as 
far as we can tell it seems "random".

We would like to help track this down. Are there any known issues on 
64bit in 0.9.5-beta1?

Could this be one of those famous "concurrency isssues"?

Are there any tips anyone has on how we can narrow down the 
problem/provide a trace given this is a production environment (we don't 
have a 64bit dev machine)?

Cheers

Oliver

Re: [eAccelerator-developers] eAccelerator scales towards useless

[Bart V. <bar...@zo...>]

Alexander Schories wrote:
> Hello,
>
>  =20
>> we have
>> hundreds of servers,
>>    =20
>
> Ahem.. ;)
>
> Btw: What makes you think, that it is important for people around eA ho=
w
> many servers are run by you or your company?
>
> Please understand this is just about "we have zillion servers.."-statem=
ent.
>  =20
What does that matter?
>  =20
>> every percentage point I can push in speed saves us
>> thousands of dollars.
>>    =20
>
> Fine. This is logical then.
>
> However, please allow just another question: Do you plan to donate some=
 of
> the saved dollars to the project - or you just demanding free services =
for
> your enterprise?
>
> In the end: If eA is so unsatisfying for you - why don`t you invest som=
e
> thousand dollars into Zend`s fairy lights boxed products and tell us th=
e
> results. :)
>
>  =20
I think he likes eAccelerator and he has found a problem and he wants to
invest time in finding the problem and helping resolve it.
Personally I like that more then people donating money to eA, I'm not
going to work more on eA when the project gets more money so eA won't
improve. Donations are nice, but help into making eA a better product is
even nicer. When people help finding bugs, eA will improve!

cheers,

Bart

--=20
Bart Vanbrabant <bar...@zo...>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1

Re: [eAccelerator-developers] eAccelerator scales towards useless

[Niek v. d. M. <nie...@gm...>]

Francisco, can you post your my.cnf file on this list? The SQL server is
usually the big bottlenock, and I guess more readers are interested in
tuning their configs.

Dormando, have you tried switching to Lighttpd? Many high-traffic sites
(Wikipedia, Youtube, Lyxos, various BT sites) are using Lighttpd instead of
Apache.

- Niek


On 3/9/06, megaciudad megaciudad <meg...@gm...> wrote:
>
> Estimate Dormando:
>
> We have three cpanel servers with a mixture of xNukes, oscommerces,
> pure perl and pure html sites, and we have noticed:
>
> - Tunning /etc/my.cnf have make the server really lighting: about 200
> to 1000% of performance and cpu lower.
> - Installing eA over Zend (caching & optimize enabled) has lower the
> cpu usage about 20 to 50%. The best of all, in a server with a backup
> drive that we're setup the temp dir for eA in the second drive, only
> used at 4'00 hours by the backup scripts.
>
> Installing eA or Zend *without* optimize my.cnf has make more cpu
> over-usage and the system starts to use usually swap space, with a big
> performance degradation.
>
> If you want I can send you by mail our 512 Mb and 1.024 Mb RAM mysql
> configuration files. We have adjust it and Apache to use exactly the
> 50% of the ram. I have tested it for years, and I have many months of
> mrtg graphics that certified it.
>
> Greetings from Spain.
>
> Francisco Segura
> Megaciudad Hosting.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> eAccelerator-developers mailing list
> eAc...@li...
> https://lists.sourceforge.net/lists/listinfo/eaccelerator-developers
>

Re: [eAccelerator-developers] eAccelerator scales towards useless

[Alexander S. <ale...@sc...>]

Hello,

> we have
> hundreds of servers,

Ahem.. ;)

Btw: What makes you think, that it is important for people around eA how
many servers are run by you or your company?

Please understand this is just about "we have zillion servers.."-statemen=
t.

> every percentage point I can push in speed saves us
> thousands of dollars.

Fine. This is logical then.

However, please allow just another question: Do you plan to donate some o=
f
the saved dollars to the project - or you just demanding free services fo=
r
your enterprise?

In the end: If eA is so unsatisfying for you - why don`t you invest some
thousand dollars into Zend`s fairy lights boxed products and tell us the
results. :)


Kind Regards

Alexander Schories
Tuebingen, Germany

Re: [eAccelerator-developers] eAccelerator scales towards useless

[dormando <dor...@ry...>]

Hey,

I'm appreciative of your optimization pointers, but this isn't really 
about that.

Our architecture is *very* highly tuned. Our databases are near idle all 
day, and our webservers and network are very highly tuned top to bottom. 
Our load balancing architecture is modeled after the best, and this 
latest inquiry is in my interest of further pushing the limits; we have 
hundreds of servers, every percentage point I can push in speed saves us 
thousands of dollars.

In this particular case, eA is doing something that should very well be 
fixable, so I am hoping that it is.

As my original e-mail already states, in pages that are almost pure-CPU 
loads we have a 75% performance gain by using eA. After the cache is 
loaded, that performance gain drops to 60% for the *same page loads*. As 
we add more pages and more data to cache, I expect that initial 
performance increase to drop further.

I know everyone wants to insist that my configuration is bumpkus, but 
that's why I spent four hours running tests all over eA's configuration. 
I was also very careful to state most of the setup in the original 
e-mail. To those who insist on "stick with the defaults" - I would, but 
those were even slower. Also, *please* understand that this was as far 
from a synthetic test as I could make it. I'm testing our real code, 
doing many, many iterations through real pageviews; not trying to 
include as many files as possible and timing it.

have fun,
-Dormando

megaciudad megaciudad wrote:
> Estimate Dormando:
> 
> We have three cpanel servers with a mixture of xNukes, oscommerces,
> pure perl and pure html sites, and we have noticed:

[...]

Re: [eAccelerator-developers] eAccelerator scales towards useless

[megaciudad m. <meg...@gm...>]

Estimate Dormando:

We have three cpanel servers with a mixture of xNukes, oscommerces,
pure perl and pure html sites, and we have noticed:

- Tunning /etc/my.cnf have make the server really lighting: about 200
to 1000% of performance and cpu lower.
- Installing eA over Zend (caching & optimize enabled) has lower the
cpu usage about 20 to 50%. The best of all, in a server with a backup
drive that we're setup the temp dir for eA in the second drive, only
used at 4'00 hours by the backup scripts.

Installing eA or Zend *without* optimize my.cnf has make more cpu
over-usage and the system starts to use usually swap space, with a big
performance degradation.

If you want I can send you by mail our 512 Mb and 1.024 Mb RAM mysql
configuration files. We have adjust it and Apache to use exactly the
50% of the ram. I have tested it for years, and I have many months of
mrtg graphics that certified it.

Greetings from Spain.

Francisco Segura
Megaciudad Hosting.

Re: [eAccelerator-developers] eAccelerator scales towards useless

[dormando <dor...@ry...>]

Bart Vanbrabant wrote:
> dormando wrote:
>   
>> Hey,
>>
>> We recently moved our site from eA 0.9.3 to 0.9.5-beta1 while
>> upgrading from PHP 4.4.2 to 5.1.2.
>>
>> We discovered a pretty big dropoff in site speed after doing this.
>> Sadly I *cannot* verify if the same performance drop exists in our
>> PHP4 setup. What was most concerning is that our site speed dropped to
>> complete crap after I upped the shared memory segment size to 64
>> megabytes. Dropping it back down to 32 megabytes made the site usable
>> again.
>>
>> We start up PHP across the cluster with a fresh start, and the site is
>> blazing fast. After a few minutes things start slowing down pretty
>> badly. If we load up the eaccelerator() page and nail the "Clean"
>> button, or restart apache across the cluster, the site speeds up again.
>>
>> I wasted a few hours last week running a large array of tests to
>> narrow down what this could be. Here's the dump of information to get
>> past the usual level of "user is probably an idiot" questions;
>>
>> - The server has no harddrive, the code is loaded out of a ramdisk.
>> There is also ~800 megabytes of *unallocated system memory* before and
>> after all of these tests. There are no messages in dmesg about running
>> low or out of memory.
>> - The eaccelerator configuration is set to not use disk caching
>> - Optimize, check_mtime, enable, etc are set. compression is not set.
>> pruning is not set up during the tests.
>> - Apache was *clean restarted* between tests. eaccelerator() was used
>> to verify a clean start between *every single test*
>> - The tests encompass hitting five different pages from our site code,
>> each vary between the amount of CPU required vs DB queries. The
>> numbers I looked at most critically are the CPU-only page loads.
>> DB-heavy pages were used as a baseline, only.
>> - The box was fresh booted for the start of the test runs.
>> - There are *no files* being generated in /tmp/eaccelerator/ - I can
>> make them show up if I tell eA to, but during the tests none were
>> created. /tmp is also hosted in a tmpfs filesystem.
>> - Again, all the code is hosted out of a tmpfs file system. We are not
>> running out of system memory.
>> - The production tests with memory being filled up was *not* running
>> the shm segment completely out, there was enough memory free to cache
>> the benchmarked pages.
>> - The OS is debian Linux, running kernel 2.6.15 with some minor tuning.
>>
>> I took a number of tests (I won't bother pasting all the output unless
>> necessary). I tested various values of shared memory segment size in
>> various states. Five pages were tested, each hit 2000 times per test
>> at a concurrency level of 9 via apachebench. Each page test was done
>> immediately after the other. Apache was restarted between tests.
>>
>> 32 megabytes of shm with nothing cached before test (used as baseline).
>> 32 megabytes of shm after being ran in production for 20 minutes (most
>> memory used), 15% performance drop from baseline.
>> 32 megabytes of shm in the same conditions with and without the
>> optimize flag enabled (dropping optimize loses 2% performance on top
>> of the other results).
>> After talking with growler_ on IRC, I tried upping the hash buckets
>> from 256 to 4096, since there were ~1400-1600 files in the cache.
>> That made no difference in the tests....
>> I also tested 64 megabytes of shm in the above conditions, and had an
>> 18%+ performance drop as more files were cached.
>> Tried 8 megabytes of shm and the performance drop was much lower.
>> Tried 32 megabytes with half of the memory used and the drop was much
>> lower.
>> Compared to not running eA at all, we get a 75% speed boost from no eA
>> at all to the 32 meg nothing cached baseline test. After one speed
>> drop that's down to 60%, and with 64 megabytes of shared memory that
>> value drops more.
>>
>> It looks to me like it's tied, not to the amount of memory used, nor
>> the amount of memory free, but the number of files in the cache. As
>> the number of files in the cache passes 1500, the performance starts
>> rapidly dropping down. Removing a lot of *small* files from cache has
>> a pretty dramatic change in results.
>>
>> Is there anything at all that can be done about this? I'm going to
>> have nearly 300 webservers soon all running eA, and a 15%+ performance
>> drop is like losing 30 entire webservers. I'm willing to spend some
>> more time on this, but the eA code is tough to work with, so I
>> probably won't be doing any patches on my own. This is also especially
>> painful, since we're writing a lot more code for the site, and so we
>> need eA to scale up the number of files it can cache. I have plenty of
>> RAM to do it with, but eA needs to be able to support this. APC isn't
>> even an option since it segfaults all over our code.
>>
>> I've already adjusted our eA configuration so that it caches fewer
>> files, and the performance seems to have regained noticably. This
>> won't last long though as folks add more code to be cached.
>>
>> Thanks,
>> -Dormando
>>
>>     
> Can you verify if your apache processes don't segfault? It could be that
> with eAccelerator after some time apache starts segfaulting. There have
> been reports of that under high load on smp-systems.
>
> cheers,
>
> Bart
>
>
>   
I just double checked and verified that the apache processes are *not* 
segfaulting during the test. They were segfaulting during our APC tests, 
but not during eA.

I also ran the same test several times in a row, and as long as the 
parameters are the same, the results are the same. (so apache is not 
slowing down over time)

-Dormando

Re: [eAccelerator-developers] eAccelerator scales towards useless

[Bart V. <bar...@zo...>]

dormando wrote:
> Hey,
>
> We recently moved our site from eA 0.9.3 to 0.9.5-beta1 while
> upgrading from PHP 4.4.2 to 5.1.2.
>
> We discovered a pretty big dropoff in site speed after doing this.
> Sadly I *cannot* verify if the same performance drop exists in our
> PHP4 setup. What was most concerning is that our site speed dropped to
> complete crap after I upped the shared memory segment size to 64
> megabytes. Dropping it back down to 32 megabytes made the site usable
> again.
>
> We start up PHP across the cluster with a fresh start, and the site is
> blazing fast. After a few minutes things start slowing down pretty
> badly. If we load up the eaccelerator() page and nail the "Clean"
> button, or restart apache across the cluster, the site speeds up again.=

>
> I wasted a few hours last week running a large array of tests to
> narrow down what this could be. Here's the dump of information to get
> past the usual level of "user is probably an idiot" questions;
>
> - The server has no harddrive, the code is loaded out of a ramdisk.
> There is also ~800 megabytes of *unallocated system memory* before and
> after all of these tests. There are no messages in dmesg about running
> low or out of memory.
> - The eaccelerator configuration is set to not use disk caching
> - Optimize, check_mtime, enable, etc are set. compression is not set.
> pruning is not set up during the tests.
> - Apache was *clean restarted* between tests. eaccelerator() was used
> to verify a clean start between *every single test*
> - The tests encompass hitting five different pages from our site code,
> each vary between the amount of CPU required vs DB queries. The
> numbers I looked at most critically are the CPU-only page loads.
> DB-heavy pages were used as a baseline, only.
> - The box was fresh booted for the start of the test runs.
> - There are *no files* being generated in /tmp/eaccelerator/ - I can
> make them show up if I tell eA to, but during the tests none were
> created. /tmp is also hosted in a tmpfs filesystem.
> - Again, all the code is hosted out of a tmpfs file system. We are not
> running out of system memory.
> - The production tests with memory being filled up was *not* running
> the shm segment completely out, there was enough memory free to cache
> the benchmarked pages.
> - The OS is debian Linux, running kernel 2.6.15 with some minor tuning.=

>
> I took a number of tests (I won't bother pasting all the output unless
> necessary). I tested various values of shared memory segment size in
> various states. Five pages were tested, each hit 2000 times per test
> at a concurrency level of 9 via apachebench. Each page test was done
> immediately after the other. Apache was restarted between tests.
>
> 32 megabytes of shm with nothing cached before test (used as baseline).=

> 32 megabytes of shm after being ran in production for 20 minutes (most
> memory used), 15% performance drop from baseline.
> 32 megabytes of shm in the same conditions with and without the
> optimize flag enabled (dropping optimize loses 2% performance on top
> of the other results).
> After talking with growler_ on IRC, I tried upping the hash buckets
> from 256 to 4096, since there were ~1400-1600 files in the cache.
> That made no difference in the tests....
> I also tested 64 megabytes of shm in the above conditions, and had an
> 18%+ performance drop as more files were cached.
> Tried 8 megabytes of shm and the performance drop was much lower.
> Tried 32 megabytes with half of the memory used and the drop was much
> lower.
> Compared to not running eA at all, we get a 75% speed boost from no eA
> at all to the 32 meg nothing cached baseline test. After one speed
> drop that's down to 60%, and with 64 megabytes of shared memory that
> value drops more.
>
> It looks to me like it's tied, not to the amount of memory used, nor
> the amount of memory free, but the number of files in the cache. As
> the number of files in the cache passes 1500, the performance starts
> rapidly dropping down. Removing a lot of *small* files from cache has
> a pretty dramatic change in results.
>
> Is there anything at all that can be done about this? I'm going to
> have nearly 300 webservers soon all running eA, and a 15%+ performance
> drop is like losing 30 entire webservers. I'm willing to spend some
> more time on this, but the eA code is tough to work with, so I
> probably won't be doing any patches on my own. This is also especially
> painful, since we're writing a lot more code for the site, and so we
> need eA to scale up the number of files it can cache. I have plenty of
> RAM to do it with, but eA needs to be able to support this. APC isn't
> even an option since it segfaults all over our code.
>
> I've already adjusted our eA configuration so that it caches fewer
> files, and the performance seems to have regained noticably. This
> won't last long though as folks add more code to be cached.
>
> Thanks,
> -Dormando
>
Can you verify if your apache processes don't segfault? It could be that
with eAccelerator after some time apache starts segfaulting. There have
been reports of that under high load on smp-systems.

cheers,

Bart


--=20
Bart Vanbrabant <bar...@zo...>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1

[eAccelerator-developers] eAccelerator scales towards useless

[dormando <dor...@ry...>]

Hey,

We recently moved our site from eA 0.9.3 to 0.9.5-beta1 while upgrading 
from PHP 4.4.2 to 5.1.2.

We discovered a pretty big dropoff in site speed after doing this. Sadly 
I *cannot* verify if the same performance drop exists in our PHP4 setup. 
What was most concerning is that our site speed dropped to complete crap 
after I upped the shared memory segment size to 64 megabytes. Dropping 
it back down to 32 megabytes made the site usable again.

We start up PHP across the cluster with a fresh start, and the site is 
blazing fast. After a few minutes things start slowing down pretty 
badly. If we load up the eaccelerator() page and nail the "Clean" 
button, or restart apache across the cluster, the site speeds up again.

I wasted a few hours last week running a large array of tests to narrow 
down what this could be. Here's the dump of information to get past the 
usual level of "user is probably an idiot" questions;

- The server has no harddrive, the code is loaded out of a ramdisk. 
There is also ~800 megabytes of *unallocated system memory* before and 
after all of these tests. There are no messages in dmesg about running 
low or out of memory.
- The eaccelerator configuration is set to not use disk caching
- Optimize, check_mtime, enable, etc are set. compression is not set. 
pruning is not set up during the tests.
- Apache was *clean restarted* between tests. eaccelerator() was used to 
verify a clean start between *every single test*
- The tests encompass hitting five different pages from our site code, 
each vary between the amount of CPU required vs DB queries. The numbers 
I looked at most critically are the CPU-only page loads. DB-heavy pages 
were used as a baseline, only.
- The box was fresh booted for the start of the test runs.
- There are *no files* being generated in /tmp/eaccelerator/ - I can 
make them show up if I tell eA to, but during the tests none were 
created. /tmp is also hosted in a tmpfs filesystem.
- Again, all the code is hosted out of a tmpfs file system. We are not 
running out of system memory.
- The production tests with memory being filled up was *not* running the 
shm segment completely out, there was enough memory free to cache the 
benchmarked pages.
- The OS is debian Linux, running kernel 2.6.15 with some minor tuning.

I took a number of tests (I won't bother pasting all the output unless 
necessary). I tested various values of shared memory segment size in 
various states. Five pages were tested, each hit 2000 times per test at 
a concurrency level of 9 via apachebench. Each page test was done 
immediately after the other. Apache was restarted between tests.

32 megabytes of shm with nothing cached before test (used as baseline).
32 megabytes of shm after being ran in production for 20 minutes (most 
memory used), 15% performance drop from baseline.
32 megabytes of shm in the same conditions with and without the optimize 
flag enabled (dropping optimize loses 2% performance on top of the other 
results).
After talking with growler_ on IRC, I tried upping the hash buckets from 
256 to 4096, since there were ~1400-1600 files in the cache.
That made no difference in the tests....
I also tested 64 megabytes of shm in the above conditions, and had an 
18%+ performance drop as more files were cached.
Tried 8 megabytes of shm and the performance drop was much lower.
Tried 32 megabytes with half of the memory used and the drop was much lower.
Compared to not running eA at all, we get a 75% speed boost from no eA 
at all to the 32 meg nothing cached baseline test. After one speed drop 
that's down to 60%, and with 64 megabytes of shared memory that value 
drops more.

It looks to me like it's tied, not to the amount of memory used, nor the 
amount of memory free, but the number of files in the cache. As the 
number of files in the cache passes 1500, the performance starts rapidly 
dropping down. Removing a lot of *small* files from cache has a pretty 
dramatic change in results.

Is there anything at all that can be done about this? I'm going to have 
nearly 300 webservers soon all running eA, and a 15%+ performance drop 
is like losing 30 entire webservers. I'm willing to spend some more time 
on this, but the eA code is tough to work with, so I probably won't be 
doing any patches on my own. This is also especially painful, since 
we're writing a lot more code for the site, and so we need eA to scale 
up the number of files it can cache. I have plenty of RAM to do it with, 
but eA needs to be able to support this. APC isn't even an option since 
it segfaults all over our code.

I've already adjusted our eA configuration so that it caches fewer 
files, and the performance seems to have regained noticably. This won't 
last long though as folks add more code to be cached.

Thanks,
-Dormando

Re: [eAccelerator-developers] I can't change shm_size value

[Alexander S. <ale...@sc...>]

Hi,

> Solved, exactly as you wrote  ;)
>
> Tnx, Alexander.


Great!

Thank you for the kind feedback! :)


Kind Regards

Alexander Schories
Tuebingen, Germany

Re: [eAccelerator-developers] I can't change shm_size value

[Matt <dat...@gm...>]

For anyone experiencing this problem on a FreeBSD-based system, I have
a brief write-up on how to solve it at:

http://www.datahead.org/wiki/index.php/FreeBSD_System_Settings#Shared_Memor=
y_Settings

I mention this only because FreeBSD requires an additional setting to
be changed.  I <snipped> this info from an NIH site located here:

http://afni.nimh.nih.gov/afni/doc/misc/3dDeconvolveOnFreeBSD

Regards,
Matt

On 3/8/06, megaciudad megaciudad <meg...@gm...> wrote:
> Solved, exactly as you wrote  ;)
>
> Tnx, Alexander.
>
>
> > You told us that your system has 1gb of ram. To enable a maximum (of 1g=
b)
> > of SHM for all your applications that will use SHM, please enter this o=
n
> > your console:
> >
> > echo 1073741824 > /proc/sys/kernel/shmmax
> >
> > Attention - the above setting will be LOST after/on every reboot!
> >
> > To have this setting as a default, please edit your /etc/sysctl.conf li=
ke
> > this:
> >
> > kernel.shmmax =3D 1073741824
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> eAccelerator-developers mailing list
> eAc...@li...
> https://lists.sourceforge.net/lists/listinfo/eaccelerator-developers
>

Re: [eAccelerator-developers] I can't change shm_size value

[megaciudad m. <meg...@gm...>]

Solved, exactly as you wrote  ;)

Tnx, Alexander.


> You told us that your system has 1gb of ram. To enable a maximum (of 1gb)
> of SHM for all your applications that will use SHM, please enter this on
> your console:
>
> echo 1073741824 > /proc/sys/kernel/shmmax
>
> Attention - the above setting will be LOST after/on every reboot!
>
> To have this setting as a default, please edit your /etc/sysctl.conf like
> this:
>
> kernel.shmmax =3D 1073741824

Re: [eAccelerator-developers] I can't change shm_size value

[Alexander S. <ale...@sc...>]

Hi,


you probably have to set your systems default shm size (which is limited
by default on most systems to 16mb or 32mb) to a higher value.
Eaccelerator can only use/aquire SHM in the size the system - to be more
precise the kernel - is currently configured to. Maybe your apache or
system logs will show some line about this ("not enough shm cache" or
similar)..


You told us that your system has 1gb of ram. To enable a maximum (of 1gb)
of SHM for all your applications that will use SHM, please enter this on
your console:

echo 1073741824 > /proc/sys/kernel/shmmax


Attention - the above setting will be LOST after/on every reboot!

To have this setting as a default, please edit your /etc/sysctl.conf like
this:

kernel.shmmax =3D 1073741824



Kind Regards

Alexander Schories
Tuebingen, Germany

Re: [eAccelerator-developers] I can't change shm_size value

[Alexander S. <ale...@sc...>]

Hi,


you probably have to set your systems default shm size (which is limited
by default on most systems to 16mb or 32mb) to a higher value.
Eaccelerator can only use/aquire SHM in the size the system - to be more
precise the kernel - is currently configured to. Maybe your apache or
system logs will show some line about this ("not enough shm cache" or
similar)..


You told us that your system has 1gb of ram. To enable a maximum (of 1gb)
of SHM for all your applications that will use SHM, please enter this on
your console:

echo 1073741824 > /proc/sys/kernel/shmmax


Attention - the above setting will be LOST after/on every reboot!

To have this setting as a default, please edit your /etc/sysctl.conf like
this:

kernel.shmmax =3D 1073741824



Kind Regards

Alexander Schories
Tuebingen, Germany