Skip to main content

Diagnostic checklist

Before diving into specific issues, verify the following:
  • Server is running and reachable (docker ps, nc -zv)
  • Configuration file is valid (--validate)
  • Data directory is writable and mounted
  • Collection contains data (points_count > 0)
  • Vector dimensions match query input
  • Logs don’t show startup errors

Quick reference: common issues

Connection issues

Server not reachable

1

Confirm the container is running

If the container is not listed, start it:
2

Check the port binding

Verify port 6574 is exposed:
Expected output: 6574/tcp -> 0.0.0.0:6574
3

Test connectivity from the host

If this fails, check for firewall rules or other processes using the port:
4

Check server logs for binding errors

UNAVAILABLE error from SDK

This error indicates the client cannot reach the server. In addition to the steps above:
  • Confirm the host and port passed to VectorAIClient match the container binding
  • If connecting from another container, use the Docker network service name instead of localhost:
  • Check that TLS settings match — if the server has TLS enabled, the client must also enable TLS

Search issues

Search returns no results

Verify collection state

If indexed_vectors_count is lower than points_count, the index is still building. Wait for indexing to complete before evaluating search quality.

Search quality

If search returns results but they are inaccurate or irrelevant, the issue is usually related to index parameters, distance metrics, or embedding configuration.

Poor recall or irrelevant results

hnsw_ef controls how many candidates the HNSW graph explores during search. Increase it to trade speed for better recall:
Verify that the collection’s distance metric matches the one used to train your embedding model:
Common mismatch: using Cosine with embeddings trained for Dot product.
Cosine similarity requires unit-normalized vectors. If your embedding model does not normalize by default, normalize before inserting and before querying:

Performance issues

Slow ingestion

Slow queries

Startup failures

Container exits immediately

Use logs to diagnose issues

VectorAI DB logs provide the fastest way to identify root causes. Common patterns:
  • error → configuration or runtime failure
  • warn → potential performance or data issues
  • info → normal operation (useful for tracing flow)

Memory issues

Memory consumption depends on the number of vectors, their dimensionality, concurrency, and the HNSW index configuration.

High memory usage

High memory usage usually becomes more noticeable when:
  • The collection contains a large number of vectors
  • Vector dimensionality is high
  • Query concurrency is high
  • The index graph maintains more connectivity between nodes

What is m?

In an HNSW index, m refers to the number of edges each node maintains in the graph.
  • Higher m usually improves recall by increasing graph connectivity
  • Higher m also increases memory usage and index build cost
  • Lower m reduces memory overhead but may lower search quality
For more background, see Vector index concepts.

Data persistence

By default, Docker containers store data in a writable layer that is discarded when the container is removed. Mount a volume to preserve data across restarts.

Data lost after container restart

Ensure a volume is mounted to the data directory:
Verify the volume mount:

Next steps

Error handling

Handle specific gRPC error codes in your application code.

Docker setup

Container setup, volume mounts, and Docker Compose configuration.

HNSW indexing

Configure index parameters that affect search quality and performance.