smartbotic-database.service 2.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748
  1. [Unit]
  2. Description=Smartbotic Database Service
  3. After=network.target
  4. [Service]
  5. # v1.7.5: Type=notify so dependents block at startup until the service is
  6. # *actually* ready (recovery complete + migrations applied + gRPC listening),
  7. # not just "process spawned." Pre-1.7.5 this was Type=simple, which made
  8. # `After=smartbotic-database.service` on consumers ineffective: tools,
  9. # gateway, server etc. would launch immediately and silently fall back to
  10. # defaults when their startup DB reads timed out against an in-recovery
  11. # database. The service code already calls `sd_notify(READY=1)` at the
  12. # correct point in `service/src/main.cpp` after `service.start()`; with
  13. # Type=notify systemd actually waits for that signal before considering
  14. # the unit active and unblocking dependents.
  15. Type=notify
  16. NotifyAccess=main
  17. # v1.8.1: Cap glibc per-thread arenas to two. With Type=notify + threads
  18. # in eviction / WAL sync / snapshot / gRPC / replication, glibc allocates
  19. # `8 × num_cpus` arenas by default and small frees go on per-thread
  20. # free-lists that never `madvise(MADV_DONTNEED)`. On Zoe (22 threads) the
  21. # committed heap drifted 6.5 GB above the 5 GB the DB itself was tracking
  22. # — a fragmentation gap large enough to OOM-kill the process every ~3h
  23. # even though `estimatedMemoryBytes_` was correct. Two arenas is enough
  24. # for the writer + reader thread split; the small extra contention is
  25. # negligible vs. the RSS savings (measured 7.97 → 5.57 GB on Zoe).
  26. # Operators can override per-deployment by setting MALLOC_ARENA_MAX
  27. # elsewhere; the binary also calls `mallopt(M_ARENA_MAX, 2)` at startup
  28. # as a fallback for non-systemd deploys.
  29. Environment="MALLOC_ARENA_MAX=2"
  30. # Recovery on a large dataset (700k+ docs, multi-MB WAL) routinely takes
  31. # 60–90s. Default systemd start timeout (90s) is too tight; bump to 5 min.
  32. # The service emits `EXTEND_TIMEOUT_USEC=` during long recovery anyway, but
  33. # the static cap is the safety net.
  34. TimeoutStartSec=300
  35. User=smartbotic-db
  36. Group=smartbotic-db
  37. ExecStart=/usr/bin/smartbotic-database --config /etc/smartbotic-database/config.json
  38. WorkingDirectory=/var/lib/smartbotic-database
  39. Restart=on-failure
  40. RestartSec=3
  41. TimeoutStopSec=30
  42. LimitNOFILE=65536
  43. [Install]
  44. WantedBy=multi-user.target