That would potentially mean a _lot_ of info coming out in the logs, I
know of 40M documents that have been sent for instance. I typically
batch 1,000 docs per update request, that'd mean dumping all of them.
The Solr logs should have the update request in close proximity to the
slow query message, and one of the bits of data dumped is the first 10
ids of the docs being updated along with the batch size. The last
number in the update log message is the time taken which should
correlate to 1736 in your example. That's what I usually use to try to
track updates down.
And if you're indexing 10,000 docs per batch this might be perfectly
reasonable...
Best,
Erick
On Wed, Nov 29, 2017 at 9:29 AM, S G <sg.online.em...@gmail.com> wrote:
> Hi,
>
> Our logs are spewing a lot of the following:
>
> org.apache.solr.core.SolrCore; slow: [my_coll_shard8_replica1]
> webapp=/solr path=/update params={wt=javabin&version=2} status=0 QTime=1736
>
> And the QTime is as high as 3-4 seconds in some cases.
>
> Shouldn't the slow logger print the document also which took so long?
> The /select query and /get query handlers do a good job of helping in such
> cases as the entire URL is present there (I know its GET vs POST thing).
> But we should probably print the POST request's payload for /update
> requests to debug more?
>
> Thanks
> SG
