2009-11-20 19:04
为了维护ttserver的服务器，用crontab每天半夜删除三天前和超过1G的ulog文件。
通过监控系统发现，删除文件的时候，内存的下降量和磁盘空间的下降量一致！！！
比如，删除了10G的磁盘文件，内存也紧接着下降10G。（当然，并不是一个ttserver，部署了10个ttserver的master，又部署了10个ttserver的slave）
暂不能确定是什么原因导致内存使用和磁盘同步下降。
猜测如下：采用slave/master模式后，master会映射旧的ulog文件，同步给slave。映射首先占用虚拟内存，读取的过程中逐渐分配了更多 |
2009-11-17 14:04
使用中发现，创建ttserver hash database 数据库后，如果修改桶大小，再启动，tch文件的大小并未改变。通过以往的实验得知ttserver在运行时映射了整个桶，如果修改桶大小，而数据文件的大小未发生变化，说明桶大小一旦指定，就无法修改。
因此，要注意在前期规划的时候就设置好桶大小；否则想通过修改桶来提升性能，就非得引起停机不可。 |
2009-11-13 20:01
终于开始在团队中推广使用ttserver了，可今天一位同事在使用ttserver的时候，根本无法插入数据，写入数据的时候，ttserver返回：error: 9999: miscellaneous error。
上次遇见这个错误，是因为服务器磁盘满，这次也是？
磁盘、内存，以及当天的天气等，都非常正常。
而且，ttserver出现突然崩溃，或者无法启动的现象。
认真检查启动参数，发现hash database的桶设置得非常大：20亿！
难道是这个问题？
把桶大小修改为2亿后，一切正常。
由此说明，ttserver的桶大小是有 |
2009-11-13 19:43
今天在linux下做一些测试，程序频繁在data目录下产生数据。在新一轮测试前，我删除data目录下的数据：
rm -fdr data/*
不巧，硬盘上有一个/data分区……
正好这会儿很晚了，肚子很饿，人很累……
敲命令的时候偶然敲成了rm -fdr /data -_-!
悬崖勒马，没敲回车，不然整个分区的数据就没了。
于是我想到，data这种普通的名字，谁都会取，很方便，很偷懒。
可是人总是会出错的，一个不小心，偷懒的命名就成为了祸根。
于是赶紧把自己的 |
2009-11-08 11:37
最近打算写一个BitArray，用于统计大量整数号码的出现情况。标记完相关的bit后，再统计有多少个bit是1。于是问题出来了：怎么样快速统计一个字节中有多少个1？
第一反应是：
char a_byte = xxx;
int count = 0;
for (int i=0; i<8; ++i)
{
count += (a_byte>>i & 1);
}
还有什么技巧可以提高性能？
性能最好的办法其实是查表法：构造一个拥有256个元素的char数组，每个单元的值，是其对应下标的数值中的1的个数。那么，任意一个char在表中查找即可得知 |
2009-10-27 21:50
今天对服务器进行压测，模拟的请求量到4万次/分的时候，进程的CPU占用就已经达到400%了（也就是把四个核都占到100%）。其实模拟的请求数据都是单一的，不会因为BUG的原因导致CPU过高。怀疑是代码里的STL用得过多，加之ttserver和memcached大量的读操作——大量的小内存分配可能带来全局的锁竞争，从而可能使得CPU过高。
之前听说过google的tcmalloc是一个很好的线程内的内存分配器，能够提高内存分配的性能。正好今天试试能不能改善我的代码的性能。
安装的过程如下：
#1、到google下载代码：
|
2009-10-26 21:09
今天又犯了个低级错误，花了N多时间，换了N多办法，最终还是在导演（哦，其实是导师！）的帮助下找到了原因。
项目中使用ttserver做持久化存储，使用memcached作为缓存。某个逻辑是，先从cache获取数据，如果没有，再从ttserver获取数据，最后再把数据写回cache。
可是代码里不小心把memcached的初始化参数传入成ttserver的IP和端口。
就是这样一个简单的小动作，发现这个问题还真的非常不容易。因为ttserver是一个很好很强大的东东，它是完全兼容memcached客户端协议的，所以当memcached客户端连 |
2009-10-23 10:48
tbb 2.2中提供了统一的头文件：tbb.h，只要包含这个文件就可以使用所有tbb的库了。
为了使用起来方便，以及可以使用静态库，可以使用以下这些命令自己创建：
# 1. 先下载 tbb22_20090908oss_src.tgz, 去 http://www.threadingbuildingblocks.org
# 2. 解压
tar -zxvf tbb22_20090908oss_src.tgz
cd tbb22_20090908oss
#编译，没必要直接make，很多东东其实不需要
make tbb && make tbbmalloc
#编译好的东东在build目录下，不同的编译器和操作系统，文件夹的名字不一 |
2009-10-22 20:47
今天在写一个服务器程序的时候，发现请求量大的时候，程序发生崩溃，原因是我传入某个函数的string的size()过大。
这个程序是一个典型的生产者/消费者：生产者产生的信息放入 string，然后加锁放入std::queue中；消费者线程加锁，从std::queue.front()中获得对象的应用，然后pop()队头元素。一切看起来都是那么清晰简单。
消费者的代码看起来就像是这样：
string& str = q.front();
q.pop();
func( str.data(), str.size() );
为什么从队列取出string后，size就变了？
试了很 |
2009-10-20 20:17
可以把ttserver理解成一种key-value形式的数据库，在运营中就像管理数据库一样去管理ttserver，使得性能和数据安全都能得到较好的保障。
部署ttserver的方式，可以根据访问量和数据规模循序渐进地这样部署：
1、单机：数据量不大，访问量不大
ttserver -host 192.168.0.100 -port 20001 -thnum 128 -dmn -ulim 1024m -ulog /home/ahfu/temp/test_data/test_ulog_01 -log /home/ahfu/temp/test_data/log/test_data_01.log -pid /home/ahfu/temp/test_data/log/test_data_01.pid -sid 1 /home/ahfu/t |
|
|
|
加为好友
送他礼物
发送消息
