php-fpm + apc(семафорная блокировка)
tantra
есть связка nginx + phpfmp(Байт код кешер apc). С некоторого момента
php стал регулярно сидеть в lockf состоянии (по top). Как возможное
решение мне предложили сменить тип блокировки используемый apc с
файловой на семафорную. И вроде бы чего сложного скомпилил apc с --
enable-apc-sem и всего делов, но не работает это с php-fpm. Когда
происходит попытка захватить семафор вылетает с ошибкой народе этой:
Fatal error: Unknown: apc_sem_lock: semop(655361) failed: 22 in
Unknown on line 0
Мы перепробовали кучу sysctl параметров, но ничего не помагает. Затем
решили посмотреть а существуют ли какие семафоры в системе
ipcs -s и опа пусто:
Semaphores:
T ID KEY MODE OWNER GROUP
Т.е при работающем php никаких семафоров нет, следовательно потому и
падает при попытке блокирования. Соответственно начали отлаживать уже
сам apc и обнаружили что PHP_MINIT_FUNCTION (функция инициализации
модуля) вызывается только один раз и то только в процессе который
видимо участвует в демонизации (потому как в конечном счете в списке
процессов его нет)
freebsd# ps -aux | grep 'php'
root 4023 0.0 1.4 46004 7076 ?? Ss 5:06AM 0:00.01 /usr/
local/bin/php-cgi --fpm --fpm-config /usr/local/etc/p
www 4024 0.0 1.4 46004 7096 ?? S 5:06AM 0:00.00 /usr/
local/bin/php-cgi --fpm --fpm-config /usr/local/etc/p
www 4025 0.0 1.4 46004 7096 ?? S 5:06AM 0:00.00 /usr/
local/bin/php-cgi --fpm --fpm-config /usr/local/etc/p
у процесс который вызвал PHP_MINIT_FUNCTION имеет идентификатор 4022.
Соответственно в этом же процессе вызывается PHP_MSHUTDOWN_FUNCTION(и
все семафроры прибиваються)
У меня собсвенно вопрос а разве php-fpm правильно поступает делая так?
Это очень смахивает на баг, ведь и в других расширениях все работает
сходным образом
PS: php - 5.2.14, fpm - fpm-0.5.14 (собран как so)
PS: может быть кто то сталкиваося с подобными проблемами?
tantra
То что функция PHP_MINIT_FUNCTION вызываеться всего один раз это
вообщем то нормально. Не нормально то что она вызываеться в процессе
который осуществляет демонизацию, в нем же вызываеться инициализация
sapi(sapi_startup), и после того как он порождает детенка вызываеться
деинициализация sapi(sapi_shutdown) и соовественно вызов у всех
модулей расширений функции PHP_MSHUTDOWN_FUNCTION. Как выриант решения
проблемы это демонизация php сторонними средствами, для FreeBSD
утилита daemon и вот как в моем случае выглядит rc.d скрипт запуска
php-fpm
#!/bin/sh
# PROVIDE: php-fpm
# REQUIRE: NETWORKING SERVERS
# KEYWORD: shutdown
# Add the following lines to /etc/rc.conf to enable php-fpm:
# php_fpm_enable (bool): Set to "NO" by default.
# Set it to "YES" to enable php-fpm
# php_fpm_config (str): Set to "" by default.
# Define your php-fpm configuration file here.
. /etc/rc.subr
name="php_fpm"
rcvar=`set_rcvar`
load_rc_config $name
: ${php_fpm_enable="NO"}
: ${php_fpm_config="/usr/local/etc/php-fpm.conf"}
: ${php_fpm_pidfile="/var/run/php.pid"}
command="/usr/sbin/daemon"
procname="/usr/local/bin/php-cgi"
command_args="-p $php_fpm_pidfile /usr/local/bin/php-cgi --fpm --fpm-
config $php_fpm_config"
pidfile=${php_fpm_pidfile}
reload_precmd="php_fpm_prereload"
quit_cmd="php_fpm_quit"
extra_commands="reload quit"
php_fpm_prereload()
{
sig_reload=USR2
}
php_fpm_quit()
{
sig_stop=QUIT
run_rc_command stop
}
run_rc_command "$1"
Единственное неудобство это то что не перенаправляеться stderr, но это
можно решить использую следующий патч который накладываеться на файл
fpm_stdio.c (в этом случае если erro лог указан в конфиге stderr идиет
в него если нет то просто валиться в стандартный stderr, тобишь в
консоль)
*** fpm_stdio.c.orig Thu Sep 23 13:05:05 2010
--- fpm_stdio.c Thu Sep 23 13:04:57 2010
***************
*** 42,48 ****
int fpm_stdio_init_final()
{
! if (fpm_global_config.daemonize) {
if (fpm_globals.error_log_fd != STDERR_FILENO) {
/* there might be messages to stderr from libevent, we need to
log them all */
--- 42,48 ----
int fpm_stdio_init_final()
{
! //if (fpm_global_config.daemonize) {
if (fpm_globals.error_log_fd != STDERR_FILENO) {
/* there might be messages to stderr from libevent, we need to
log them all */
***************
*** 55,61 ****
zlog_set_level(fpm_globals.log_level);
zlog_set_fd(fpm_globals.error_log_fd);
! }
return 0;
}
--- 55,61 ----
zlog_set_level(fpm_globals.log_level);
zlog_set_fd(fpm_globals.error_log_fd);
! //}
return 0;
}
***************
*** 258,286 ****
int fpm_stdio_open_error_log(int reopen)
{
! int fd;
!
! fd = open(fpm_global_config.error_log, O_WRONLY | O_APPEND |
O_CREAT, S_IRUSR | S_IWUSR);
! if (0 > fd) {
! zlog(ZLOG_STUFF, ZLOG_SYSERROR, "open(\"%s\") failed",
fpm_global_config.error_log);
! return -1;
! }
! if (reopen) {
! if (fpm_global_config.daemonize) {
! dup2(fd, STDERR_FILENO);
}
! dup2(fd, fpm_globals.error_log_fd);
! close(fd);
! fd = fpm_globals.error_log_fd; /* for FD_CLOSEXEC to work */
}
! else {
! fpm_globals.error_log_fd = fd;
! }
!
! fcntl(fd, F_SETFD, fcntl(fd, F_GETFD) | FD_CLOEXEC);
return 0;
}
--- 258,292 ----
int fpm_stdio_open_error_log(int reopen)
{
! if(fpm_global_config.error_log)
! {
! int fd;
! fd = open(fpm_global_config.error_log, O_WRONLY | O_APPEND |
O_CREAT, S_IRUSR | S_IWUSR);
! if (0 > fd) {
! zlog(ZLOG_STUFF, ZLOG_SYSERROR, "open(\"%s\") failed",
fpm_global_config.error_log);
! return -1;
! }
! if (reopen) {
! //if (fpm_global_config.daemonize) {
! dup2(fd, STDERR_FILENO);
! //}
!
! dup2(fd, fpm_globals.error_log_fd);
! close(fd);
! fd = fpm_globals.error_log_fd; /* for FD_CLOSEXEC to work */
! }
! else {
! fpm_globals.error_log_fd = fd;
}
! fcntl(fd, F_SETFD, fcntl(fd, F_GETFD) | FD_CLOEXEC);
}
! else
! {
! fpm_globals.error_log_fd=STDERR_FILENO;
! };
return 0;
}
Eugene Klimov
в качестве эксперимента интересно было бы посмотреть на аналогичное
поведение php-fpm для 5.3.3 и выше, т.е. в состоянии когда он уже стал
официально частью PHP
Ilya Bakulin
PHP 5.3.3 + FreeBSD 8.1-STABLE i386
Ilya V. Yesin
зоне =( Сильно мешает переходу на новую версию.
С кто-нибудь пробовал php-5.3.3 + APC под сильной нагрузкой?
No1
Max Baryshnikov
Наблюдаю аналогичное поведение php-5.3.3 + xcache 1.3.0 на тестовой
зоне =( Сильно мешает переходу на новую версию.
С кто-нибудь пробовал php-5.3.3 + APC под сильной нагрузкой?
On 23 сен, 17:53, Eugene Klimov <bloodjaz...@gmail.com> wrote:
> > Ну чтож сам себе и отвечу, вдруг кому и пригодиться
>
> молодцы что сами разбрались, прошу прощения что морочил голову ruslan с mod_php
> в качестве эксперимента интересно было бы посмотреть на аналогичное
> поведение php-fpm для 5.3.3 и выше, т.е. в состоянии когда он уже стал
> официально частью PHP
--
Sincerely,
Max Baryshnikov
nafan...@gmail.com
Ну вот например
http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html
Вы писали 11 октября 2010 г., 16:50:23:
С уважением,
Nafania293 mailto:Nafan...@gmail.com
Ihalainen Nickolay
PandoraBox2007
я юзаю
Мемкеш
/usr/ports/databases/memcached
и расширения к ПХП
/usr/ports/databases/pecl-memcache
/usr/ports/databases/pecl-memcached
отличная производительность
On 11 окт, 15:34, Ihalainen Nickolay <ihan...@gmail.com> wrote:
> с точностью до погрешностей они сейчас близки,
> лимитирует работа с большими массивами, вычислительная нагрузка или в худшем
> случае работа с базами или внешними урлами.
>
> Падения, также наблюдаются со всеми кешерами опкода (проблемы не только в
> них самих, но и других экстеншинах php, которые корраптят память), в apc
> есть возможность собрать с функционалом перевода shared memory в readonly
> 2010/10/11 No1 <smile.neversm...@gmail.com>
>
>
>
> > А сравнительные тесты с Еакселератором,апц,хкэш имеются?Что в какую сторону
> > лучше.
>
> > 2010/10/11 Ilya V. Yesin <yesin...@gmail.com>
ruslan usifov
PandoraBox2007
On 31 окт, 18:25, ruslan usifov <ruslan.usi...@gmail.com> wrote:
> Вы немного не понимаете назначение APC, прежде всего он предназначен для
> того чтобы не происходило прикаждом запросе перекомпиляции скрипта в байт
> код
>
> 31 октября 2010 г. 16:57 пользователь PandoraBox2007 <
> pandorabox2...@gmail.com> написал:
PandoraBox2007
за холостых двойных тактов
ns
Posted at Nginx Forum: http://forum.nginx.org/read.php?25,132925,147707#msg-147707