12 2008存档
每一段音乐都是一段记忆。
昨天又听到了理查德.克莱德曼的钢琴曲，何等熟悉。第一次听到他的钢琴曲是在我初一的暑假，老爸跑长途回来，买了几盘磁带（当然，盗版），司机嘛，车上没 有磁带听跑长途会很闷的（所以家里有很多很多相声磁带），我放来听，觉得棒极了。尤其是改版的《命运》，这样的柔化处理肯定会被交响乐爱好者所鄙夷，但是 对我们这样的普通人来说，却刚刚好。
那个暑假天气很好，每天阳光明媚却不炎热，我每天要么搞搞盆栽、要么看看电视、要么写写毛笔字（怎么听起来像退休老 头？不过当时确实如此），相当悠闲惬意。昨天一听钢琴曲，仿佛一下子穿越了时空，我仿佛又触到了那时温暖湿润的空气、看到了耀眼的阳光和郁郁葱葱的绿色、 听到了老爸跑车回家得意洋洋的叫门声....
昨天又听到了理查德.克莱德曼的钢琴曲，何等熟悉。第一次听到他的钢琴曲是在我初一的暑假，老爸跑长途回来，买了几盘磁带（当然，盗版），司机嘛，车上没 有磁带听跑长途会很闷的（所以家里有很多很多相声磁带），我放来听，觉得棒极了。尤其是改版的《命运》，这样的柔化处理肯定会被交响乐爱好者所鄙夷，但是 对我们这样的普通人来说，却刚刚好。
那个暑假天气很好，每天阳光明媚却不炎热，我每天要么搞搞盆栽、要么看看电视、要么写写毛笔字（怎么听起来像退休老 头？不过当时确实如此），相当悠闲惬意。昨天一听钢琴曲，仿佛一下子穿越了时空，我仿佛又触到了那时温暖湿润的空气、看到了耀眼的阳光和郁郁葱葱的绿色、 听到了老爸跑车回家得意洋洋的叫门声....
对一个多线程的程序做性能测试时发现不管开多少个线程，CPU的使用率总是停留在160％左右，对于四核的CPU，这显然太低了，肯定是程序里哪部分对线
程锁的使用不当。我第一感觉就把问题定在了BerkeleyDB的
get上，因为打开ENV时我用了DB_THREAD参数，会不会是BDB的线程锁造成的？大概看了看BDB的源码，唔....每个ENV带一个
mutex的HANDLE，这线程锁范围还挺寬，整整锁了一个ENV，也不管里面有多少个DB；而且还是mutex，而不是读写锁，估计即使是get，也
会造成cache的变化，所以只能用互斥锁了。
于是改程序：一个进程开多个ENV，减少互斥的机会，结果CPU利用率几乎没变；再改：多个进程，每个进程管一个ENV，CPU利用率就上去了！难道 BDB的锁和进程还有关系？干脆，一句句的注释掉代码，一步一步的测性能，最后发现，问题出在我自己写的Log::Debug()函数里，这里面不判断 log的级别就直接加了一个线程锁，结果即使不打印日志，也会锁住线程，造成了运行效率的低下。
看来调程序还是要先怀疑自己，再怀疑别人。
周一晚上去离公司稍远的二月二春饼店吃饭，感觉环境和服务都很不错，春饼也挺好，奇怪的是生意很清淡。想想家附近的麻辣烫和包子铺，东西都做的不错，可就是生意
一般般。相比公司附近的那几家“黑店”，不是超贵（京尊烤鸭），就是饭菜超油（马兰拉面），不是上菜太晚（牛大王），就是服务极为恶劣（柴家湾服务员语
录：“我们这儿都成你们食堂了！”，喔，你开饭馆的，不做食堂你想做人民大会堂吗！？），但一到中午或晚上，生意都好得不行，就因为吃的人实在太多，做得
差它也有生意！真是太不公平了。
想想这个CBD，也不知道大伙儿为什么爱往这儿挤，搞得附近几家烂餐馆还得宠的不行，唉！
04年的时候装了个RedHat 9.0，用了两三个月，在某次编译内核重启失败后换回了windows。
最近又想起来装个linux玩玩，公司同事很多装ubuntu的，我要是再装一样的就没意思了，所以刻了个fedora 9 的DVD回家装。安装过程和当年装redhat一样，图形化界面，方便。
装完后我把DVD设成软件包的源，结果麻烦了，装xmms，源里没有，装mplayer，源里没有， 装xfce，源里又没有，下了个xfce来装，又说少了什么vte，下了vte来装，装完了xfce还是说找不到vte....自己装咋就这么费 劲？....唉，最后改回网络做源，才顺利装了xfce，发现xfce界面响应也不是传说中的那么快，似乎和gnome差不多。
装个mplayer麻烦，装个xmms老崩，用个bt又死慢....linux还是开发和工作用吧，娱乐还是不太适合。
最近又想起来装个linux玩玩，公司同事很多装ubuntu的，我要是再装一样的就没意思了，所以刻了个fedora 9 的DVD回家装。安装过程和当年装redhat一样，图形化界面，方便。
装完后我把DVD设成软件包的源，结果麻烦了，装xmms，源里没有，装mplayer，源里没有， 装xfce，源里又没有，下了个xfce来装，又说少了什么vte，下了vte来装，装完了xfce还是说找不到vte....自己装咋就这么费 劲？....唉，最后改回网络做源，才顺利装了xfce，发现xfce界面响应也不是传说中的那么快，似乎和gnome差不多。
装个mplayer麻烦，装个xmms老崩，用个bt又死慢....linux还是开发和工作用吧，娱乐还是不太适合。
原先为了在多线程环境下使用bdb，还专门在调用其API前加线程锁。自己加锁除了多出工作量以外，还有一个麻烦：当一个DB的数据很大时，对它的加锁粒度就太大了，会拖慢性能。
后来才发现bdb自己是可以在多线程环境下使用的，只是在DB_ENV初始化时需要加标记：
DB_ENV *dbenv;
u_int32_t flags;
flags | = DB_THREAD;
dbenv->open(dbenv, “/home/data/”, flags, 0);
在这个DB_ENV下的操作就是线程安全的了，不过还有一点要注意，就是get数据时作为value的DBT需要加DB_DBT_THREAD标记（参考）：
DBT tKey,tValue;
tValue.flags = DB_DBT_MALLOC;
...
int ret=m_dbp->get(m_dbp,NULL,&tKey,&tValue,0);
...
free(tValue.data); //由于tValue.data指向的内存是bdb用malloc分配的，所以现在需要用户自己free
使用bdb自己的多线程支持比外部加锁方便、高效很多。
后来才发现bdb自己是可以在多线程环境下使用的，只是在DB_ENV初始化时需要加标记：
DB_ENV *dbenv;
u_int32_t flags;
flags | = DB_THREAD;
dbenv->open(dbenv, “/home/data/”, flags, 0);
在这个DB_ENV下的操作就是线程安全的了，不过还有一点要注意，就是get数据时作为value的DBT需要加DB_DBT_THREAD标记（参考）：
DBT tKey,tValue;
tValue.flags = DB_DBT_MALLOC;
...
int ret=m_dbp->get(m_dbp,NULL,&tKey,&tValue,0);
...
free(tValue.data); //由于tValue.data指向的内存是bdb用malloc分配的，所以现在需要用户自己free
使用bdb自己的多线程支持比外部加锁方便、高效很多。
