WordPress的网站工作几分钟,然后网站失败,数百名“无法分配内存池”的错误

我正在迁移一台机器,并已经移动了几个最小stream量的WordPress网站(最大的网站每天获得约200个独特的用户)。 一切似乎工作正常,但稍后我再次加载它并在浏览器中得到“没有数据收到”。 打开PHP警告/错误消息然后,我看到数以百计的“无法为池分配内存”消息。 如果我重新启动Apache,站点再次运行一段时间,然后再次停止。

有几件事对我没有意义:

  • Apache重启解决了这个问题
  • 在其他网站的问题期间,同一服务器上的另一个WordPress网站继续正常工作
  • 目前的php.ini有更多的内存分配比旧的(我移动了一些变化,但留下的内存在默认情况下,128 MB或东西,在旧的服务器上是16 MB)
  • 在寻求帮助时,我看到了对APC的引用,但是我没有看到在这里使用APC的证据
  • 我试过禁用所有的插件,但没有改变。

作为背景,这个迁移是Apache版本的1.x到2.x版本的变化,但在PHP版本中只是一个相对较小的版本。

我现在不知道该怎么做。

请帮助?

Quinxy

这是我的PHP.ini,如果有帮助(评论剥离适合职位长度):

[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(安装时的默认值)。 我不自觉地使用APC,但也许WordPress使用它(评论剥离):

 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 

打开PHP警告/错误消息

这应该已经在 – 我假设php.ini文件是打开错误日志之后。

我没有看到有证据表明使用APC /我不是有意识地使用APC

这是一个模糊的答案。 你应该知道如何确定。 认真。

如果你运行Wordpress,那么某种操作码caching是非常重要的。

APC附带一个非常有用的脚本(apc.php,可通过http://example.com/php-apc/在我的盒子上访问),它报告了很多有用的信息,包括configuration+多lesscaching当前正在使用+它使用了什么。 后一个事实是相当重要的 – WordPress的performance速度很慢,并且有很多插件试图加快速度 – 其中一些插件使用APC作为存储后端。 禁用插件后,您是否重置了APCcaching?

(你也可以在APC的源码分发中find这个脚本)