1

I'm migrating a machine and have moved over several minimal traffic WordPress sites (biggest site gets ~200 unique users a day). Everything appeared to work fine but then a little while later I loaded it again and got 'No data received' in the browser. Turning on PHP warnings/error messages I then saw hundreds of 'Unable to allocate memory for pool' messages. If I restart Apache the site works again, for some period of time, then stops again.

Several things make no sense to me:

  • Apache restart resolves the problem
  • A different WordPress site on same server continues to work fine during the problem with the other site
  • Current php.ini has more memory allocated than old one (I moved over some changes but left items like memory at the default, 128 MB or something, on old server it was 16 MB)
  • In searching for help I see references to APC, but I see no evidence that APC is used here
  • I tried disabling all plugins, but no change.

As background, this migration was a 1.x to 2.x Apache version change, but only a relatively minor one in PHP version.

I've got no idea what to do now.

Help please?

Quinxy

Here's my PHP.ini in case it helps (comments stripped to fit post length):

[PHP]

engine = On
short_open_tag = On
asp_tags = Off
precision = 14
y2k_compliance = On
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 100
allow_call_time_pass_reference = On
safe_mode = Off
safe_mode_gid = Off
safe_mode_include_dir =
safe_mode_exec_dir =
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
disable_functions =
disable_classes =
expose_php = On
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
html_errors = Off
error_log = /var/log/php.log
variables_order = "GPCS"
request_order = "GP"
register_globals = On
register_long_arrays = On
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 10M
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
doc_root =
user_dir =
enable_dl = On
file_uploads = On
upload_max_filesize = 10M
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
[Date]
[filter]
[iconv]
[intl]
[sqlite]
[sqlite3]
[Pcre]
[Pdo]
[Phar]
[Syslog]
define_syslog_variables  = Off
[mail function]
SMTP = localhost
smtp_port = 25
sendmail_path = /usr/sbin/sendmail -t -i
mail.add_x_header = On
[SQL]
sql.safe_mode = Off
[ODBC]
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
[MySQL]
mysql.allow_persistent = On
mysql.max_persistent = -1
mysql.max_links = -1
mysql.default_port =
mysql.default_socket =
mysql.default_host =
mysql.default_user =
mysql.default_password =
mysql.connect_timeout = 60
mysql.trace_mode = Off
[MySQLi]
mysqli.max_links = -1
mysqli.default_port = 3306
mysqli.default_socket =
mysqli.default_host =
mysqli.default_user =
mysqli.default_pw =
mysqli.reconnect = Off
[PostgresSQL]
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
[Sybase-CT]
sybct.allow_persistent = On
sybct.max_persistent = -1
sybct.max_links = -1
sybct.min_server_severity = 10
sybct.min_client_severity = 10
[bcmath]
bcmath.scale = 0
[browscap]
[Session]
session.save_handler = files
session.save_path = "/var/lib/php/session"
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
uch as JavaScript.
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440
session.bug_compat_42 = Off
session.bug_compat_warn = Off
session.referer_check =
session.entropy_length = 0
session.entropy_file =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 5
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
[MSSQL]
mssql.allow_persistent = On
mssql.max_persistent = -1
mssql.max_links = -1
mssql.min_error_severity = 10
mssql.min_message_severity = 10
mssql.compatability_mode = Off
mssql.secure_connection = Off
[Assertion]
[COM]
[mbstring]
[gd]
[exif]
[Tidy]
tidy.clean_output = Off
[soap]
soap.wsdl_cache_enabled=1
soap.wsdl_cache_dir="/tmp"
soap.wsdl_cache_ttl=86400
[sysvshm]

apc.ini (the default on the installation). I'm not consciously using APC, but maybe WordPress uses it (comments stripped):

extension = apc.so
apc.enabled=1
apc.shm_segments=1
apc.shm_size=64M
apc.num_files_hint=1024
apc.user_entries_hint=4096
apc.ttl=7200
apc.use_request_time=1
apc.user_ttl=7200
apc.gc_ttl=3600
apc.cache_by_default=1
apc.filters
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.file_update_protection=2
apc.enable_cli=0
apc.max_file_size=1M
apc.stat=1
apc.stat_ctime=0
apc.canonicalize=0
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.include_once_override=0
apc.lazy_classes=0
apc.lazy_functions=0
apc.coredump_unmap=0
apc.file_md5=0
apc.preload_path

1 Answers1

0

Turning on PHP warnings/error messages

This should have been on already - I assume that the php.ini file is after you switched on error logging.

I see no evidence that APC is used here / I'm not consciously using APC

That's rather a vague answer. You should know how to find out for sure. Seriously.

If you run Wordpress then some sort of opcode cache is pretty essential.

APC ships with a very useful script (apc.php, accessible via http://example.com/php-apc/ on my box) which reports lots of useful information including the config + how much of the cache is currently in use + what it is used by. This latter fact is rather important - Wordpress is phenomonally slow and there are lots of plugins which try to speed it up - some of which use APC as a storage backend. Did you reset the APC cache after disabling the plugins?

(You'll also find this script in the source distribution for APC)

symcbean
  • 21,009
  • 1
  • 31
  • 52
  • I was trying to convey that I never knew about APC until yesterday when I ran into this issue. I've cached in PHP via various homegrown and third-party mechanisms, but never APC. With WordPress I use the W3 cache plugin which can cache via SQL, memcached, filesystem and maybe APC. Maybe migration suddenly allowed APC capabilities in WP/W3 Cache, but even disabling ALL plugins (and specifically W3 Cache) I still had the problem. So does core WordPress use APC? I didn't find proof of that. Does PHP internally now use APC? I didn't find proof of that. With all plugins disabled I am confused. – Quinxy von Besiex May 01 '13 at 00:37
  • As a temporary work-around (since I have no idea what else to try) I set apc.enabled=0 in apc.ini and now things don't suddenly start failing after a few minutes of Apache running... everything works, albeit without APC available to whatever was trying to use it. – Quinxy von Besiex May 01 '13 at 00:39