C++博客-曲径通幽-随笔分类-Linux Generic

再遇 SQLITE_BUSY

Meiosis — Wed, 06 Jun 2012 08:35:00 GMT

记得以前解决过这个问题，现在帮助同事查BUG的时候，再次遇到，记录一下省的下次再苦苦回忆。
遇到这个问题，一般而言是3种情况造成：
1) 其他线程、进程正在执行一次写操作
根据SQLITE文档，所有写操作(当然SELECT不算写操作)，SQLITE内部都会自动添加事务，这样在线程同时写有依赖关系的表的时候，自然会发生冲突
2) 当前SQLITE被“BEGIN TRANSACTION” lock住了，这个问题其实包含了1)中的隐形调用，另外别忘了自己的代码一定要在执行完BEGIN 后 COMMIT
3) 有statement对象未finalize，且未reset(出错时)
这个情况占多数，我项目中遇到两次都是这个情况，

当然，要注意即使自己未直接调用 prepare-step-finalize，在某些API执行的时候会隐式调用(比如sqlite3_exec)，当然这种情况一般会归在1)里

Meiosis 2012-06-06 16:35 发表评论

linux ssh 任务的断开与重连

Meiosis — Thu, 26 Apr 2012 16:17:00 GMT

直接用自带的 screen 即可解决，screen 中执行的任务 c-a d 之后会把任务切后台，
重新SSH上去之后，screen -ls 找到ID，直接 screen -r [id]

C-a ? 显示所有键绑定信息
C-a w 显示所有窗口列表
C-a C-a 切换到之前显示的窗口
C-a c 创建一个新的运行shell的窗口并切换到该窗口
C-a n 切换到下一个窗口
C-a p 切换到前一个窗口(与C-a n相对)
C-a 0..9 切换到窗口0..9
C-a a 发送 C-a到当前窗口
C-a d 暂时断开screen会话
C-a k 杀掉当前窗口
C-a [ 进入拷贝/回滚模式

Meiosis 2012-04-27 00:17 发表评论

关于 SQLite 优化

Meiosis — Thu, 19 Jan 2012 09:58:00 GMT

项目里遇到一个问题，在我们程序客户端运行时，sqlite数据库会不断自动生成/删除 journal 文件，高峰时候会占用大量的IO，导致程序很慢。
由于客户端本身的数据完整性不重要，性能非常重要，所以想禁止这个文件的生成。
后来查了一下文档，并实践过后，发现网络上所有的关于关闭/打开某些宏来防止生成的方法都不管用。情急之下，只有改源码了。
改的地方是在main.c 的 sqlite3BtreeFactory 里，直接加个宏就好了 omitJournal

1 int sqlite3BtreeFactory(
2   const sqlite3 *db,        /* Main database when opening aux otherwise 0 */
3   const char *zFilename,    /* Name of the file containing the BTree database */
4   int omitJournal,          /* if TRUE then do not journal this file */
5   int nCache,               /* How many pages in the page cache */
6   int vfsFlags,             /* Flags passed through to vfsOpen */
7   Btree **ppBtree           /* Pointer to new Btree object written here */
8 ){
9   int btFlags = 0;
10   int rc;
11
12   assert( sqlite3_mutex_held(db->mutex) );
13   assert( ppBtree != 0);
14
15 #ifdef OMIT_JOURNAL
16   omitJournal = 1; //!< turn off journal file
17 #endif

Meiosis 2012-01-19 17:58 发表评论

研究了一天ZeroMQ，有个严重的问题还没解决

Meiosis — Tue, 14 Jun 2011 08:59:00 GMT

ZeroMQ是一个Message Queue的实现方案，支持超多种语言的Binding，今天研究了一下，起初对它的N:N模型很感兴趣，后来试用了其自带的 Load Balance特性，结果发现一个非常严重的问题，在Server Cluster中，如果有一台服务器在接收消息后Blocking，或者服务器崩溃了，没来得及send response，则客户端的请求一直就停留在这次send req上，永远无法检测出error，我查了关于timeout的文档，后来改用poll模型试了很久，还是没法解决。接下来可能要花时间仔细研读一下Guide了。

Meiosis 2011-06-14 16:59 发表评论

Linux下调试死循环

Meiosis — Mon, 13 Jun 2011 05:49:00 GMT

最近在工作中发现网络通信收发文件部分，发送一次文件后，就再也不能发第二次了。本以为是协议的问题，后来用TOP发现CPU过高，才通过GDB看到了是一个清空Buffer类的代码有BUG，计算无符号整形的操作溢出了。
具体跟踪方法记录一下。首先正常启动程序，然后进行收发文件操作，触发死循环。而后通过 top -H 查看哪个线程(其实是PID，redhat的线程是fork进程实现的)占用CPU过高，而后gdb -p [pid] attach 之，最后bt 打印堆栈。

Meiosis 2011-06-13 13:49 发表评论