[ 
https://issues.apache.org/jira/browse/SOLR-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13670090#comment-13670090
 ] 

Aditya commented on SOLR-4802:
------------------------------

I am not sure if this issue is active. But we recently had an incident where we 
had to rollback to 3.5 on Production. There is seriously some issue with High 
memory utilization in Solr with large multivalued field when retrieved. 
Fetching large size multivalued field is causing System being unresponsive and 
then eventually throw OOM. 

I will try collect more data and update the Issue. Planning to raise a ticket 
with Lucid Works

                
> Atomic Updated for large documents is very slow and at some point Server 
> stops responding. 
> -------------------------------------------------------------------------------------------
>
>                 Key: SOLR-4802
>                 URL: https://issues.apache.org/jira/browse/SOLR-4802
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.2.1
>         Environment: Jboss 5.1 with Solr 4.2.1 and JDk 1.6.0_33u
>            Reporter: Aditya
>            Priority: Critical
>
> I am updating three fields in the document which are of type long and float. 
> This is an atomic update. Updating around 30K doucments and i always get 
> stuck after 80%.
> Update 200 docs per request in a thread and i execute 5 such thread in 
> parallel. 
> The current work around is that i have auto-commit setup for 10000 docs with 
> openSearcher = false.
> i guess that this is related to SOLR-4589
> Some additional information 
> the machine is 6core with 5GB Heap. ramBuffer=1024MB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to