今天换了一个服务器运行php久了就会发现Fatal error: Allowed memory size of 33554432 bytes exhausted提示了，下面我来给大家介绍此问题解决地。
解决办法
方法一（推荐）、修改 php.ini 里的 memory_limit 的设置值 8M 改为 120M：memory_limit = 120M
方法二、在最上层的 PHP Script，加入一行：ini_set("memory_limit","120M");
我使用的是否wordpress博客，我的解决办法有点不同，下面也分享一下。
1、网络办法，据说这个适用3.0以前的版本。编辑wp-config.php这个文件，添加
| 代码如下 | 复制代码 |
define(‘WP_MEMORY_LIMIT’, ’64M’); |
|
64M可以更高。可以96M、128M。
2、3.0以后的版本，要修改源文件，介意的就不用改了。在wp-includes目录下找到default-constants.php文件中的以下的代码
| 代码如下 | 复制代码 |
global $blog_id; // set memory limits |
|
第二行 define(‘WP_MEMORY_LIMIT’, ’32M’); 变64M即可。
在利用php解析xml时提示Invalid byte 1 of 1-byte UTF-8 sequence错误了，这个问题我百度查实说是编码问题，结果我把编码处理一下果然KO了，下面我来分享一下解决办法。
错误提示
Invalid byte 1 of 1-byte UTF-8 sequence
原因分析
在中文版的window下java的默认的编码为GBK，也就是所虽然我们标识了要将xml保存为utf-8格式但实际上文件是以GBK格式来保存的，所以这也就是为什么能够我们使用GBK、GB2312编码来生成xml文件能正确的被解析，而以UTF-8格式生成的文件不能被xml解析器所解析的原因。
把xml的encoding属性值UTF-8改为UTF8
org.xml.sax.SAXParseException: Content is not allowed in trailing section
把先要解析和字符串trim()一下即可解决问题。
解决：
1、最简单就是把<?xml version="1.0" encoding="UTF-8"?>改成<?xml version="1.0" encoding="gbk"?>
2、或者把xml打开另存的时候把字符集改为UTF-8后保存
或改程序
| 代码如下 | 复制代码 |
SAXReader reader = new SAXReader(); |
|
我使用的是eclipse编辑器如下操作即可
可以在Eclipse中更改，在 eclipse 的功能表 [Project]→[Properties]，?? [Resources]，在右?的「Text file encoding」，把原?硎窍到y??的??，改? 「UTF-8」。
phpmyadmin超时或响应慢的原因我分析有两种，超时就是设置时间不够，默认为1800秒了，而反应慢估计是phpmyadmin自动检查更新导致的，下面我来具体解决一下操作方法。
今天安装了最新版的phpmyadmin，安装好了测试了一下，发现间或的反应超慢，查看了nginx的日志，是报fastcgi连接超时。然后打开fastcgi的慢日志，发现如下错误：
[10-May-2013 11:15:16] [pool www] pid 10992 script_filename = /usr/share/nginx/html/phpmyadmin-1688/version_check.php [0x0000000002902e78] file_get_contents() /usr/share/nginx/html/phpmyadmin-1688/version_check.php:240
问题明显了，是phpmyadmin不断地进行版本的检查更新，而国内的服务器连接phpmyadmin服务器又是超慢的，且还有可能无法连接，所以导致了超时的现象。
解决方法：
编辑version_check.php文件，在
| 代码如下 | 复制代码 |
<?php： exit; |
|
保存测试，响应慢的问题解决了。
下面来看第二个问题，就是phpmyadmin超时问题
phpMyAdmin的默认超时时间是1800秒，太短了
开发过程中写几行代码回来一看数据库就超时了，
反复登录很烦人。
修改方法：
打开 phpMyAdmin/libraries/config.default.php
找到$cfg['LoginCookieValidity'] = 1440; 行
把1440调大一些就ok了
今天起看发现服务器的nginx产生大量日志了，并且提示PHP Warning: Memcache::connect(): Can\'t connect to 127.0.0.1:11211, Connection timed out (110) in，后来几经周折找出问题所在了。
在一次例行检查日志的时候，发现Nginx日志中出现了大量的PHP连接Memcached超时的报错信息，如下：
PHP Warning: Memcache::connect(): Can't connect to 127.0.0.1:11211, Connection timed out (110) in ...
连上服务器检查Memcached进程运行正常，然后我用一段测试代码检查Memcached是否能够正常连接，结果也很正常。
于是又仔细分析日志，发现那段报错信息是间隔出现的，说明是有一定几率的。这时我回想起上周因为架构问题刚刚把PHP的Session存储路径指向到了Memcached里，可能是因为这个配置增加了Memcached的负载，从而导致在并发量较高时，Memcached出现连接超时的现象。
找到原因就容易解决了。重新调整Memcached的启动参数，增加-c参数来提高连接数量。默认为1024，可以逐步增加以找到最佳数值。我设置为2048。
启动命令为：
| 代码如下 | 复制代码 |
memcached -d -m 256 -c 2048 -l 127.0.0.1 -p 11211 -u root |
|
如果服务器充裕，可以考虑分布式的memcached集群，以降低单个节点上的压力,据说2.5有连接数量过多导致oom的bug
$_COOKIE是php中一个非常好用的东西，但是有时我们会碰到同域名下的不同子域名一样，这样就会存在只能保留一个cookie的问题，下面小编来给各位同学介绍一下。
PHP的超全局变量$_COOKIE带来了很多便利，在某些情况下也会造成困惑。比如在根域和子域下存在同名cookie，$_COOKIE中只能保存一个，应该是哪个？
RFC建议使用长度最长的那个，这样精度最高，但是不同浏览器处理方式不同。我只测试了Chrome，Chrome中根域和子域的同名cookie都发送出去了，这样PHP只接收排在前面的同名cookie，后面的被忽略，这样很容易接收到错误的值。据说Safari遵循了RFC的建议，没有亲自测试，其他浏览器也没有测试。
首先通过SwitchHosts设定虚拟域名：www.111cn.net，并且配置好Web服务器，当然，你手动设置Hosts文件也可以，我本意是为了多介绍几个工具。
然后编写设置Cookie的PHP脚本，先设置子域，再设置根域：
| 代码如下 | 复制代码 |
<?php |
|
再编写浏览Cookie的脚本：
| 代码如下 | 复制代码 |
<?php |
|
BTW：最初写脚本的时候我竟然在setcookie前使用了var_dump，也就是在发送请求头之前有了输出，犯了这样的初学者错误实在是罪过，可更令人惊讶的是脚本没有报错，查了半天原来是因为php.ini里缺省output_buffering = 4096。
先设置再浏览，就能看到结果了，结果显示有效的是子域下的Cookie。
重开一个浏览器窗口，并使用WebDeveloper删除Cookie，或手动删除，避免对结果造成影响。
然后调换两次调用setcookie的顺序，也就是先设置根域，再设置子域：
| 代码如下 | 复制代码 |
<?php |
|
先设置再浏览，就能看到结果了，结果显示有效的是根域下的Cookie。
重复两次测试过程，并用Firebug记录下请求头的差异：
第一次先设置子域，再设置根域：请求头Cookie的值是bar=www;bar=foo，结果有效的是bar=www
第二次先设置根域，再设置子域：请求头Cookie的值是bar=foo;bar=www，结果有效的是bar=foo
也就说，同名Cookie对于服务端PHP来说，在请求头Cookie中，哪个在前哪个生效，后面的会被忽略。
如果使用的不是Firefox，那就用不了Firebug，此时可以用PHP代码来检测Cookie头：
| 代码如下 | 复制代码 |
if (isset($_SERVER['HTTP_COOKIE'])) var_dump($_SERVER['HTTP_COOKIE']); |
|
以上的实验结论是基于Firefox而言的，由于不同的浏览器发送Cookie的策略可能有差异，所以在其他浏览器上结果可能会有所不同，比如在Safari下就始终是子域有效，其他浏览器如Opera，Chrome等未仔细测试。鉴于这个混乱的结论，所以还是不要在子域和根域下使用同名Cookie为好！
结论：目前在根域和子域中使用同名COOKIE是非常不明智的