我之前也碰到过这个一模一样的棘手问题！调整了系统的ulimit和内核参数后，GATK还是报文件句柄不足的错误，大概率是Java虚拟机本身的文件句柄限制没跟上系统设置，或者你的配置没真正作用到Java进程上。给你几个亲测有效的排查和解决方向：

1. 给Java进程单独指定文件句柄上限 #

GATK是Java程序，默认情况下Java的文件句柄上限可能低于系统设置的值。你可以在启动命令里直接添加Java参数，强制它使用更大的文件句柄限制：

java -XX:MaxOpenFiles=65536 -jar GenomeAnalysisTK.jar \
-T VariantsToBinaryPed \
-R Homo_sapiens_assembly38.fasta \
-V ~/vcf/snp.indel.recal.splitMA_norm.vcf.bgz \
-m ~/03_IdentityCheck/KING/targeted_seq_ped_clean.fam \
-bed output.bed \
-bim output.bim \
-fam output.fam \
--minGenotypeQuality 0

如果这个参数不生效（部分旧版本Java可能不支持），可以试试-XX:-MaxFDLimit，这个参数会让Java忽略自身的限制，直接使用系统允许的最大文件句柄数。

2. 确认系统配置是否完全生效 #

有时候修改sysctl.conf和.bash_profile后，需要重启终端甚至重启系统才能让配置彻底生效。你可以用以下命令验证当前的限制：

# 查看系统全局的文件句柄限制
sysctl kern.maxfiles kern.maxfilesperproc
# 查看当前shell进程的限制
ulimit -a

如果输出的kern.maxfiles、kern.maxfilesperproc和open files都是65536，说明系统层面的配置没问题，问题肯定出在Java进程或GATK的运行逻辑上。

3. 检查VCF文件的索引与完整性 #

你的VCF是bgz压缩格式，必须要有对应的.tbi索引文件。如果索引损坏或缺失，GATK可能会异常打开大量文件句柄。你可以用tabix重新生成索引：

tabix -p vcf ~/vcf/snp.indel.recal.splitMA_norm.vcf.bgz

另外，如果VCF文件的分块过多（比如压缩时用了过小的块大小），也会导致GATK需要打开多个分块文件。这种情况下，你可以用bcftools重新压缩合并成更少的分块：

bcftools view ~/vcf/snp.indel.recal.splitMA_norm.vcf.bgz | bgzip -c > merged_vcf.bgz
tabix -p vcf merged_vcf.bgz

然后用新生成的merged_vcf.bgz重新运行GATK命令。

4. 降低GATK的并行处理线程数 #

GATK3默认会启用多线程并行处理，线程数量越多，同时打开的文件句柄也会越多。你可以强制单线程运行试试：

java -XX:MaxOpenFiles=65536 -jar GenomeAnalysisTK.jar \
-T VariantsToBinaryPed \
-R Homo_sapiens_assembly38.fasta \
-V ~/vcf/snp.indel.recal.splitMA_norm.vcf.bgz \
-m ~/03_IdentityCheck/KING/targeted_seq_ped_clean.fam \
-bed output.bed \
-bim output.bim \
-fam output.fam \
--minGenotypeQuality 0 \
-nt 1

如果单线程能成功运行，说明是并行度导致的文件句柄耗尽。你可以逐步调高-nt的数值（比如从2、4开始试），找到一个既能保证速度又不会触发报错的线程数。

内容的提问来源于stack exchange，提问作者Carmen Sandoval