Konfiguration: Import-Debug-Log nachziehen
tibi-server 197e6c0 ergaenzt `search.workerDebug` / `SEARCH_WORKER_DEBUG` (sparses Batch-Log) und die Panik-Absicherung im Embedding-Pfad. - server/konfiguration: fuenfter Schalter mit Default/Env, Beispielzeile des Logs und Hinweis auf die Cadence (erster, jeder zehnte, jeder Batch ueber 5 s), damit der Import ohne Log-Flut diagnostizierbar ist. - Beleg-Stempel auf 197e6c0 aktualisiert. Build und audit-docs.mjs gruen.
This commit is contained in:
1 parent
39f91a2e35
commit
7cb57be362
2 files changed
+6
-3
No files matched your search
@@ -1,5 +1,5 @@
|
||||
{
|
||||
"generatedAt": "2026-10-20T14:28:23.273Z",
|
||||
"generatedAt": "2026-10-20T14:57:33.521Z",
|
||||
"stats": {
|
||||
"files": 70,
|
||||
"byDir": {
|
||||
|
||||
@@ -188,7 +188,7 @@ search:
|
||||
|
||||
## Suche: Import-Tuning und Worker-Pool (`search.*`)
|
||||
|
||||
Die vier Schalter darunter steuern, wie viel ein großer Import (Zehntausende Dokumente) parallel arbeitet. Alle sind optional; ohne Angabe bleibt alles beim bisherigen Verhalten.
|
||||
Die fünf Schalter darunter steuern, wie viel ein großer Import (Zehntausende Dokumente) parallel arbeitet. Alle sind optional; ohne Angabe bleibt alles beim bisherigen Verhalten.
|
||||
|
||||
```yaml
|
||||
search:
|
||||
@@ -196,6 +196,7 @@ search:
|
||||
workerWindowSize: 25 # Gelesene Dokumente pro Worker-Fenster (Default: 25, max. 1000)
|
||||
workerConcurrency: 1 # Parallele Worker-Jobs je Provider/Gruppe (Default: 1, max. 8)
|
||||
writeConcurrency: 4 # Parallele Dokument-Updates je Fenster (Default: 4, max. 32)
|
||||
workerDebug: false # Kompaktes Import-Log pro Batch (Default: aus)
|
||||
```
|
||||
|
||||
| Env | Config-Pfad | Wirkung |
|
||||
@@ -204,10 +205,12 @@ search:
|
||||
| `SEARCH_WORKER_WINDOW_SIZE` | `search.workerWindowSize` | Gelesene Dokumente pro Fenster; Ranges pro Durchlauf ≈ Fenster / Range-Größe |
|
||||
| `SEARCH_WORKER_CONCURRENCY` | `search.workerConcurrency` | Parallele Jobs je Gruppe — ein Job ist eine Sammlung, dieselbe Sammlung läuft nie doppelt |
|
||||
| `SEARCH_WRITE_CONCURRENCY` | `search.writeConcurrency` | Parallele Mongo-Updates im Schreibschritt; der In-Memory-Index bleibt ein einzelner Schreiber |
|
||||
| `SEARCH_WORKER_DEBUG` | `search.workerDebug` | Kompaktes Import-Log: erster Batch, jeder zehnte Batch und jeder Batch über 5 s |
|
||||
|
||||
- **Warum das zusammenspielt.** Ein Fenster wird in Ranges zerlegt (eine Range = ein Embedding-Aufruf); die Ranges gehen per Work Sharing an die Mitglieder der Embedding-Gruppe. Fenster 100 + `vectorEmbedMaxTexts: 10` ergeben also ~10 Ranges und füllen auch vier parallele Endpoint-Slots, statt dass ein Mitglied die Arbeit allein macht.
|
||||
- **Empfehlung für einen Massenimport:** `workerWindowSize: 100`, `vectorEmbedMaxTexts: 10`, `writeConcurrency: 8`; `workerConcurrency` nur erhöhen (2–4), wenn der Import mehrere Sammlungen betrifft. Zusätzlich `EMBEDDING_GROUP_<NAME>_MAX_CONCURRENT_PER_ENDPOINT` (Default 2) anheben, wenn die Gegenstelle mehr parallele Anfragen wirklich schneller beantwortet — lokale `native`-Mitglieder bleiben bewusst bei 1.
|
||||
- **Grenzen.** Dieselbe (Namespace, Sammlung) läuft nie parallel, weil jeder Provider das ganze `_search`-Objekt schreibt; mehrere Sammlungen derselben Gruppe schon. Die Werte werden beim Start gelesen, nicht zur Laufzeit.
|
||||
- **Mitlesen beim Import:** `workerDebug: true` schreibt pro Batch eine Zeile wie `batch=120 docs=100 changed=97 updated=97 failed=0 errors=0 texts=100 ranges=10 members=2 read=41ms embed=1120ms write=185ms total=1346ms` — erster Batch, jeder zehnte und jeder Batch über 5 s, sonst nichts. Daraus liest du ab, ob die Embedder oder die Datenbank der Engpass sind.
|
||||
- **Prüfen:** `GET /_/:project/_/admin/search-worker/status` zeigt Queue-Tiefe, alle laufenden Jobs (`inFlightJobs`) und die Fortschrittszähler; `GET /api/v1/admin/embedding/status` zeigt die Treffer je Gruppen-Mitglied.
|
||||
|
||||
## Admin-Tokens
|
||||
@@ -241,4 +244,4 @@ api:
|
||||
|
||||
Weiter: [Betrieb und Beobachtung](/server/betrieb/) zeigt Profile und Metriken. [Sicherheit](/server/sicherheit/) erklärt Token-Arten und Ratelimit.
|
||||
|
||||
Verifiziert am d272041 2026-10-17 (tibi-server); Starter-Compose am e3f92eb 2026-10-14 (tibi-svelte-starter); Go-Version aus `go.mod`. Upload-Kaskade aus `internal/controller/collection.go` (resolveAllowedMimeTypes), Provider-/Gruppen-Env und `goldenPath` aus `internal/config/server.go`, Gruppen-Regeln aus `internal/config/embedding_group.go`, Prüfung/Quarantäne/Rückkehr/Timeouts aus `internal/embedding/{registry,probe,group}.go`, Pending-Verhalten aus `internal/utils/search.go`. Import-/Worker-Tuning am 3d052ae 2026-10-20 (tibi-server: `search.{vectorEmbedMaxTexts,workerWindowSize,workerConcurrency,writeConcurrency}` in `internal/config/server.go`, Verdrahtung in `cmd/server/main.go`, Sharding in `internal/utils/search.go`, Worker-Pool in `internal/models/search_worker.go`).
|
||||
Verifiziert am d272041 2026-10-17 (tibi-server); Starter-Compose am e3f92eb 2026-10-14 (tibi-svelte-starter); Go-Version aus `go.mod`. Upload-Kaskade aus `internal/controller/collection.go` (resolveAllowedMimeTypes), Provider-/Gruppen-Env und `goldenPath` aus `internal/config/server.go`, Gruppen-Regeln aus `internal/config/embedding_group.go`, Prüfung/Quarantäne/Rückkehr/Timeouts aus `internal/embedding/{registry,probe,group}.go`, Pending-Verhalten aus `internal/utils/search.go`. Import-/Worker-Tuning am 3d052ae 2026-10-20, Debug-Log und Panik-Absicherung am 197e6c0 2026-10-20 (tibi-server: `search.{vectorEmbedMaxTexts,workerWindowSize,workerConcurrency,writeConcurrency,workerDebug}` in `internal/config/server.go`, Verdrahtung in `cmd/server/main.go`, Sharding in `internal/utils/search.go`, Worker-Pool und Batch-Log in `internal/models/search_worker.go`, `EmbedSafe` in `internal/embedding/safe.go`).
|
||||
Reference in new issue
Block a user