昨天公司一台服务器被机房动手动脚之后,上面的虚拟机变得极不正常。squid基本跑不了三四个小时就out of memory一次。虽然已经把cache_mem调低到free的1/4了。依然如此。 更过分的事情刚才发生了,在又一次挂掉后,squid重启动彻底失败起不来了。 赶紧查看cache.log,其中记载了失败的原因,如下:

storeDiskdInit: msgget: (28) No space left on device
FATAL: msgget failed

一眼看起来像是磁盘空间满了,df一看,没问题呀,use才1%呢! 然后注意到其具体失败处,是msgget函数。msgget是用来新建/获取信息队列的。也就是说,信息队列的某个方面满了。查看一下这方面的信息:

[root@sitesquid1 ~]# ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 67108864
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767
------ Messages: Limits --------
max queues system wide = 16
max size of message (bytes) = 65536
default max size of queue (bytes) = 65536

看着有点晕,队列系统宽度的最大值,这个比较难理解(下面明明有最大大小了呀?)。只好求助百度,原来就是能打开的消息队列的最大个数,或者说消息队列标识符的最大值。 看这个值挺小的,再看网上也有DB2和apache修改这个值的说法,那就修改一下试试:

sysctl -w kernel.msgmni=128

再启动squid,OK!! 再重新看看消息队列标识符到底打开了多少:

[root@spshort5 ~]# ipcs|awk '/msqid/{a=NR}END{print NR-a}'
19

果然是超过16。