存档

2014年3月 的存档

代码优化(1)

2014年3月20日 没有评论

代码优化,其实是有很多很基本的准则的,这里,不提算法层面的优化,因为这个层面的优化,没有太多好说的,一个好的算法,比各种各样的优化来得都更加靠谱
不多扯,看下面的基本规则
1. 延迟计算
2. 减少函数调用次数
3. 核心代码尽量短小
4. 合并IO读写
5. 控制数据结果大小,一般情况下是缩小(在已经考虑内存对齐的情况下)
6. 减少浮点运算,在精度允许的情况下,采用整数运算(放大再运算,保证精度范围)
7. 控制锁粒度、

其实写了那么多,归纳下来,就是那么几个点
1. 尽量保证cache的命中率(核心数据结构,核心代码足够短小,核心逻辑的代码尽量靠近,不要有长距离的跳转)
3. 减少浮点运算,尽量用整数运算(cpu的浮点运算和整数运算能力差异太大了)
4. IO合并

然后,具体到代码层面,大概可以看到这些特点
1. 延迟构造对象,对象要用的时候,再构造,所以,能压缩声明周期就压缩生命周期
特别是对于c++这种代码
甚至可以考虑
{
type obj;
} // 手工加上限制的作用域
2. 减少数据结构的大小
当数据结构太大的时候,超过一个cache line长度的时候,就需要考虑了,因为,压缩一次,cpu的读取就可能要少多次。一般的做法是,对成员进行重排,防止对齐的padding,然后是,合理的压缩字段的长度,比如,一个标志位,8个标志够了,就不用给int了,一个char就够了,甚至可以考虑位域。
3. 核心代码的逻辑要紧凑,不要散落得哪里都是
很多人写代码,写到哪里是哪里,结果,一条主线逻辑,几乎贯穿了整个代码,中间到处是各种异常逻辑,然后各种跨库的调用,这些东西都是很影响性能的。因为,非主线逻辑,很多时候,不会执行,这是给编译器的优化增加难度。所以,能把核心逻辑提炼出来,最好还是提炼出来,同理,经常调用的代码,最好写在一起,同一个文件,这样编译出来,物理位置也靠近。
算了,不写了,下次接着继续

修改VG名称后,ubuntu开机进入busybox处理过程

2014年3月15日 没有评论

场景重现:
ubuntu12.10,光盘默认安装,根分区使用LVM分区,安装后使用devstack,安装openstack,安装需要使用名为 stack-volumes的VG,所以就把vg给重命名了,然后机器一直在用,直到异常断电,就没起来,启动就进入busybox。机器上有几十个instance等着用,各种着急。
处理中走过的弯路:

1、首先,是异常断电,怀疑是根分区数据丢失,用livecd进去,使用fsck进行扫描,没发现错误,
重启还是进入busybox,放弃。
2、进而,期间有一次系统更新,怀疑更新后的内核文件有问题,遂用之前备份的内核文件恢复,
重启后依然进入busybox,放弃。

最终处理方案:

1、开机进入grub后,按e进行编辑,手动修改根分区,Ctrl+x启动。
2、进入系统后修改 grub.conf,将根分分区的名字改为修改后的,就ok了。

大家可能说这是很简单个问题,你搞那么久,确实是个简单的问题,但是在处理的当时我完全对自己改了vg名字这个事情丝毫没有印象,当时比较着急,也忽略了一些信息,在重现的时候,才发现进入busybox之前是有提示的,当时被疏忽掉了,所以导致走了很多弯路。
所以大家遇到问题:

第一,不要慌,系统总是会给你蛛丝马迹的。
第二,不要急着下结论,作出让情况更糟糕的举动,比如我差点就发故障邮件,重装系统。
分类: 关于技术 标签: