為什麼在1.3版本中，對SQL單目錄併發操作的優化無法在一般程式中顯現？

[tanchihpin0517]

你好，我根據 這個 測試了1.3版本對SQL單文件夾併發性能的優化，測試指令如下：
juicefs mdtest "postgres://test:test123@myip:5432/postgres" --depth=1 --dirs=2 --files=100 --threads 100 --write 8192 mdtest
並且得到相似的測試結果：

在 mdtest 確實性能有顯著的提升

但是如果使用簡易的 python 來測試多線程在單文件夾創建文件的速度，卻無法得到優化後的性能：

juicefs stats：

測試代碼：

import multiprocessing as mp
import shutil
from pathlib import Path

from tqdm import tqdm

T = 32
N = 1000

data_dir = "/home/tanch/juicefs_postgres/jfs_test"


def delete_dir(d):
    if d.exists() and d.is_dir():
        print(f"Deleting {d}")
        shutil.rmtree(d)


def create_file(i):
    d = Path(data_dir) / f"test_{i}"
    d.touch()


def main():
    assert Path(data_dir).parent.exists()

    if Path(data_dir).exists():
        delete_dir(Path(data_dir))

    Path(data_dir).mkdir(parents=True, exist_ok=True)

    with mp.Pool(T) as pool:
        pbar = tqdm()
        for _ in pool.imap_unordered(create_file, list(range(N))):
            pbar.update(1)
        pbar.close()


if __name__ == "__main__":
    main()

掛載指令：
juicefs mount "postgres://test:test123@myip/postgres" ./juicefs_postgres --writeback

請問為什麼測試代碼的併發性能會跟 mdtest 相差這麼多？

[Xuyuchao-juice]

mdtest是通过fs层接口直接操作元数据，而你的python脚本使用的Path.create会经过内核系统调用和fuse层，这里消耗了性能。你可以使用我们的1.3新发布的python sdk来做测试，这会更接近mdtest的性能

[tanchihpin0517]

經過測試，使用 python api 得到的性能提升有符合預期

1 process:

20 processes:

[tanchihpin0517]

但我另外測試了 single process 調用 python 內建的檔案操作函數，得到的結果是性能反而提升：

這個結果跟直接調用 python sdk 的結果差不多，我觀察起來這似乎不是額外性能開銷造成的問題，而是 juicefs 目前還無法在 fuse 層利用 1.3 版本的新特性嗎？

[Xuyuchao-juice]

测试脚本主要是在创建空文件，操作耗时几乎完全集中在元数据更新而非数据写入，而多进程与元数据pgsql的交互由于需要竞争锁和IO资源，本质实际上仍然是串行，多进程在这里实际是负优化

[tanchihpin0517]

理解，從juicefs stats中有觀察到客戶端跟object storage沒有傳輸資料。

但我的疑惑是，1.3新增的優化項目中，有包含一項是優化了當sql作為元數據引擎時，在單一文件夾內部並行創建、刪除文件的效能，想請問為什麼使用腳本創建文件（不使用python sdk）沒辦法享受到1.3新特性帶來的效能提升？

而多进程与元数据pgsql的交互由于需要竞争锁和IO资源

在python sdk的測試中，也是開了多個進程同時創建文件，為什麼就沒有遇到競爭鎖和IO資源的問題？

另外，在這邊先感謝您花時間與我討論

[tanchihpin0517]

這邊附上測試python sdk所使用的腳本：

import multiprocessing as mp
import time

from juicefs import Client

T = 20
N = 10000

# data_dir = "/home/tanch/juicefs_postgres/jfs_test"
data_dir = "/jfs_test"


def create_file(pid):
    jfs = Client(name="", meta="postgres://test:test123@myip:5432/postgres")
    for i in range(N):
        if i % T == pid:
            with jfs.open(f"/files/test_{i}", "wb") as f:
                pass


def delete_file(pid):
    jfs = Client(name="", meta="postgres://test:test123@myip:5432/postgres")
    for i in range(N):
        if i % T == pid:
            jfs.unlink(f"/files/test_{i}")


def main():
    create_start_time = time.time()
    with mp.Pool(T) as pool:
        pool.map(create_file, list(range(T)))
    create_time = time.time() - create_start_time

    delete_start_time = time.time()
    with mp.Pool(T) as pool:
        pool.map(delete_file, list(range(T)))
    delete_time = time.time() - delete_start_time

    print(f"Number of creating files per second: {N / create_time:.2f}")
    print(f"Number of deleting files per second: {N / delete_time:.2f}")


if __name__ == "__main__":
    main()

[frostwind]

@Xuyuchao-juice @tanchihpin0517
你们可否尝试如下设置：
https://juicefs.com/docs/zh/community/postgresql_best_practices
设置max_open_conns=10 以及max_idle_conns=10，看看性能有没有改善

我在测试我自己的场景的时候发现一个问题，跟你们的问题不直接相关，但看起来也许有关联。
如果我设置max_idle_conns=1 ，max_open_conns=任何大于1的数字，就会发现到 postgresql出现大量time wait的连接(比方说用netstat -an观测)，大概就是很快连接又关闭的，即使开一个单线程的find命令，也会出现很多这样的time wait连接数量持续上涨。如果把max_idle_conns调整到大于1，这个症状就会很快缓解。比方说max_idle_conns=2 max_open_conns=2 甚至可以开两个find命令，也不会出现连接暴涨（当然DB端的连接数还是不会超过max_open_conns），会有两个很稳定的 established状态的连接。
根据#5512 @anysql 的推荐，我们把max_idle_conns设置成大于等于max_open_conns的数值，比如都是10，会让连接数比较稳定。
另外我们在测试中还观察到了一个问题，我们使用默认的metadata DB连接参数，而且 postgresql metadata DB用ceph RBD这种网络存储，如果遇到网络波动，metadata DB的连接（ select count(*) from pg_stat_activity) 会暴涨到3万左右，很多连接都在清理 jfs_session2并且这个表会膨胀的很厉害，metadata DB的负载会飙升到几百。我猜测可能跟两个因素有关，网络波动的时候，metadata DB到ceph RBD的延迟增加，查询返回更慢，所以juicefs client会需要创建更多连接到DB，另外就是默认没设置max_idle_conns和max_open_conns的时候，如果一个数据库连接查询慢了，即使没有网络波动，也会造成tcp连接数暴涨。
我们暂时还没机会验证下一次网络波动的情况，但我们应该会在后续把metadata DB从ceph RBD存储换成本地磁盘，并且设置max_open_conns和max_idle_conns到10，以避免网络波动的情况。

[Xuyuchao-juice]

@frostwind 谢谢你的建议。这两个参数我已经尝试过了，不能解决我们的问题。我们这个场景只有把max_open_conns设置成1才能改善性能，但这只是串行，这不是我们想要的。还要继续研究。

[frostwind]

我用上面的python测试程序测试的，N=32, T=100000 ,lookup基本在0.5ms以下

Operation           Count     Average(us)          Total(us)     Percent(%)
create                622            1964            1221908           61.1
getattr              1577             448             706789           35.3
lookup               1256             475             597103           29.9
release               621               6               3820            0.2
flush                 621               5               2846            0.1
getxattr                2             978               1957            0.1

差不多是
19405it [01:11, 272.77it/s]

meta DB 是postgresql 17. object storage是ceph rados. juicefs 1.3.0. 不过我没有用writeback挂载参数, 我的是：
Options=_netdev,allow_other,backup-meta=0,buffer-size=2000,readdir-cache,cache-partial-only

meta DB URL参数是 max_open_conns=10&max_idle_conns=10&max_idle_time=30

[Xuyuchao-juice]

就是用@tanchihpin0517 提供的python脚本测试的是吗？

[frostwind]

@Xuyuchao-juice
是的，就是上面第一段那个python的非sdk代码，里面不包含metadata DB URL的，我用的
T = 32
N = 100000
让他跑的时间略长一些。我用的python3 on rocky linux 9

我的postgresql 17的setting ，我用的synchronous_commit =OFF也许对密集写入元数据的场景有利。其他参数都是比较常见的配置。DB后端是ceph RBD。

$ grep -v '^\s*#' postgresql.conf | grep -v '^\s*$'
listen_addresses = '*'		# what IP address(es) to listen on;
port = 5432				# (change requires restart)
max_connections = 50000			# (change requires restart)
tcp_keepalives_idle = 60		# TCP_KEEPIDLE, in seconds;
tcp_keepalives_interval = 10		# TCP_KEEPINTVL, in seconds;
tcp_keepalives_count = 10		# TCP_KEEPCNT;
shared_buffers = 200GB			# min 128kB
maintenance_work_mem = 4GB		# min 64kB
dynamic_shared_memory_type = posix	# the default is usually the first option
bgwriter_delay = 10ms			# 10-10000ms between rounds
synchronous_commit = off		# synchronization level;
max_wal_size = 100GB
min_wal_size = 1GB
wal_keep_size = 100000		# in megabytes; 0 disables
effective_cache_size = 400GB
log_destination = 'stderr'		# Valid values are combinations of
logging_collector = on			# Enable capturing of stderr, jsonlog,
log_directory = 'pg_log'			# directory where log files are written,
log_filename = 'postgresql-%Y%m%d.log'	# log file name pattern,
log_rotation_age = 1d			# Automatic rotation of logfiles will
log_rotation_size = 0			# Automatic rotation of logfiles will
log_truncate_on_rotation = on		# If on, an existing log file with the
log_min_duration_statement = 100	# -1 is disabled, 0 logs all statements
log_autovacuum_min_duration = 0	# log autovacuum activity;
log_connections = off
log_line_prefix = '%m [%p] [%d] [%r] '		# special values:
log_timezone = 'America/Los_Angeles'
cluster_name = 'jfs'			# added to process titles if nonempty
autovacuum_naptime = 10s		# time between autovacuum runs
autovacuum_vacuum_scale_factor = 0	# fraction of table size before vacuum
autovacuum_vacuum_insert_scale_factor = 0	# fraction of inserts over table
autovacuum_analyze_scale_factor = 0.01	# fraction of table size before analyze
datestyle = 'iso, mdy'
timezone = 'America/Los_Angeles'
lc_messages = 'en_US.UTF-8'		# locale for system error message
lc_monetary = 'en_US.UTF-8'		# locale for monetary formatting
lc_numeric = 'en_US.UTF-8'		# locale for number formatting
lc_time = 'en_US.UTF-8'			# locale for time formatting
default_text_search_config = 'pg_catalog.english'
shared_preload_libraries = 'pg_stat_statements'		# (change requires restart)

[Xuyuchao-juice]

@frostwind
我发现cpu和GOMAXPROCS会影响测试结果，我这边用4核机器，GOMAXPROCS设置为2时可以跑出最佳性能， 之前性能下降时GOMAXPROCS=4。想了解下你的cpu核数和GOMAXPROCS是多少？

[frostwind]

@Xuyuchao-juice

# lscpu |grep CPU
CPU op-mode(s):                       32-bit, 64-bit
CPU(s):                               48
On-line CPU(s) list:                  0-47
CPU family:                           6
CPU(s) scaling MHz:                   98%
CPU max MHz:                          3700.0000
CPU min MHz:                          800.0000
NUMA node0 CPU(s):                    0-23
NUMA node1 CPU(s):                    24-47

怎么查看GOMAXPROCS？

[Xuyuchao-juice]

我是在mount时加了一行日志，这样打印出来
logger.Infof("\033[92mOK\033[0m, %s is ready at %s, maxprocs = %d", name, mp, runtime.GOMAXPROCS(-1))

[frostwind]

# cat test.go 
package main

import (
    "fmt"
    "runtime"
)

func main() {
    procs := runtime.GOMAXPROCS(-1)
    fmt.Printf("GOMAXPROCS = %d\n", procs)
}


# go run test.go
GOMAXPROCS = 48

[Xuyuchao-juice]

此问题结论已经确定，是fuse内核限制导致的，详见：
#6293