c - 在 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 使用事务来防止 sqlite 在我每次调用 INSERT 时写入数据库。

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 线程模型中)，因为多个线程正在绑定(bind)、步进和重置相同的语句。在解决此问题之前，询问“为什么这么慢”变得无关紧要。

相反，您应该用互斥量包装您的 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 的计算而不是写入数据库，您将看到性能提升。否则，此互斥量的开销应该可以忽略不计，并且线程数不会对运行时产生重大影响。