Hi Christine,
Thanks for the response and the suggestion. This turned out to be quite a
deep rabbit hole, but the following shows times for versions between 6.6
and 9.5.
Each row below gives the version followed by two times for the partial
update of the 25 documents listed in my original post,
Hi Michael,
Thanks for your thoughts. In Solr 6, we were using `indexed="true"
stored="false" docValues="true"`, and it was slower than I would have liked
but roughly the same whether stored was false or true (about 2s in either
case under 6.6.6).
Here's a representative `newEntry` stack trace
Hi Rahul,
Thanks for the suggestion. I was using `solr.NRTCachingDirectoryFactory` in
all the versions I've tested, which was the default in the example
solrconfig:
I'll give `solr.MMapDirectoryFactory` a try later though.
Thanks,
Calvin
p.s. Christine, I am following up on your
Also, you don't explicitly mention, but just to be sure: in your Solr
6 deployment, were the `playlist_index_*` fields stored? Some degree
of performance difference between stored=true/false is expected,
because retrieving dynamic fields with many field names is definitely
problematic for
It might be worth looking at this issue:
https://issues.apache.org/jira/browse/SOLR-16989
The irony is that this issue was supposed to help with slowness in
cases similar to what you describe. Can you send a full stack trace
for a representative call to
`DocValuesIteratorCache.newEntry(String)`?
Did you happen to change the DirectoryFactory in solrconfig to
SimpleFSDirectoryFactory or NIOFSDirecotryFactory by any chance? Default is
Mmap which is much more performant for atomic updates (and also practical,
especially given the small(ish) size of your index).
-Rahul
On Tue, Feb 20, 2024
Hi solr users,
While tracking down a severe performance regression doing partial updates
when upgrading from Solr 6 to solr 9.5.0, I discovered the following
unexpected behavior.
In my schema.xml file, I have the following fields (among many others):
The unexpected impact on partial
