Comparing 4.1.1-EE (Version: 4.1.1-5914 Enterprise Edition (build-5914)) with 4.1.0 (Version: 4.1.0-5005 Enterprise Edition (build-5005)) on 3-node cluster (same application code is used). For design docs (for one bucket only) on both clusters buckets {“updateMinChanges”:1,“replicaUpdateMinChanges”:1} are set + “updateInterval”:1000 (globally). Indexed bucket has 2 DD (first DD with 1 view, second DD with 2 views). Total document count is less then 1000, insertion rate is less then 10 docs per second. Value eviction mode is used.
Problem: 4.1.0-EE works normal while indexing; 4.1.1-EE is just unable to index fast enough => application tests show errors; output shows that view call returning not all results it should (comparing to same tests for 4.1.0). Even “sitting and watching ‘views’ web-interface page”, i see “indexing …%” is slooooow on 4.1.1; and “almost don’t see ‘indexing %’ on 4.1.0” during applications tests.
Error.log and indexer.log both have no error messages
Assumption: 4.1.1-EE indexer is broken. IMHO, seriously broken.
Has anyone got same results ?
UPDATE: further testing with different hardware configurations shows that the real cause is that 4.1.1-indexer probably consumes more memory, or uses completely different algorithm than 4.1.0-indexer; so it’s not a bug.
UPDATE2: IMHO, something terribly wrong was made with 4.1.1’s indexer. 4.1.0 allowed to fit 2 buckets within 1GB RAM and indexer worked very fast. 4.1.1 shows “periodical indexation slowing” even with 2GB RAM. “Minimal official requirement” of 4GB makes indexer work well. Well, “officialism rules”, ok, no problem, that’s the real life is.
P.S. But maybe, there are some developers, who would like to ask themselves “what have we really done with indexer service between 4.1.0 and 4.1.1 ?”…
UPDATE3: varying number of cpus 1…4 also allows to boost up indexer, but the problem completely solved only for 4VCPU + 4GB RAM. So sad 1VCPU + 1GB RAM was enough for 4.1.0