在 sqlite3 中使用多线程时的性能问题

Question

我正在编写一个程序，它为所有子目录中的文件生成哈希，然后将它们放入数据库或将它们打印到标准输出：https://github.com/cherrry9/dedup

在最新的提交中，我为我的程序添加了使用多线程的选项（THREADS 宏）。

以下是我所做的一些基准测试：

$ test() { /usr/bin/time -p ./dedup / -v 0 -c 2048 -e "/\(proc\|sys\|dev\|run\)"; }
$ make clean all THREADS=1 test
real 8.03
user 4.34
sys 4.55
$ make clean all THREADS=4 && test
real 3.94
user 7.66
sys 7.42

您可以使用THREADS=4 编译的版本快 2 倍。

现在我将使用第二个位置参数来指定 sqlite3 数据库：

$ test() { /usr/bin/time -p ./dedup / test.db -v 0 -c 2048 -e "/\(proc\|sys\|dev\|run\)"; }
$ make clean all THREADS=1 && ​test
real 20.40
user 7.58
sys 7.29
$ rm test.db
$ make clean all THREADS=4 && ​test
real 21.86
user 17.17
sys 18.15

使用THREADS=4 编译的版本比使用THREADS=1 的版本慢！

当我使用第二个参数时，在 dedup.c 中执行了将哈希插入数据库的代码：

if (sql != NULL && sql_insert(sql, entry->fpath, hash) != 0) {
// ...

sql_insert 每次调用INSERT 时都会使用事务来防止 sqlite 写入数据库。

int
sql_insert(SQL *sql, const char *filename, char unsigned hash[])
{
    int errcode;

    pthread_mutex_lock(&sql->mtx);
    sqlite3_bind_text(sql->stmt, 1, filename, -1, NULL);
    sqlite3_bind_blob(sql->stmt, 2, hash, SHA256_LENGTH, NULL);

    sqlite3_step(sql->stmt);
    SQL_TRY(sqlite3_reset(sql->stmt));

    if (++sql->insertc >= INSERT_LIM) {
        SQL_TRY(sqlite3_exec(sql->database, "COMMIT;BEGIN", NULL, NULL, NULL));
        sql->insertc = 0;
    }

    pthread_mutex_unlock(&sql->mtx);
    return 0;
}

这个片段针对每个处理过的文件执行，并且由于某种原因它阻塞了我程序中的所有线程。

这是我的问题，如何防止 sqlite 阻塞线程并降低程序的性能？

如果您想知道test 函数在做什么，这里是dedup 选项说明：

1th positional argument - directory to use to generate hashes
2th positional argument - path to databases which will be used by sqlite3
-v level  - verbose level (0 means print only errors)
-c nbytes - read nbytes from each file
-e regex  - exclude directories that match regex

我在 sqlite3 中使用序列化模式。

Answer 1

您的所有线程似乎都使用相同的数据库连接和语句对象。因此，您有一个竞争条件（即使在 SERIALIZED 线程模型中），因为多个线程正在绑定、步进和重置同一语句。在您解决此问题之前，询问“为什么速度慢”变得无关紧要。

相反，您应该用互斥锁包裹您的sql_insert，以保证最多有一个线程正在访问数据库连接：

int
sql_insert(SQL *sql, const char *filename, char unsigned hash[])
{
    pthread_mutex_lock(&sql->mutex);
    // ... actual insert and exec code ...
    pthread_mutex_unlock(&sql->mutex);
    return 0;
}

然后使用pthread_mutex_init 在SQL 结构中添加并初始化该互斥体。

如果您的瓶颈确实是 SHA-256 的计算而不是写入数据库，那么您会看到性能提升。否则这个互斥体的开销应该可以忽略不计，线程数不会对运行时产生显着影响。