hi all:


We deploy single entry PHP program with php-fpm & nginx. We use a single
entry PHP with version file to switch product version.

Just like the following code:

<?php
>
> $version = file_get_contents('version');
>
> require_once "/home/www/release/$version/init.php";
>
> dispatch();
>

The problem is that when we deploy a new version, the php-fpm will
become slower after a while so that it cannot handle any request.

After I restart php-fpm, it works properly.

Any idea or suggestion will be appreciated.

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On 02/19/2014 02:07 PM, Zhiwen Sun wrote:
> The problem is that when we deploy a new version, the php-fpm will become slower after a while so that it cannot handle any request.

What kind of opcode cache are you using?
How did you configure it?
How much space does the new code version take?
What's the average request per second rate?
Can you see where PHP spends most of the time? (use http://poormansprofiler.org/ for example).

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks for your reply.

The space of code is about 40M.
The max request count is about 30/s .
I will try poormansprofiler later.

We use APC as opcode cache.
APC related configuration :

APC Support => enabled
Version => 3.1.9
APC Debugging => Disabled
MMAP Support => Enabled
MMAP File Mask => /dev/zero
Locking type => pthread mutex Locks
Serialization Support => php
Revision => $Revision: 308812 $
Build Date => Sep 12 2013 04:22:53

Directive => Local Value => Master Value
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => On => On
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => /dev/zero => /dev/zero
apc.num_files_hint => 5000 => 5000
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.serializer => default => default
apc.shm_segments => 1 => 1
apc.shm_size => 640M => 640M
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 60 => 60
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 60 => 60
apc.write_lock => On => On








On Wednesday, February 19, 2014 8:13:20 PM UTC+8, Antony Dovgal wrote:
>
> On 02/19/2014 02:07 PM, Zhiwen Sun wrote:
> > The problem is that when we deploy a new version, the php-fpm will
> become slower after a while so that it cannot handle any request.
>
> What kind of opcode cache are you using?
> How did you configure it?
> How much space does the new code version take?
> What's the average request per second rate?
> Can you see where PHP spends most of the time? (use
> http://poormansprofiler.org/ for example).
>
> --
> Wbr,
> Antony Dovgal
> ---
> http://pinba.org - realtime profiling for PHP
>

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On 02/20/2014 10:21 AM, Zhiwen Sun wrote:
> Thanks for your reply.
>
> The space of code is about 40M.
> The max request count is about 30/s .
> I will try poormansprofiler later.
>
> We use APC as opcode cache.
> APC related configuration :
>
> APC Support => enabled
> Version => 3.1.9
> APC Debugging => Disabled
> MMAP Support => Enabled
> MMAP File Mask => /dev/zero
> Locking type => pthread mutex Locks

I'd suggest using pthread rwlocks instead.
To do this recompile APC with --enable-apc-pthreadrwlocks flag.

But switching to the latest PHP version, which also includes Zend Opcache, is preferable.

> apc.shm_size => 640M => 640M

And how much of this segment is actually used?
You should be able to see it on phpinfo() page.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Do you mean https://github.com/zendtech/ZendOptimizerPlus ?

We have tried this PHP extension. It seems that it has gc problem after we
deployed several versions.

On Thursday, February 20, 2014 4:03:18 PM UTC+8, Antony Dovgal wrote:
>
> On 02/20/2014 10:21 AM, Zhiwen Sun wrote:
> > Thanks for your reply.
> >
> > The space of code is about 40M.
> > The max request count is about 30/s .
> > I will try poormansprofiler later.
> >
> > We use APC as opcode cache.
> > APC related configuration :
> >
> > APC Support => enabled
> > Version => 3.1.9
> > APC Debugging => Disabled
> > MMAP Support => Enabled
> > MMAP File Mask => /dev/zero
> > Locking type => pthread mutex Locks
>
> I'd suggest using pthread rwlocks instead.
> To do this recompile APC with --enable-apc-pthreadrwlocks flag.
>
> But switching to the latest PHP version, which also includes Zend Opcache,
> is preferable.
>
> > apc.shm_size => 640M => 640M
>
> And how much of this segment is actually used?
> You should be able to see it on phpinfo() page.
>
> --
> Wbr,
> Antony Dovgal
> ---
> http://pinba.org - realtime profiling for PHP
>

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On 02/20/2014 12:43 PM, Zhiwen Sun wrote:
> Do you mean https://github.com/zendtech/ZendOptimizerPlus ?

Yes, it's a part of standard distribution now:
http://git.php.net/?p=php-src.git;a=tree;f=ext/opcache;h=7ea4bdd921afd432493da9630f48eafc26a5e6bd;hb=HEAD

> We have tried this PHP extension. It seems that it has gc problem after we deployed several versions.

What kind of problem?
Do you have a reproduce case or some more info?

We've been using it for quite a while now on a lot of servers with some minor issues that have been quickly resolved.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

We have encountered the problem that opcache cannot remove cache of old
version code automatically so that new release code cannot be cached in
opcache.


On Thursday, February 20, 2014 4:56:47 PM UTC+8, Antony Dovgal wrote:
>
> On 02/20/2014 12:43 PM, Zhiwen Sun wrote:
> > Do you mean https://github.com/zendtech/ZendOptimizerPlus ?
>
> Yes, it's a part of standard distribution now:
>
> http://git.php.net/?p=php-src.git;a=tree;f=ext/opcache;h=7ea4bdd921afd432493da9630f48eafc26a5e6bd;hb=HEAD
>
> > We have tried this PHP extension. It seems that it has gc problem after
> we deployed several versions.
>
> What kind of problem?
> Do you have a reproduce case or some more info?
>
> We've been using it for quite a while now on a lot of servers with some
> minor issues that have been quickly resolved.
>
> --
> Wbr,
> Antony Dovgal
> ---
> http://pinba.org - realtime profiling for PHP
>

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On 02/20/2014 01:22 PM, Zhiwen Sun wrote:
> We have encountered the problem that opcache cannot remove cache of old version code automatically so that new release code cannot be cached in opcache.

Do you happen to use symlinks in the path to your code?

I've encountered and helped to fix a similar problem, but symlinks were required to reproduce it.
Here's the patch: http://git.php.net/?p=php-src.git;a=commitdiff;h=16e95d91378591042c1bf4bd40dead3ef9ae975a

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

We have not use symbol link in the path to our code.


On Thursday, February 20, 2014 8:00:25 PM UTC+8, Antony Dovgal wrote:
>
> On 02/20/2014 01:22 PM, Zhiwen Sun wrote:
> > We have encountered the problem that opcache cannot remove cache of old
> version code automatically so that new release code cannot be cached in
> opcache.
>
> Do you happen to use symlinks in the path to your code?
>
> I've encountered and helped to fix a similar problem, but symlinks were
> required to reproduce it.
> Here's the patch:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=16e95d91378591042c1bf4bd40dead3ef9ae975a
>
> --
> Wbr,
> Antony Dovgal
> ---
> http://pinba.org - realtime profiling for PHP
>

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On 02/21/2014 07:35 AM, Zhiwen Sun wrote:
> We have not use symbol link in the path to our code.

Then a reproduce case and/or more info is definitely needed.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks.

When we changed APC to rwlock, it worked properly until now.

On Friday, February 21, 2014 1:18:59 PM UTC+8, Antony Dovgal wrote:
>
> On 02/21/2014 07:35 AM, Zhiwen Sun wrote:
> > We have not use symbol link in the path to our code.
>
> Then a reproduce case and/or more info is definitely needed.
>
> --
> Wbr,
> Antony Dovgal
> ---
> http://pinba.org - realtime profiling for PHP
>

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.