我们知道在nginx中运行PHP实际上是PHP-CGI处理的，这里的方法我们用PHP-FPM来实现。PHP-FPM里有一个重写PHP.ini的设置的地方，那么我们把需要隔离的网站用独立的PHP-CGI进程来跑，缺点就是比原来共享PHP-CGI进程要占用更多的内存，因为PHP-CGI进程多了嘛。

先在NGINX里指定解析的PHP进程，我这里没有用端口模式，用端口模式也一样。

location ~ .*\.(php|php5)?$
{
fastcgi_pass  unix:/dev/shm/php-cgi2.socket;
fastcgi_index index.php;
include fcgi.conf;
}

关键是FPM的配置里：在 <value name=”php_defines”>节点中加入：

<value name=”open_basedir”>/var/www2/bbs/:/tmp:/var/tmp</value>

这个节点里写入的配置会覆盖php.ini里的，那么可以利用这点来做多个fpm-php进程了。

最后在启动脚本里设置对应的pid和配置文件的地址。

打开php/sbin目录

里面有php-fpm的启动脚本，复制一份，VI 编辑一下
php_fpm_CONF=/usr/local/php5/etc/php-fpm.conf   针对上面修改的配置文件对应起来修改一下
php_fpm_PID=/usr/local/php5/logs/php-fpm.pid      每个PHP-FPM都需要一个独立的pid

修改好后，就可以启动了，看见有新的pid产生那就可以了。

其他的网站依次类推，一个个配置好就OK了。

互联网严打不应该在针对网民言论上，而应该在切切实实的打击网络犯罪上，才是深得民心之举。何时才能还我们一个清净的环境。

今天运气好，测试下搜索 FTP 550 Access is Denied,没想到被我找到一位繁体的老兄的博客上记录了这样的错误，导致原因居然是前面的ISA防护墙，原来怀疑过这个东西有什么保护措施，但是防火墙管理员说全开了。ISA的预设规则里FTP是read only的，需要把规则里的勾去掉。一切OK了。

环境 CentOS5.3  X86_64

经过大半天的测试，终于装上了coreseek3.1，中间碰到不少问题

mmseg安装是比较容易。

./configure –prefix=/usr/servers/mmseg

make

make install

coreseek安装的时候会出现一些问题，我没有选择python支持。

./configure –prefix=/usr/servers/coreseek –with-mysql=/usr/servers/mysql –with-mysql-includes=/usr/servers/mysql/include/mysql –with-mysql-lib=/usr/servers/mysql/lib/mysql –with-mmseg-includes=/usr/servers/mmseg/include/mmseg –with-mmseg-libs=/usr/servers/mmseg/lib/ –enable-id64 –with-liconv

undefined reference to `libiconv_open’

undefined reference to `libiconv_close’

网上的解决方法是

官网解决办法：

In the meantime I’ve change the configuration file and set
#define USE_LIBICONV 0 in line 8179.
修改configure 文件把 #define USE_LIBICONV 0 最后的数值由1改为0
重新编译。

vi ./src/sphinx.cpp

注释以下代码

#case TOKENIZER_ZHCN_GBK:
#pTokenizer = sphCreateGBKChineseTokenizer
#(tSettings.m_sDictPath.cstr(), tSettings.m_nBest); break;
然后重新编译
make clean

但是这样的方法，把GBK的支持去掉了，只能用UTF8。比较完美的解决方法是

vi /src/Makefile

将

LIBS = -lm -lz -lexpat  -L/usr/local/lib -lpthread

改为

LIBS = -lm -lz -lexpat - liconv -L/usr/local/lib -lpthread

再把根目录下Makefile也这样改一下。

要在configure之后改，然后make。

测试建立索引，出现错误

FATAL: no readable config file (looked in /usr/servers/coreseek/etc/sphinx.conf, ./sphinx.conf)

解决方法，–config后面的路径写绝对路径。

OK了。接下来看看怎么用API了。

世界上曾经最大的互联网门户网公司时代华纳旗下AOL（美国在线）网站，今年3月份，向外界宣布其退出中国内地，终止北京公司的运营。对于AOL停 止在华业务，不少人的第一反应是，“什么？AOL在中国也有运营？”中国的市场，一直就是国际互联网大佬们的伤心地。全球最大的社区网站MY SPACE在中国一事无成；EBAY旗下的易趣由于经营不善，在2005年烧掉1亿美元巨资后，最终全盘嫁给本土公司TOM；雅虎中国在并入阿里巴巴后， 游移不定；而亚马逊全资收购的卓越网也未能收获成功。即使是创造互联网最大神话的谷歌，在中国也和领先者百度有着巨大的差距……如果说出淘宝网和阿里巴巴 的名头，只怕欧美所有网络巨头都得低头致敬。

为什么中国本土互联网企业这么牛？

因为这是中国经济中被管制最少、准入门槛最低的行业，企业家精神在这个行业充分爆发！那些审批惯了大项目，嘴里笔下动辄“统筹规划”、“合理安排” 的政府官员们，在互联网革命兴起之时，大多已达四五十岁之龄。他们不理解，也不明白互联网革命引发的浪潮，别说他们，就是网络行业的市场资深人士，现在也 不明白这个行业最终发展方向。既然大家都找不到北嘛，那么“合理规划促进健康发展”云云，也无从谈起。这行业管制条例怎么写，当官的都没法下笔。这个领 域，也是国有资本最少的，所以政府也不会三天两头出政策搞宏观调控，更不会“大力扶持”。政府听之任之，不帮倒忙，对于中国互联网的发展来说，已经阿弥陀 佛了。

但这个趋势，现在悄悄的发生了变化。

近期市场就传言，中国中央电视台的网站央视网将合并暴风影音。据了解这一计划的内部人士透露，央视网与暴风公司的谈判经过了大约一年的时间，央视网一直不认同以内容供应商的身份与暴风展开内容合作的方式，而是希望直接在运营、收入等方面对接。

而就在央视准备大举进军网络视频领域之时，中国广电总局对网络视频领域进行了大扫荡。本月初，日均访问人数为25万的国内知名BT下载网站“BT中 国联盟”，因未办理《信息网络传播视听节目许可证》被关闭。中国国内另一家知名BT影视下载论坛“悠悠鸟影视论坛”近日也宣布整改转型，将以文字影视评论 为主，BT下载服务将逐渐屏蔽。更有媒体透露，广电总局12月全面展开下一批非法视听站点的备案取缔工作，“影视帝国”、“猪猪乐园”、“圣城家园”等 200多家视听服务站点与论坛都可能被关闭。谁要是认为这两者没有必然联系，那是太天真了。

也许是巧合，那边中国电信部门也开始积极进行手机网络扫黄活动。今年11月25日，中国工信部召开新闻通报会，就近来央视报道手机淫秽色情网站的问 题，要求基础运营商采取积极措施，配合有关部门将扫黄打非行动抓出成效。老于世故的中国人都明白，“扫黄”是题目，内容是“打非”。为何“打 非”？2009年12月21日，由中国社会科学院社会学研究所、社会科学文献出版社出版的2010年《社会蓝皮书》指出，2009年中，中国互联网普及率 达到26%，超过世界平均水平，特别是微博客崛起，网络议题更加广泛。人民网舆情监测室对2009年77件影响力较大的社会热点事件的分析表明，其中由网 络爆料而引发公众关注的有23件，约占全部事件的30%。也就是说，约三成的社会舆论因互联网而兴起，互联网成为新闻舆论独立源头。特别是在传统媒体因为 种种顾虑而缺席或反应迟钝的情况下，互联网孤军深入，成为网民自发爆料和集结舆论的平台。互联网和无线终端嫁接的另一个产品是微视频。微视频是短则几十 秒、长不过半小时的视频短片，在突发事件现场，用手机、DV等非专业设备拍摄，然后发布到网上。特别是城市管理中一些老大难问题，如城管与商贩、拆迁户与 开发商冲突的现场画面传到网上，更容易激起网民的强烈不满，引爆舆论。

阿里巴巴掌门人马云曾经公开表示，已经做好支付宝随时被国有化的准备，因为这涉及到金融安全——其实就是触及到国有金融资本的利益。马云这么说，是 因为阿里巴巴没有办法的情况下，才搞网络金融体系建设，这意味着网络新贵不会考虑对这个领域追加投入。民不和官斗，自古而然，然而在经济领域，民间资本的 意兴阑珊，就意味着这个行业不会有太大前途，永远都处于政府的“振兴计划”和“压缩产能”的周期动荡中。现在政府认为互联网领域涉及经济安全和政治稳定， 并大举管制之时，中国网络新贵将何以自处？中国本土互联网企业前景如何？这个领域产生的财富，还将会是“干净钱”吗？

安邦认为，中国国有资本牟利冲动和政府政治稳定的需求相结合，对互联网领域必然加强管制。而导致的结果，很可能就是互联网行业的活力有所桎梏。尽管互联网的发展，永远充满惊奇，然而考虑到官员们高度关注这个行业，并且国有资本开始垂涎这个领域的高利润，那么对于中国本土互联网行业的前景，我们不能太过于乐观。

（注：安邦咨询公司是中国内地一家独立智库机构，专注于财经与公共政策研究。本文只代表该机构观点。)

转自 http://www.ftchinese.com/story/001030436

接下来就是轰轰烈烈的网络扫黄，本来是一件得民心的事情，可是除了官方媒体在叫好之外，个人站长抱怨声不断，国内机房连二连三遭到一刀切的摧残。站长的正当利益遭到了无情的践踏。此时的站长在国家机器面前就如宇宙中的尘埃，太渺小了啊。站长只能默默忍受着多年经营的希望被强奸，除了能在各大bbs上抱怨，面对强大的施暴者还能做什么？

05，06年的论坛专项备案早就提出了，但是实施有困难，大家都知道这个规定太苛刻了，是一种扼杀，那怎么就不改呢？是法律还是行政命令？这次趁扫黄的势头，又开始给个人站长扣上无证经营的帽子了。每个办正规网站的站长都想使自己的网站健康的发展，但是就偏偏这么难，没证可以办证，难就难在根本就是不想让你办，连通信管理局的人都说这个证难，全省目前只有3-4家通过，这个通过率恐怕大大小于公务员的录取率，查要查的，办又不让通过，这不摆明让个人站长走上绝路嘛。暂且不说这个论坛专项备案是否符合互联网发展的潮流，光申请就是难与上青天，这就是一把乱杀站长的屠刀，随便一扣上这个帽子，9成是死路一条。

从这次对互联网的扫荡背后，我们可以看出中国在互联网方面的落后，不是在于技术，而在于管理存在太大的缺陷。

1、什么部门都可以管互联网，缺少一个专门的机构管理。

2、管理政策远滞后于网络发展，完全是门外汉在管。

3、缺少可行的法律，行政干预大于法律手段。

4、合法利益基本没有保护措施。

5、执法部门缺少监督，权力过大，不受法律约束。

6、行政过程复杂度太高，办网站比办公司的手续更为复杂。

总的来说，在互联网还是人治，行政干预为主要管理手段，做不到法制化，市场化。有些政策落后的可以丢尽制定者的脸，真道是没有文化真可怕啊。可怜了中国的站长，在夹缝中求生，还要天天提心吊胆，日日如履薄冰。有一日，全部彻查的那一天，也就宣告了个人站长时代结束，将来只能回忆传说了。中国互联网社区休矣。

方法一: 用Broadcom的诊断程序

1.到Broadcom网站下载诊断程序并刻录成光盘：
http://www.broadcom.com/support/ethernet_nic/driver-sla.php?driver=NX2-diag
2.用这张光盘引导
3.选择1（FreeDOS Setup），English，Run FreeDOS from CDROM
4.执行下面的命令：
cd nx2
uxdiag -c 1 -mfw 0
uxdiag -c 2 -mfw 0

方法二：升级网卡firmware

[root@ADVTRS104 ~]# wget http://ftp.us.dell.com/network/NETW_FRMW_LX_R239524.BIN
[root@ADVTRS104 ~]# chmod +x NETW_FRMW_LX_R239524.BIN
[root@ADVTRS104 ~]# ./NETW_FRMW_LX_R239524.BIN
Dell Update Package 6.1 (BLD_135)
Copyright (c) 2003-2009 Dell, Inc. All Rights Reserved.
Release Title:
Broadcom BCM95708C PCI-E NIC, BCM5708 Copper LOM, BCM5708 SerDes (Fiber) LOM, BCM5708S Blade Daughter Card (PE1955 Specific),
BCM5709C Dual Port NIC without iSCSI Offload, BCM5722 Based LOM, BCM95722 PCI-E NIC, BCM57710 10GBase-T Dual Port Rack
Mezzanine Card, BCM57710 10GBase-T Single Port NIC, BCM5708 TOE plus iSCSI Offload NIC, BCM5709C Copper LOM, BCM5709S SERDES
LOM, BCM95709 iSCSI Offload Dual Port NIC, BCM5709S Dual Port SERDES Mezzanine Card for Blade Systems, BCM5709C Dual Port Rack
Mezzanine Card, BCM57710 Dual Port KX4 Blade Mezzanine Card, BCM5716 Copper LOM, BCM5709S Quad Port SERDES Noble MC, BCM957711
10G SFP+ Dual Port NIC, BCM95709C 10/100/1000BASET Quad Port NIC, BCM57711 Dual Port KX4 Noble MC, BCM57711 Based LOM, v.5.0.9, A05
Release Date:
September 10, 2009
Default Log File Name:
R239524
Description:
This release updates only one file in the NX2Payload attachment for MDIAGS.  This release must go across platfoms because
the factory can only use one release across all platforms for this diag and firmware program utility.
This is a Sev 1 fix that causes blade add-in devices to be set for PXE which causes a stop in the factory.  THIS RELEASE MUST
BE TAKEN TO ALLOW THE FACTORY TO SHIP SERVERS.
Supported Device(s):
BCM95708C PCI-E NIC
BCM5708 Copper LOM
BCM5708 SerDes (Fiber) LOM
BCM5708S Blade Daughter Card (PE1955 Specific)
BCM5709C Dual Port NIC without iSCSI Offload
BCM5722 Based LOM
BCM95722 PCI-E NIC
BCM57710 10GBase-T Dual Port Rack Mezzanine Card
BCM57710 10GBase-T Single Port NIC
BCM5708 TOE plus iSCSI Offload NIC
BCM5709C Copper LOM
BCM5709S SERDES LOM
BCM95709 iSCSI Offload Dual Port NIC
BCM5709S Dual Port SERDES Mezzanine Card for Blade Systems
BCM5709C Dual Port Rack Mezzanine Card
BCM57710 Dual Port KX4 Blade Mezzanine Card
BCM5716 Copper LOM
BCM5709S Quad Port SERDES Noble MC
BCM957711 10G SFP+ Dual Port NIC
BCM95709C 10/100/1000BASET Quad Port NIC
BCM57711 Dual Port KX4 Noble MC
BCM57711 Based LOM
Fixes / Enhancements:
Syncronizes the boot code to the new driver set.
Adds support for 5716 based controllers.
Adds support for 57711 based controllers.
Adds support for IPv6 iSCSI Boot for 5709, 57710 and 57711 based network adapters.
Updates NCSI on NX2 Management Enabled LOMs.
Collecting inventory…
…….
Running validation…
NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth0)
The version of this Update Package is newer than the currently installed version.
Software application name: NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth0)
Package version: 5.0.9
Installed version: 4.6.8
NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth1)
The version of this Update Package is newer than the currently installed version.
Software application name: NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth1)
Package version: 5.0.9
Installed version: 4.6.8
NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth2)
The version of this Update Package is newer than the currently installed version.
Software application name: NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth2)
Package version: 5.0.9
Installed version: 4.6.8
NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth3)
The version of this Update Package is newer than the currently installed version.
Software application name: NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth3)
Package version: 5.0.9
Installed version: 4.6.8
Continue? Y/N:Y
Executing update…
WARNING: DO NOT STOP THIS PROCESS OR INSTALL OTHER DELL PRODUCTS WHILE UPDATE IS IN PROGRESS.
THESE ACTIONS MAY CAUSE YOUR SYSTEM TO BECOME UNSTABLE!
……………………………………………………………………………………………………………………………………………………………………………
Update success.
Would you like to reboot your system now?
Continue? Y/N:Y
The system should be restarted for the update to take effect.

第一个方法是禁用了固件的管理，很奇怪，怎么会有固件管理。

第二个方法是升级了固件版本

我的操作系统CentOS5.3 64位，这个方法不行。出现故障的机器大多是较新版本的非dell合作的操作系统。如CentOS，FreeBSD，而且好多是64位的，目前不知道是否和64位有关。

只能去换个驱动了。
原厂厂家驱动：http://www.broadcom.com/support/ethernet_nic/netxtremeii.php

解压缩，说明里有安装方式。

再不然就按第一个方法去禁用固件管理，这个………

在经过一天的观察下，在FPM下有错误日志

11月 13 21:19:21.219359 [NOTICE] fpm_got_signal(), line 48: received SIGCHLD
11月 13 21:19:21.219415 [NOTICE] fpm_children_bury(), line 194: child 7528 stopped for tracing
11月 13 21:19:21.219426 [NOTICE] fpm_php_trace(), line 139: about to trace 7528
11月 13 21:19:21.219579 [ERROR] fpm_trace_get_long(), line 78: ptrace(PEEKDATA) failed: 输入/输出错误 (5)
11月 13 21:19:21.220292 [NOTICE] fpm_php_trace(), line 167: finished trace of 7528

google了一下在nginx论坛上也有人问起这个问题，但是没有解决方法。

开始无从下手，换成Spawnfcgi管理php-cgi。结果跑了一个晚上，还以为解决的时候，当我早上登录服务器发现，诡异的事情又出现了，CPU急剧上升100%，负载上升到80-100多。

因为前面分析过，排除mysql的问题导致，因为和以前uchome1.5的beta版由于一个语句里缺少索引字段，导致的PHP-CGI挂掉的现象不一样。mysql死锁导致的异常不会cpu上升100%，只上升负载。问题就缩小到PHP相关上，由于FPM与spawnfcgi都出现问题，也不应该是CGI上的问题，那么只有PHP版本和ZendOptimizer或者eaccelerator之间的问题，想想最有可能的就是eaccelerator，网站上只有一个插件用到ZendOptimizer。 于是把eaccelerator降级下，想到当时为了追新，用了eaccelerator-0.9.6-rc1，而且这个版本改动较大，兼容了PHP6。

将版本换成eaccelerator-0.9.5.3，用spawnfcgi跑了一天多，没有出现问题。估计是瞎猫碰死老鼠撞对了。

环境为

CentOs 5.3 X86—64

nginx-0.8.20

ZendOptimizer-3.3.9-linux-glibc23-x86_64

php-5.2.11

eaccelerator-0.9.5.3

网上搜了一下，还是有人有办法的。

tor提供一个网桥中继功能。

可以通过访问 https://bridges.torproject.org/ 来获取网桥地址。

也可以给 bridges@torproject.org 发邮件，邮件正文为 “get bridges”，立即会收到自动回信。

得到如下信息

Here are your bridge relays:

bridge 67.166.252.156:9001 50190e89af98e18a79828006680748

af5c946a84
bridge 75.190.175.8:443 ea20adbc86c91ae4e067289bb5a649ccac297596
bridge 218.189.200.130:4439 c88ed76dfb3d42ce98047219e190aad4c970d8a4

然后按图设置，后面的key不需要填写。只要IP和端口即可。

这样设置好，就可以翻墙了。如果地址被封，就再去获取网桥地址了。

mysql> SHOW VARIABLES LIKE ‘%query_cache%’;
+——————————+———-+
| Variable_name                | Value    |
+——————————+———-+
| have_query_cache             | YES      |
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 67108864 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+——————————+———-+
6 rows in set (0.00 sec)

have_query_cache
是否支持查询缓存区 “YES”表是支持查询缓存区
query_cache_limit 可缓存的Select查询结果的最大值 1048576 byte /1024 = 1024kB 即最大可缓存的select查询结果必须小于1024KB
query_cache_min_res_unit 每次给query cache结果分配内存的大小 默认是 4096 byte 也即 4kB

经过我测试，

set GLOBAL query_cache_min_res_unit=4096; 的时候，碎片会比较多，在3000多。

set GLOBAL query_cache_min_res_unit=2046;的时候，碎片比较少，在1000多。

但是过小会增加IO负担

mysql>show status;

中间有一段 Qcache_开头的

Qcache_free_blocks                | 4984      |
| Qcache_free_memory                | 30097400  |
| Qcache_hits                       | 701669    |
| Qcache_inserts                    | 832414    |
| Qcache_lowmem_prunes              | 41224     |
| Qcache_not_cached                 | 2654      |
| Qcache_queries_in_cache           | 20527     |
| Qcache_total_blocks               | 46362

1-(Qcache_hits  /Qcache_inserts )是缓存命中率。

但是我总质疑干嘛要1减去这个数字，Qcache_hits 是命令的数量，那么Qcache_inserts是总数，命中数量除以总数，不就是命中率了，这里还要好好查查。

Qcache_free_memory 表示查询缓存区现在还有多少的可用内存
Qcache_hits 表示查询缓存区的命中个数，也就是直接从查询缓存区作出响应处理的查询个数
Qcache_inserts 表示查询缓存区此前总过缓存过多少条查询命令的结果
Qcache_lowmem_prunes 表示查询缓存区已满而从其中溢出和删除的查询结果的个数
Qcache_not_cached 表示没有进入查询缓存区的查询命令个数
Qcache_queries_in_cache 查询缓存区当前缓存着多少条查询命令的结果

这部分和我后来找到的另外的有些出入

MySQL查询缓存变量解释：

Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。

Qcache_free_memory：缓存中的空闲内存。

Qcache_hits：每次查询在缓存中命中时就增大

Qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。

Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个 数字在不断增长，就表示可能碎片非常严重，或者内存很少。(上面的 free_blocks和free_memory可以告诉您属于哪种情况)

Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。

Qcache_queries_in_cache：当前缓存的查询(和响应)的数量。

Qcache_total_blocks：缓存中块的数量。

query_cache_limit：超过此大小的查询将不缓存

query_cache_min_res_unit：缓存块的最小大小

query_cache_size：查询缓存大小

query_cache_type：缓存类型，决定缓存什么样的查询，示例中表示不缓存 select sql_no_cache 查询

query_cache_wlock_invalidate：当有其他客户端正在对MyISAM表进行写操作时，如果查询在query cache中，是否返回cache结果还是等写操作完成再读表获取结果。

query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。

查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。

查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小，要不就是碎片太多。

查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%

示例服务器 查询缓存碎片率 = 20.46%，查询缓存利用率 = 62.26%，查询缓存命中率 = 1.94%，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。

引用一段前辈的话

优化提示：
如果Qcache_lowmem_prunes 值比较大，表示查询缓存区大小设置太小，需要增大。
如果Qcache_free_blocks 较多，表示内存碎片较多，需要清理，flush query cache
根据我看的 《High Performance MySQL》中所述，关于query_cache_min_res_unit大小的调优
，书中给出了一个计算公式，可以供调优设置参考：
query_cache_min_res_unit = (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache