metaSPAdes fails during k-mer counting despite sufficient RAM (250 GB available)

[sahana24310-cell]

I am running metaSPAdes as part of a MAG assembly pipeline on 99 metagenomic samples.
All samples were processed identically (same script, same parameters, same system).

System info

RAM: 251 GB
Available at runtime: ~200 GB
Swap: 15 GB

Most samples completed metaSPAdes successfully, including samples with larger FASTQ sizes.

However, 10 samples fail during k-mer counting, even though their input FASTQ files are not the largest.

Failing sample log excerpt

Filtering singleton k-mers
mimalloc: warning: unable to allocate aligned OS memory directly,
fall back to over-allocation (2726297600 bytes, alignment: 67108864)

Memory at failure time

Mem available: ~203 GB

Other samples with larger trimmed FASTQ files (7 GB+) completed successfully.

Question
Why does metaSPAdes fail for these samples despite sufficient available RAM, and why is the FASTQ file size not predictive of success?
Is this related to k-mer diversity, memory fragmentation, or alignment requirements?

Are there recommended parameters or strategies to handle such samples?

[asl]

Why does metaSPAdes fail for these samples despite sufficient available RAM

Why do you think that RAM is sufficient?

FASTQ file size not predictive of success?

Because of different (meta-)genome size, error rate, coverage variation, relative abundance, repeat content, strain content and variation, etc. This is not reflected in input size at all.

Failing sample log excerpt

Please provide the full spades.log from the failed runs as you were instructed in the error log.

[sahana24310-cell]

Why do you think that RAM is sufficient?
This is based on system-level memory availability at runtime (~250 GB total, ~200 GB available, minimal swap). Other samples with larger inputs completed successfully under identical parameters on the same machine. I understand that SPAdes memory usage depends on k-mer graph complexity and alignment/fragmentation rather than total free RAM.

FASTQ file size not predictive of success?
Agreed. FASTQ size was mentioned only as an observation. Factors such as k-mer diversity, error rate, coverage variation, repeats, and strain heterogeneity drive memory usage and are not reflected by input size.

Full spades.log
I will upload the complete spades.log from the failed run

[spades.log](https://github.com/user-attachme
spades.log
nts/files/24859526/spades.log)

[sahana24310-cell]