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线程模型中也是如此(，因为多个线程正在绑定、步进和重置同一语句。在你解决这个问题之前，问"为什么速度慢"变得无关紧要。

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