nickva commented on issue #5342:
URL: https://github.com/apache/couchdb/issues/5342#issuecomment-2501965116
Thanks @aduchate.
Hmm, so far everything looks good.
`couch_index_updater:update/3` processes seem to be the most busy on the
cluster. But they seem to wait in 'do_call` so they are waiting on a response
from another process.
* Try to get `erlang:process_info(Pid, current_stacktrace).` along with
`erlang:process_info(Pid). ` for the stuck indexer, maybe the indexer updater
process as well.
* What about the `{progress,50}, {total_changes,1223768}, {type,indexer},
{updated_on,1732624464}` values on the stuck indexer, do they get updated
periodically? What about disk IO and CPU usage does it seems like anything is
being used significantly?
* Is it always the same db/index that gets stuck or it's always a random
one?
* `RUN git clone https://github.com/erlang/otp otp_src_27.1.2` we do
support and test with Erlang 27. However our package still ship with 25. Would
it be possible to see if 25 would act the same?
* Does running the QuickJS scanner show any discrepancies or crashes in
the logs against the cluster, specifically for the stuck indexes?
https://docs.couchdb.org/en/stable/best-practices/jsdevel.html#scanning-for-quickjs-incompatibilities
* Do indexes build with Spidermonkey engine? (ensure to restart the nodes
after toggling the config settings as in 3.4.2 the engine setting doesn't
update at runtime)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@couchdb.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
