嘿，碰到同时往1000张表写数据的情况确实容易踩磁盘和内存的坑，我来给你分享几个实用的调优方向，亲测有效的那种：

一、先解决磁盘空间暴涨的问题 #

• 开启共享WAL文件：默认情况下QuestDB会给每张表单独创建WAL（预写日志）文件，1000张表的话光是WAL文件就能占掉大量磁盘。你可以在配置文件里设置wal_single_file=true，让所有表共享同一个WAL文件，能大幅减少文件数量和磁盘占用。
• 调整WAL同步策略：默认的wal_fsync_period是1000ms（每秒同步一次磁盘），如果你的业务对数据一致性要求不是极端高，可以把这个值调大到5000ms甚至10000ms，减少磁盘IO的频率，也能降低磁盘空间的临时占用。
• 清理不必要的索引和分区：如果某些字段不需要做查询过滤，就别建索引——索引本身会占用额外的磁盘空间。另外如果用了时间分区，别把粒度设得太细（比如别按小时分），按天分区足够的话，能减少分区表的数量，间接降低磁盘开销。
• 关闭无用的日志：如果不需要追踪提交日志，可以在配置里设置commit_log_enabled=false，这个日志也会占用不少磁盘空间。

二、搞定OOM杀手的内存问题 #

• 限制QuestDB的内存上限：QuestDB是原生C++程序，启动时可以通过-m参数设置内存上限，比如你的机器有16G内存，就设-m 12g，给系统留足富余，避免系统触发OOM杀手。
• 优化WAL内存缓冲区：配合共享WAL的设置，调整wal_mem_size参数，比如设为2G——这个缓冲区是用来暂存待写入的数据，太大占内存，太小会导致频繁刷磁盘。
• 调整ILP工作线程数：InfluxDB Line Protocol的处理线程数ilp.worker.count别设得太多，比如你的CPU是8核，设4-6个就够了，太多线程会导致上下文切换频繁，反而浪费内存资源。
• 批量写入+复用连接：让你的ILP客户端尽量攒够一批数据再发送（比如每批次1-5万条），别单条或小批量频繁发，这样能减少内存中同时处理的请求数。另外要复用客户端连接，别每次写数据都新建连接，每个连接都会占用内存资源。
• 关闭不必要的缓存：如果你的查询场景不多，或者查询都是实时的，可以把query.cache.size设小一点，甚至设为0，释放缓存占用的内存。

三、其他实用小技巧 #

• 禁用swap分区：在Linux系统里设置vm.swappiness=0，让系统尽量用物理内存，避免因为swap频繁读写导致内存占用异常，也能减少OOM杀手触发的概率。
• 用合适的文件系统：尽量用XFS或者Ext4文件系统，这两个对多文件和大文件的支持更好，能提升磁盘读写效率，间接减少磁盘空间的浪费。
• 监控系统状态：用QuestDB自带的questdb-admin工具或者查看日志，实时监控内存和磁盘的使用情况，根据实际负载调整参数——毕竟1000张表的写入场景，得根据你的数据量和机器配置灵活调优。

备注：内容来源于stack exchange，提问作者Andrei Pechkurov