protobuf,json,xml,binary,Thrift之间的对比

一条消息数据,用protobuf序列化后的大小是json的10分之一,xml格式的20分之一,是二进制序列化的10分之一,总体看来ProtoBuf的优势还是很明显的。

protobuf是google提供的一个开源序列化框架,类似于XML,JSON这样的数据表示语言,详情访问protobuf的google官方网站https://code.google.com/p/protobuf/Continue reading

Kipmi0进程对CPU使用率很高

突然top发现Kipmi0进程一直占用近乎100%的一个核的资源,等待了一个下午,居然还是如此。

google查不到多少资料,看到一篇说法:是一些平台接口的管理器。不敢贸然杀死,再查查资料。

看看专业的说法:
kipmi is supposed to run with low priority. When you say it consumes 70-90% of the CPUs, is that constant (does it still consume the processor when they are other tasks in the process queue that should have a larger slice of the CPU time) or the 70%/90% comes when the machine is idle? 
A second issue to investigate is whether you have pending controller issues (alarms of varying nature that are not resolved) and/or older versions of controller firmware. 

查看服务chkconfig 发现只有近似 ipmievd  服务,估计就是这个,跟网上资料说的ipmi有出入!

Fix:不需要修复
No fix required. You should ignore increased CPU utilization as it has no impact on actual system performance.

虽然这是一个利用空余的CPU资源进行一些接口自动调节的任务,但看着占那么多的资源还是怕出意外。

找到:可以临时降低

echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us

In our system,after set this parameter,the cpu of kipmi0 decreased to 15%.确实执行上面命令后,所占CPU单核资源从100%降低到10%

You can try this.永久性降低
To make the changes persistent you can configure the options for the ipmi_si kernel module.
Create a file in /etc/modprobe.d/, i.e./etc/modprobe.d/ipmi.conf, and add the following content:
# Prevent kipmi0 from consuming 100% CPU
options ipmi_si kipmid_max_busy_us=100

上面这个编写进去去了,但还没reboot测试

golang中for循环方法的差异

用for循环遍历字符串时,也有 byte 和 rune 两种方式.第一种试为byte,第二种rune.

package main
import (
"fmt"
)

func main() {
s := "abc汉字"

for i := 0; i < len(s); i++ {
fmt.Printf("%c,", s[i])
}

fmt.println()

for _, r := range s {
fmt.Printf("%c,", r)
}

}

输出结果:

a,b,c,d,e,f,d,ä,¸,­,
abcdefd中