YaCy 1.942 – Solr `ramBufferSizeMB` experiment on an 8-vCPU Vultr (1024 MB vs 2048 MB)

YaCy
1

I ran a series of performance experiments on a fresh YaCy 1.942 cloud peer and thought the results might be useful for others running larger crawls.

Test system

  • YaCy: yacy_v1.942_202608241908_4660126dc

  • OS: Debian

  • Java: OpenJDK 17.0.20.1

  • Vultr High Performance

    • 8 vCPU
    • 16 GB RAM
    • 350 GB NVMe SSD

  • JVM heap: 8 GB

  • HTCACHE limit: 16 GB

What was tested

I changed Lucene’s indexing buffer (ramBufferSizeMB) from the default configuration to progressively larger values.

Files modified:

  • defaults/solr/solrconfig.xml
  • DATA/INDEX/freeworld/SEGMENTS/solr_9_0/collection1/conf/solrconfig.xml

Settings tested

  • 500 MB
  • 1024 MB
  • 2048 MB

Results

2048 MB

This looked promising initially but after about 10–12 minutes the loader queue became stuck.

The system remained responsive, but crawl throughput became inconsistent.

I reverted back to 1024 MB.

1024 MB

This produced the most stable behaviour.

Mission Control settled around:

  • PPM: ~4,500
  • Heap: ~47–49%
  • Loader: ~170–195/600
  • Load: ~20–22
  • Memory remained comfortable.

Example snapshot:

  • Local PPM: 4509
  • Documents: 352,353
  • Crawl queue: 1,643,837
  • Heap: 47%

Everything remained green except System Load.

Disk behaviour

One surprise was how quickly the web cache filled.

Example measurements:

Component Size
HTCACHE ~16 GB
SEGMENTS ~14 GB
QUEUES ~3.7 GB

Once HTCACHE reached its configured limit, cache growth largely stopped.

Write amplification

Using /proc/<pid>/io to monitor Java’s write_bytes, I observed very bursty behaviour.

During one representative interval:

  • retained data grew by about 1.4 GB
  • Java wrote about 20 GB

Rough write amplification for that interval was approximately 14×.

Other intervals were closer to 6×, suggesting Lucene performs large periodic merge bursts rather than writing at a constant rate.

CPU vs disk

Interestingly, Vultr’s own monitoring showed:

  • CPU typically 60–80%
  • peaks around 90%
  • Disk operations generally below 150 ops/sec

This suggests the bottleneck is much more CPU/concurrency than NVMe IOPS.

Conclusion

For this hardware, my best-performing configuration so far is:

  • JVM heap: 8 GB
  • ramBufferSizeMB: 1024 MB
  • HTCACHE: 16 GB

The peer consistently sustained roughly 4,500 PPM without loader stalls, while increasing the Solr buffer to 2048 MB made the loader unstable.

Has anyone else experimented with ramBufferSizeMB on larger cloud instances (8+ cores)? I’m particularly interested in whether anyone has measured write amplification or found additional Lucene merge-policy tweaks that reduce the large merge bursts.