innodb_log_file_size设多大是合适的?

INNODB_LOG_FILE 过于小,会直接触发CHECKPOINT,导致频繁IO请求; 多大是合适的?

    ========================================
    : (none) 16:13:13> pager grep sequence               
    PAGER set to ‘grep sequence’
    : (none) 16:13:14>
    : (none) 16:13:15>  SHOW engine innodb STATUSG SELECT sleep(60); SHOW engine innodb STATUSG               
    Log sequence number 1450 485101299
    1 row in set (0.09 sec)
   
   
    1 row in set (1 min 0.01 sec)
   
    Log sequence number 1450 505024667
    1 row in set (0.00 sec)
   
    : (none) 16:14:37> nopager
    PAGER set to stdout
    : (none) 16:14:43> select (505024667-485101299)/1024/1024;
    +———————————+
    | (505024667-485101299)/1024/1024 |
    +———————————+
    |                     19.00040436 |
    +———————————+
    1 row in set (0.00 sec)
    ========================================
    Notice the log sequence number. That’s the total number of bytes written to the transaction log.
    我们在高峰期间采样可以得到,1分钟产生19M的日志; 我觉得这个INNODB LOG大小设成 19M*60=1140M 已经足够了;
    60分钟是一个经验值, 你也可以适当调大,比如 500M,3个文件 ;这相对来说是安全的;
    当然你也可以用以下命令来查看日志产生的大小:
    show status like ‘Innodb_os_log_written’; select sleep(60); show status like ‘Innodb_os_log_written’;

目前Apache DoS漏洞的临时解决办法

Apache 项目日前发布了一个拒绝服务(DoS)漏洞警告,该漏洞可让攻击者轻松的让 Apache 软件拒绝服务,该漏洞影响 Apache 的所有版本。而且这样的攻击工具已经公开,该攻击可使 Apache Http Server 占用大多数的内存和 CPU,从而导致无法处理正常的请求。
采用默认方式安装的 Apache 非常容易受此攻击,而且目前还没有相应的补丁版本。

攻击工具: http://seclists.org/fulldisclosure/2011/Aug/175

经过我在apahce 2.2x上的测试,下面的办法是可行的。

下文转自:http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3C20110824161640.122D387DD@minotaur.apache.org%3E

Description:
============

A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:

     http://seclists.org/fulldisclosure/2011/Aug/175

An attack tool is circulating in the wild. Active use of this tools has
been observed.

The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.

The default Apache HTTPD installation is vulnerable.

There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix
is available.

A full fix is expected in the next 48 hours.

Mitigation:
============

However there are several immediate options to mitigate this issue until
a full fix is available:

1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
   either ignore the Range: header or reject the request.

   Option 1: (Apache 2.0 and 2.2)

          # Drop the Range header when more than 5 ranges.
          # CVE-2011-3192
          SetEnvIf Range (,.*?){5,} bad-range=1
          RequestHeader unset Range env=bad-range

          # optional logging.
          CustomLog logs/range-CVE-2011-3192.log common env=bad-range

   Option 2: (Also for Apache 1.3)

          # Reject request when more than 5 ranges in the Range: header.
          # CVE-2011-3192
          #
          RewriteEngine on
          RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
          RewriteRule .* – [F]

   The number 5 is arbitrary. Several 10’s should not be an issue and may be
   required for sites which for example serve PDFs to very high end eReaders
   or use things such complex http based video streaming.

2) Limit the size of the request field to a few hundred bytes. Note that while
   this keeps the offending Range header short – it may break other headers;
   such as sizeable cookies or security fields.

          LimitRequestFieldSize 200

   Note that as the attack evolves in the field you are likely to have
   to further limit this and/or impose other LimitRequestFields limits.

   See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3) Use mod_headers to completely dis-allow the use of Range headers:

          RequestHeader unset Range

   Note that this may break certain clients – such as those used for
   e-Readers and progressive/http-streaming video.

4) Deploy a Range header count module as a temporary stopgap measure:

     http://people.apache.org/~dirkx/mod_rangecnt.c

   Precompiled binaries for some platforms are available at:

    http://people.apache.org/~dirkx/BINARIES.txt

5) Apply any of the current patches under discussion – such as:

   http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g@mail.gmail.com%3e

Actions:
========

Apache HTTPD users who are concerned about a DoS attack against their server
should consider implementing any of the above mitigations immediately.

When using a third party attack tool to verify vulnerability – know that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of
that module.

Planning:
=========

This advisory will be updated when new information, a patch or a new release
is available. A patch or new apache release for Apache 2.0 and 2.2 is expected
in the next 48 hours. Note that, while popular, Apache 1.3 is deprecated.

详解show innodb status(转)

(翻译了mysqlperformance blog的文章,网址为http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/,英文不好,大家见笑)

在show innodb status中,现实的值是每秒中的。确保数据是20-30秒之间的一个抽样,若
将计算时间运行为0或1秒左右的数据抽样,所得的信息是没有意义的。

1、开始信息为数据抽样的时间间隔
CODE:
1.=====================================
2.060717  3:07:56 INNODB MONITOR OUTPUT
3.=====================================
4.Per second averages calculated from the last 44 seconds

2、下面是信号量的信息

CODE:
1.———-
2.SEMAPHORES
3.———-
4.OS WAIT ARRAY INFO: reservation count 13569, signal count 11421
5.–Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
6.Mutex at 0×2a957858b8 created file buf0buf.c line 517, lock var 0
7.waiters flag 0
8.wait is ending
9.–Thread 1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
10.Mutex at 0×2a957858b8 created file buf0buf.c line 517, lock var 0
11.waiters flag 0
12.wait is ending
13.Mutex spin waits 5672442, rounds 3899888, OS waits 4719
14.RW-shared spins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163

在这一块,有两部分内容。一部分是列出当前的等待。它只有在高度并发的环境下,导致innodb不得不频繁进入
os的等待时才会显示。如果通过旋转锁的方式解决这个问题,这一部分将不会出现。
通过此块信息,可以得知当前访问的热点。(但需要对mysql源码有一定了解)
“lock var”的当前值代表的互斥体的状态(locked=1/free=0)
“waiters flag”是当前等待的数量。另外”wait is ending”在此处表示互斥对象已经释放,但os还没有分配线程,
所以继续执行
第二部分的信息是对事件的计数,”reservation count”和”signal count”显示了当前的innodb使用了多少同步数组,
slot被分配给innodb、线程被信号通知使用同步数组的频度。这些计数可以被用于显示innodb需要进入os等待的频度
,通过os waits获得又读写锁、互斥体引起的系统等待。
spin waits和spin rounds是另一个重要的信息。比起os wait,旋转锁的等待开销相对小。但它占用cpu
可也通过调节innodb_sync_spin_loops来适当改变。

下面的信息是关于死锁的
CODE:
1.————————
2.LATEST DETECTED DEADLOCK
3.————————
4.060717  4:16:48
5.*** (1) TRANSACTION:
6.TRANSACTION 0 42313619, ACTIVE 49 sec, process no 10099, OS thread id 3771312 starting index read
7.mysql tables in use 1, locked 1
8.LOCK WAIT 3 lock struct(s), heap size 320
9.MySQL thread id 30898, query id 100626 localhost root Updating
10.update iz set pad=’a’ where i=2
11.*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
12.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313619 lock_mode X locks rec but not gap waiting
13.Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
14. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 00000285a78f; asc       ;; 2: len 7; hex 00000040150110; asc    @   ;; 3: len 10; hex 61202020202020202020; asc a         ;;
15.
16.*** (2) TRANSACTION:
17.TRANSACTION 0 42313620, ACTIVE 24 sec, process no 10099, OS thread id 4078512 starting index read, thread declared inside InnoDB 500
18.mysql tables in use 1, locked 1
19.3 lock struct(s), heap size 320
20.MySQL thread id 30899, query id 100627 localhost root Updating
21.update iz set pad=’a’ where i=1
22.*** (2) HOLDS THE LOCK(S):
23.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313620 lock_mode X locks rec but not gap
24.Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
25. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 00000285a78f; asc       ;; 2: len 7; hex 00000040150110; asc    @   ;; 3: len 10; hex 61202020202020202020; asc a         ;;
26.
27.*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
28.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313620 lock_mode X locks rec but not gap waiting
29.Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
30. 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 00000285a78e; asc       ;; 2: len 7; hex 000000003411d9; asc     4  ;; 3: len 10; hex 61202020202020202020; asc a         ;;
31.
32.*** WE ROLL BACK TRANSACTION (2)

对于上次死锁,显示了什么造成了死锁,在死锁时的状态,它们持有了哪些锁,在等待那些innodb决定将哪个事务回滚。它只是简单的描述,要了解细节,会需要查看binlog

同死锁类似,我们可以获得最近一次外键限制失败的简单信息

CODE:
1.————————
2.LATEST FOREIGN KEY ERROR
3.————————
4.060717  4:29:00 Transaction:
5.TRANSACTION 0 336342767, ACTIVE 0 sec, process no 3946, OS thread id 1151088992 inserting, thread declared inside InnoDB 500
6.mysql tables in use 1, locked 1
7.3 lock struct(s), heap size 368, undo log entries 1
8.MySQL thread id 9697561, query id 188161264 localhost root update
9.insert into child values(2,2)
10.Foreign key constraint fails for table `test/child`:
11.,
12.  CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE CASCADE
13.Trying to add in child table, in index `par_ind` tuple:
14.DATA TUPLE: 2 fields;
15. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 000000000401; asc       ;;
16.
17.But in parent table `test/parent`, in index `PRIMARY`,
18.the closest match we can find is record:
19.PHYSICAL RECORD: n_fields 3; 1-byte offs TRUE; info bits 0
20. 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 0000140c2d8f; asc     – ;; 2: len 7; hex 80009c40050084; asc    @   ;;

innodb将打印引起错误的语句、相应的外键定义以及在父表中最近的记录。

下面是关于当前活动的事务的状态
CODE:
1.————
2.TRANSACTIONS
3.————
4.Trx id counter 0 80157601
5.Purge done for trx’s n:o <0 80154573 undo n:o <0 0
6.History list length 6
7.Total number of lock structs in row lock hash table 0
8.LIST OF TRANSACTIONS FOR EACH SESSION:
9.—TRANSACTION 0 0, not started, process no 3396, OS thread id 1152440672
10.MySQL thread id 8080, query id 728900 localhost root
11.show innodb status
12.—TRANSACTION 0 80157600, ACTIVE 4 sec, process no 3396, OS thread id 1148250464, thread declared inside InnoDB 442
13.mysql tables in use 1, locked 0
14.MySQL thread id 8079, query id 728899 localhost root Sending data
15.select sql_calc_found_rows  * from b limit 5
16.Trx read view will not see trx with id>= 0 80157601, sees <0 80157597
17.—TRANSACTION 0 80157599, ACTIVE 5 sec, process no 3396, OS thread id 1150142816 fetching rows, thread declared inside InnoDB 166
18.mysql tables in use 1, locked 0
19.MySQL thread id 8078, query id 728898 localhost root Sending data
20.select sql_calc_found_rows  * from b limit 5
21.Trx read view will not see trx with id>= 0 80157600, sees <0 80157596
22.—TRANSACTION 0 80157598, ACTIVE 7 sec, process no 3396, OS thread id 1147980128 fetching rows, thread declared inside InnoDB 114
23.mysql tables in use 1, locked 0
24.MySQL thread id 8077, query id 728897 localhost root Sending data
25.select sql_calc_found_rows  * from b limit 5
26.Trx read view will not see trx with id>= 0 80157599, sees <0 80157595
27.—TRANSACTION 0 80157597, ACTIVE 7 sec, process no 3396, OS thread id 1152305504 fetching rows, thread declared inside InnoDB 400
28.mysql tables in use 1, locked 0
29.MySQL thread id 8076, query id 728896 localhost root Sending data
30.select sql_calc_found_rows  * from b limit 5
31.Trx read view will not see trx with id>= 0 80157598, sees <0 80157594

如果只有少量的连接,将会列出所有的事务列表,Purge done for trx’s n:o表示已经清除的事务号,innodb只能清除潜在不使用的事务号,
旧的未提交的事务将会阻塞清除进程,占用资源。通过当前的事务号和清理的事务号的差可以获得相应当前的事务数。
histor list length 6 是在未做空间中未清理的事务。它随着更新和提交事务的增多而增多,随着清理工作而减少。
Total number of lock structs in row lock hash table 是所有事务锁结构分配的数量。注意这不是被锁的行的数量,每个锁会锁住多行。
如果一个连接中,没有运行的事务则显示not started,否则显示active。注:如果是多语句事务,即使处在sleep阶段,也可以是active。
innodb还会显示os的线程id和进程id,这对于使用gdb调试程序时很有用。同时还显示了事务的状态,如fetching或updating。
“Thread declared inside InnoDB 400″表示线程在innodb的内核中运行,还有400个tickets使用。通过使用innodb_thread_concurrency
调节并发在innodb内核中的线程数。如果线程未运行在innodb内核中,其状态显示为waitting in innodb queue或sleeping before joining innodb queue
innodb会让线程在进入等待前先sleep一段时间(当没有足够的slot可用的时候)。这可能使active的线程数小于innodb_thread_concurrency的值。
对此,可以调节innodb_thread_sleep_delay变量来调节sleep的时间长短。它以毫秒计算。
mysql tables in use 1, locked 0显示了该事务使用的表的数量和使用的锁,除非使用alter table或lock table等语句,一般情况innodb不加锁

下面是文件输入输出的信息:
CODE:
1.——–
2.FILE I/O
3.——–
4.I/O thread 0 state: waiting for i/o request (insert buffer thread)
5.I/O thread 1 state: waiting for i/o request (log thread)
6.I/O thread 2 state: waiting for i/o request (read thread)
7.I/O thread 3 state: waiting for i/o request (write thread)
8.Pending normal aio reads: 0, aio writes: 0,
9. ibuf aio reads: 0, log i/o’s: 0, sync i/o’s: 0
10.Pending flushes (fsync) log: 0; buffer pool: 0
11.17909940 OS file reads, 22088963 OS file writes, 1743764 OS fsyncs
12.0.20 reads/s, 16384 avg bytes/read, 5.00 writes/s, 0.80 fsyncs/s

显示了辅助线程insert buffer thread, log thread, read thread和write thread的当前状态。在每个辅助线程上挂起的操作数也显示出来。
同时也显示了挂起的fsync操作。”16384 avg bytes/read”显示了读请求的平均大小。

CODE:
1.————————————-
2.INSERT BUFFER AND ADAPTIVE HASH INDEX
3.————————————-
4.Ibuf for space 0: size 1, free list len 887, seg size 889, is not empty
5.Ibuf for space 0: size 1, free list len 887, seg size 889,
6.2431891 inserts, 2672643 merged recs, 1059730 merges
7.Hash table size 8850487, used cells 2381348, node heap has 4091 buffer(s)
8.2208.17 hash searches/s, 175.05 non-hash searches/s

此处显示了插入缓存和调节hash表的使用状况。number of merges与number of pretty的比率显示了插入缓存的效率
通过non-hash searches比hash searches的值可知hash表的效率。
但无法调节insert buffer 和adjust hash table。

CODE:
1.—
2.LOG
3.—
4.Log sequence number 84 3000620880
5.Log flushed up to   84 3000611265
6.Last checkpoint at  84 2939889199
7.0 pending log writes, 0 pending chkp writes
8.14073669 log i/o’s done, 10.90 log i/o’s/second

log sequence number 显示了innodb向log中写入的bytes。也可得知当前log被flushed到哪一点,通过此可以检验innodb_log_buffer_size的理想状况,
若有30%的数据没有被flush入log中,应该适当增大innodb_log_buffer_size。

 CODE:
1.———————-
2.BUFFER POOL AND MEMORY
3.———————-
4.Total memory allocated 4648979546; in additional pool allocated 16773888
5.Buffer pool size   262144
6.Free buffers       0
7.Database pages     258053
8.Modified db pages  37491
9.Pending reads 0
10.Pending writes: LRU 0, flush list 0, single page 0
11.Pages read 57973114, created 251137, written 10761167
12.9.79 reads/s, 0.31 creates/s, 6.00 writes/s
13.Buffer pool hit rate 999 / 1000

此节信息表明了buffer pool的效率和内存的使用。可获得innodb分配的所有内存,额外的分配的池,buffer pool中的页面数量,free页面的数量,
和脏数据页。由此可以作为依据调节buffer pool的大小,即使free页为0,database pases也将不等于buffer pool的所有大小,因为buffer pool也存入了
锁信息,调节的hash索引,和其他系统结构。
pending reads 和writes 表明了在buffer pool级别悬挂的请求。innodb将多个请求合并到一个文件级别,这里是不同的。此外,还可看到其他的io提交信息,
LRU——用最近最少使用算法换出的脏数据页; flush list:需要通过checkpointing进程刷新的旧页面;single page:独立的页面写操作。
也可看到正在被读写创建的数据页。最后还可看到buffer pool的命中率。

CODE:
1.————–
2.ROW OPERATIONS
3.————–
4.0 queries inside InnoDB, 0 queries in queue
5.1 read views open inside InnoDB
6.Main thread process no. 10099, id 88021936, state: waiting for server activity
7.Number of rows inserted 143, updated 3000041, deleted 0, read 24865563
8.0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s

最后一节信息:以行为基础,显示行操作的数量,及一些系统信息。此处信息相对简单易读,不作介绍。

【转】基于终端的常用工具

网络浏览:推荐使用 Elinks,Elinks 对于框架、表格以及鼠标的支持都很不错。当然,你也可以将LynxLinksw3m、htmlview 作为备选。

邮件收发:Mutt + Fetchmail + msmtp 是很好的组合。其中,Mutt 用于邮件的管理,Fetchmail 用来收取邮件,而 msmtp 则用来发送邮件。

联络聊天:CenterICQ 支持 MSN、Jabber、IRC、Yahoo!、AIM、ICQ 等多种即时通讯协议。它同时也具有一个 UTF-8 版本。其他的工具包括 Freetalk(Gtalk 用户适用)、Naim(支持 AIM、ICQ、IRC 等)、Irssi(IRC 用户适用) 等。

新闻阅读:现在通过 RSS 及时获取信息是一种比较流行的方式。你可以使用 Raggle 来满足每天阅读新闻的需求。Raggle 使用 Ruby 所写,它支持各种版本的 RSS、能够导入/导出 OPML、可定制绑定的快捷键。遗憾的是,Raggle 目前不支持中文。Snownews 虽然功能要弱点,但是对于中文支持很好。

文件管理:Midnight Commander(简称 mc)是一个值得使用的文件管理工具。

查看图片:你可以试试 zgv,我也在使用 feh

听歌观影:如果你需要听歌,MOC 绝对值得一用。另外,你也可以试试 cplay。看电影的话,当然是MPlayer 了。文本编辑:既然已经有了 VIMEmacs,那么我们还奢求什么呢?

下载上传:主力下载工具使用 wget,要加速可以使用 axel。至于上传 ftp,lftp、nftp 都是不错的选择。此外,对付 BitTorrent 的话,则可以使用 rTorrent

窗口管理:TwinScreen,tmux, tmux 很强大。

无线路由器配置IEEE802.11n需要注意的地方

我的无线路由器linksys wrt54g最近不稳定,经常不能上网,需要重启才行,今天又把他的电源搞坏了。索性就准备换一个无线路由器,然后中午就在网上订了Buffalo WHR-G300N V2,晚上就送到了。

 

收到货后,接上网线和电源。连上去后发现自带固件的web界面居然不支持firefox 6,也不太支持IE9。真是让人哭笑不得,难道只支持IE6不成?在此对Buffalo表示强烈的谴责!这不是还不如山寨货吗?

 

立马就把Buffalo WHR-G300N的固件换成了DD-WRT,我刷的是DD-WRT v24-sp2 17201这个版本的,是目前最新的版本。简单配置一下就可以用了。但是用我的笔记本连路由器发现是无线网络是54M。笔记本是Intel 4965AGN的无线网卡,记得以前查过,是可以支持130M的。而Buffalo WHR-G300N V2支持IEEE802.11n,最高可支持300M的速度。所以我笔记本连上去应该有130M才对。

 

经过一番折腾,发现要让路由器支持802.11n,需要配置以下这些地方:

1. 无线网络模式配置成NG-Mixed或N-only.

2. 频道宽度配置成加速(40Mhz)或Dynamic(20/40Mhz),注意,先要把第一步配置好,否则不会出来这两个选项。

3. 无线安全内配置安全模式为WPA Personal 或WPA2 Personal,WPA算法配置为AES。因为802.11n不支持WEP方式加密,而WPA Personal的TKIP算法也不支持。

 

好了,按照上面的配置Buffalo WHR-G300N后,发现无线的速度已经是130M了。

 

 

2011-08-21:经测试,频宽为20Mhz,无线模式为混合也是可以的,看来最重要的是配置安全模式。必需按第3步的方式做。

 

 

 

 

php连接memcached使用短连接造成cpu过高

最近上线的一个项目,开始几天运行良好,负载很底,访问速度也很正常。

 

29号晚上发现在监控内web服务器有点不正常,cpu和负载会突然增高,然后过十来分钟就会恢复正常。ssh连上去看,有几个php-cgi进程cpu的使用是100%。当时怀疑可能是有个别程序没写好,就通知开发这边去查了。从下图可以看到:

 

随着访问量的增加,到了昨天,好几台web都出现这种现象,并且cpu和负载都下不去了。一直是很高的状态。像下图这样:

这就不正常了,用top看资源利用率,%us和%sy还在正常状态,10%以内,就是%si一直会很高,50%~90%。

开始感觉不像是代码没写好了,因为php+memcached+mysql的架构在其它项目上也跑得挺正常的。

top显示的si是指软中断,软中断会使用cpu资源。

看到软中断过高开始怀疑是不是网卡驱动不好,因为以前碰到过有些网卡只会用到一个cpu的软中断,查了查也不是。

那到底是什么使用了这么多的软中断呢?就怀疑是网络连接了,用netstat -anpo | grep :11211 | awk -F" " ‘{print $6}’ | sort |uniq -c  | sort -rn看了一下,发现time_out状态的连接超多。正常不应该有这么多的。

到这里直接就去查php代码了,发现连接代码如下:

            $handle = new Memcache();
            $handle->connect($config[‘host’], $config[‘port’]);

用的是connect,这个是短连接。

理理头绪:为什么软中断会这么高?

因为php连接memcache使用短连接方式,这种方式是每次连上memcached,读写操作完成后,连接关闭,下次需要读写memcache时再重新连。由于php读写memcache特别频繁,自然php连接memcache的次数也就非常多了。而新建连接是需要代价的,会产生软中断。所以就在top内看到%si一直会很高,50%~90%。

基本确定原因后,改代码:

            $handle = new Memcache();
            $handle->pconnect($config[‘host’], $config[‘port’]);

用pconnect,也就是长连接去连memcached,这样每个php进程只要建立一次连接,后面都可以重复利用这个连接。

 

再看服务器,在top内看到%si使用不到1%,cpu和负载都下来了。