Trying to create an FTS index to help with a text search on big text content, but the FTS index progress gets stuck at 66.79% always. Kindly help.
Couchbase version we use is - Enterprise Edition 6.0.3 build 2895 ‧ IPv4
Any other to help/suggestion to make a search for a text faster are also most welcome.
@Kannan_Muruganmony Logs collected via cbcollect_info can assist us in giving you a better answer.
They can be collected either from within the “Logs” tab on the UI or from the command line …
I’ve noticed the same problem. I’m using Couchbase 6.6 CE in a Docker container. FTS indexer seems to go down when there is few hundred inserts in short amount of time (peak in load?) and it never recovers automatically. I need to restart the container (so Couchbase process(es)) in order to make it work. Honestly it’s a serious problem if it’s not able to index incoming documents on the fly.
I can only assume limited resources (256MB RAM for the search service) are the reason.
Would you collect logs from your couchbase-server instance and share them here? We’ll be able to give you a better answer once we’ve looked into the logs.
Indeed, limited resource was the primary reason in the originally reported case here in this thread.
Search won’t work with 256MB RAM.
So, please make sure your have enough RAM/FTS RAM Quota (60-70% of RAM) and disk available in your docker containers depending on the amount of data indexed.
Always better if it’s a Search alone container to help resource sharing/stealing across services.
Thanks! So is it better to run many Couchbase containers (each with different service) instead of one that has all the resources available and running all the services at once? In both cases container(s) share the same amount of hardware resources so it shouldn’t make any difference to me. At least in this case.
When it comes to spreading the load across many servers - let’s say having 3 machines, each running a different Couchbase service within the same cluster then it makes sense.
One more question - how important is Index service when I’m using FTS (Search) index but through N1QL query? Should I set 50%/50% (Index/Search) or like 10%/90%?
I don’t entirely agree there. Even each individual container has resource limits set and those getting divided across multiple service processes can be saved if we end up running only a single service per container. Meaning no noise from other co running processes witin a container.
In other words, we can ensure that all the memory/cpu requested over the container config files are available to the single tenant service.
For eg:, FTS takes the benefits of any available file system cache from the operating system, and this could get compromised or challenged when other significant process are running in the system. eg: index/n1ql/kv etc within the same container. (My understanding is that - even page cache memory is accounted for the container’s overall memory usage by the container orchestrator platforms)
ref - https://docs.docker.com/config/containers/runmetrics/#metrics-from-cgroups-memory-cpu-block-io
With containers, page cache sharing across containers becomes tricky if different containers ends up accessing the same file on disk. But with CB services like N1QL/FTS/GSI chances are rare for that to happen. CB recommendations are container hostings are here - https://docs.couchbase.com/operator/2.0/best-practices.html#noisy-neighbors.
If you are using N1QL only for accessing FTS, then GSI/Index service isn’t even needed. You may disable that service itself.
Alright! I got the point now. Thanks for the support!
There is still one question left without an answer - do I need to run Index service if I run N1QL queries over Search index?
Cheers!