What we need
The Kubernetes namespace we run the data-loading job in cannot currently create a
generic ephemeral volume
with storageClassName: nvme-ephemeral. We would like it to, so that a NameRes data
load can put its Solr index on node-local NVMe.
(Exact error from kubectl describe pod nameres-loading to be pasted in — it looks
like the namespace is not set up for this storage class, either because the class is
not offered to it or because there is no quota for ephemeral volume claims.)
Why
Building a NameRes backup is, in order: download (network), index (CPU), merge (disk),
optimize (disk), compress (CPU). After the parallelisation work in #278, the two
disk-bound phases dominate — optimize=true alone reads ~130G and writes ~130G in a
single forced merge. Both PVCs currently use storageClassName: basic, so the index
lives on network storage, and no amount of tuning in the Makefile substitutes for the
volume being fast.
Node-local NVMe is the single biggest remaining lever on how long a load takes.
Why ephemeral specifically, and why only one of the two volumes
The loading pod mounts two volumes, and they want opposite things:
/var/solr, the index. Takes the entire write load of the indexing run and then
the read-and-write of the optimize, so it benefits most from being fast. It is also
pure intermediate state: once snapshot.backup.tar.gz exists the index is worthless,
and if it were lost it could be rebuilt from the synonym files sitting on the other
volume. This is the one we want on NVMe, and ephemeral is the honest lifetime for it.data/, the working directory. Holds the ~130G download and the finished backup
tarball — the only thing the whole exercise produces. Stays on a persistent PVC.
Sizing
The request is 400Gi, which needs to fit on a single node's local NVMe alongside
the pod's other resources (currently 32 CPU / 128Gi).
400Gi is not padding: optimize=true writes the new single segment before deleting the
old ones, so peak usage is 2–3x the finished index, and the index is ~127Gi today. It
cannot go much below roughly 2x without the optimize step running out of space.
Status
data-loading/kubernetes/ currently uses the ordinary nameres-loading-solr PVC, so
loads work today — just slower through the merge and optimize phases. The NVMe version is ready and waiting in #281, which should not be merged until
this is sorted out.
The request there is 600Gi, not the 400Gi originally sketched: the finished index
grows with each Babel release, and peak usage during the optimize is 2-3x it.
What we need
The Kubernetes namespace we run the data-loading job in cannot currently create a
generic ephemeral volume
with
storageClassName: nvme-ephemeral. We would like it to, so that a NameRes dataload can put its Solr index on node-local NVMe.
(Exact error from
kubectl describe pod nameres-loadingto be pasted in — it lookslike the namespace is not set up for this storage class, either because the class is
not offered to it or because there is no quota for ephemeral volume claims.)
Why
Building a NameRes backup is, in order: download (network), index (CPU), merge (disk),
optimize (disk), compress (CPU). After the parallelisation work in #278, the two
disk-bound phases dominate —
optimize=truealone reads ~130G and writes ~130G in asingle forced merge. Both PVCs currently use
storageClassName: basic, so the indexlives on network storage, and no amount of tuning in the Makefile substitutes for the
volume being fast.
Node-local NVMe is the single biggest remaining lever on how long a load takes.
Why ephemeral specifically, and why only one of the two volumes
The loading pod mounts two volumes, and they want opposite things:
/var/solr, the index. Takes the entire write load of the indexing run and thenthe read-and-write of the optimize, so it benefits most from being fast. It is also
pure intermediate state: once
snapshot.backup.tar.gzexists the index is worthless,and if it were lost it could be rebuilt from the synonym files sitting on the other
volume. This is the one we want on NVMe, and ephemeral is the honest lifetime for it.
data/, the working directory. Holds the ~130G download and the finished backuptarball — the only thing the whole exercise produces. Stays on a persistent PVC.
Sizing
The request is 400Gi, which needs to fit on a single node's local NVMe alongside
the pod's other resources (currently 32 CPU / 128Gi).
400Gi is not padding:
optimize=truewrites the new single segment before deleting theold ones, so peak usage is 2–3x the finished index, and the index is ~127Gi today. It
cannot go much below roughly 2x without the optimize step running out of space.
Status
data-loading/kubernetes/currently uses the ordinarynameres-loading-solrPVC, soloads work today — just slower through the merge and optimize phases. The NVMe version is ready and waiting in #281, which should not be merged until
this is sorted out.
The request there is 600Gi, not the 400Gi originally sketched: the finished index
grows with each Babel release, and peak usage during the optimize is 2-3x it.