<str name="maxCommitsToKeep">1</str>
For what this field is used . What happens if we increase the value of this key.Can someone help me on this.
Its part of the deletion policy.
The policy has sub-parameters for the maximum number of commits to keep (maxCommitsToKeep), the maximum number of optimized commits to keep (maxOptimizedCommitsToKeep), and the maximum age of any commit to keep (maxCommitAge).
<reopenReaders>true</reopenReaders>
<deletionPolicy class="solr.SolrDeletionPolicy">
<str name="maxCommitsToKeep">1</str>
<str name="maxOptimizedCommitsToKeep">0</str>
<str name="maxCommitAge">1DAY</str>
</deletionPolicy>
<infoStream>false</infoStream>
For more information, please check the documentation
Related
Lets say that I have replication on master Solr server configured like this:
<lst name="master">
<str name="enable">true</str>
<str name="replicateAfter">optimize</str>
<str name="confFiles">solrconfig.xml,schema.xml,stopwords.txt,synonyms.xml</str>
<str name="commitReserveDuration">00:00:10</str>
</lst>
and slave configured like this:
<lst name="slave">
<str name="enable">true</str>
<str name="masterUrl">masterSolr</str>
<str name="pollInterval">24:00:00</str>
</lst>
How slave knows that optimization was performed on master (master know nothing about slaves)?
Does slave checks it every 24 hours (not more often)?
Will replication be performed if there was no optimization but some several commits (on master)?
How to reach a state where slave will do the replication ONLY after optimization (nothing else) and will do it shortly after this optimization (we don't want to wait several hours)?
the replication is a pull mechanism - so to be able to support your scenario you need to do a bit of configuration.
For you questions:
1. it does not - it pulls in intervals (or forced) from master which tells what version is ready to be replicated
2. yes - 24 hours
3. only if an optimize have been done since the last index fetch
4. some configuration and knowledge from master to slave is needed.
You can use the postOptimize update event on the updatehandler to force a repication on slaves
<listener event="postOptimize" class="solr.RunExecutableListener">
<str name="exe">wget</str>
<str name="dir">solr/bin</str>
<bool name="wait">true</bool>
<arr name="args"> <str> http://slave_host:port/solr/core?/replication?command=fetchindex</str> </arr>
</listener>
you can then remove the poll interval from the slave config. you need to add multiple args (in str tags) for each slave
I am working on Datastax Cassandra with Apache Solr for multiple partial search.
Issue is, everytime I am getting only 10 rows even once I am doing count(*) query, I am able to check there are 1300 rows belong to particular query.
nandan#cqlsh:testo> select id from empo where solr_query = 'isd:9*';
id
--------------------------------------
5ee5fca6-6f48-11e6-8b77-86f30ca893d3
27e3e3bc-6f48-11e6-8b77-86f30ca893d3
f3156e76-6f47-11e6-8b77-86f30ca893d3
f315ac74-6f47-11e6-8b77-86f30ca893d3
f315bc82-6f47-11e6-8b77-86f30ca893d3
27e3058c-6f48-11e6-8b77-86f30ca893d3
4016eee4-6f47-11e6-8b77-86f30ca893d3
1bd33e34-6f47-11e6-8b77-86f30ca893d3
8f0a9168-6f47-11e6-8b77-86f30ca893d3
6669cc42-6f47-11e6-8b77-86f30ca893d3
(10 rows)
After searching few links, I make changes into solrconfig.xml file. and changes are as below.
<requestHandler class="solr.SearchHandler" default="true" name="search">
<!-- default values for query parameters can be specified, these
will be overridden by parameters in the request
-->
<lst name="defaults">
<int name="rows">1000000</int>
</lst>
<!-- SearchHandler for CQL Solr queries:
this handler doesn't support any additional components, only default parameters
-->
<requestHandler class="com.datastax.bdp.search.solr.handler.component.CqlSearchHandler" name="solr_query">
<lst name="defaults">
<int name="rows">1000000</int>
</lst>
</requestHandler>
But still I am getting same issue. Please let me know what will be the solution for this.
Thanks.
I don't think it should be managed from the schema. The query has a rows and a start parameter. Use those: rows defines the max number of items to return, start defines the first item in the list to return:
q=isd:9*&rows=22&start=17&wt=json
isd:9* returns all items where isd starts with 9.
start=17 says begin at the 18th item in the list.
rows=22 returns 22 items, from 18 to 40.
try this
select id from empo where solr_query = 'isd:9*' limit 1300;
this will give you all 1300 rows, by default solr limits the rows it return to 10.
We have an old Solr 3.6 server and replication is behaving very strangely.
Look at the image. It is like super slow. It says that the connection is slow, but actually that may not be true because even after several minutes the number of kb downloaded does not change at all.
Also it is wrong that you see a total download of 419 GB, that is the whole index but we are not not copying all of it.
I can see the "downloading File" gets to 100% in a second and then the rest is all waiting time. Even when it goes faster, the wait time is always around 120sec before the index moves to the next version.
It stays in this state sometimes for a long time (like 5 to 20 minutes) and then suddenly it is all done.
Sometimes it is quick instead.
We have a replication configuration like this:
<requestHandler name="/replication" class="solr.ReplicationHandler">
<lst name="master">
<str name="enable">${solr.master.enable:false}</str>
<str name="replicateAfter">startup</str>
<str name="replicateAfter">commit</str>
</lst>
<lst name="slave">
<str name="enable">${solr.slave.enable:false}</str>
<str name="masterUrl">http://10.20.16.125:8080/solr/replication</str>
<str name="pollInterval">00:00:60</str>
There are several possible causes that can lead to such issue:
java.lang.OutOfMemoryError happening during replication (in order to troubleshoot this kind of issue please refer to "How to deal with out of memory problems" in Apache Solr Cookbook);
A frequent segment merge that can be caused by:
optimization running after each commit;
wrong Merge Policy or Merge Factor;
As next step I advise to:
Verify in the Solr server log the presence of OutOfMemory or other interesting errors.
Verify how frequently the optimization is performed (do you have a trigger in your code?);
Lower the merge factor to 2 (<mergeFactor>**2**</mergeFactor>)
Try <useCompoundFile>true</useCompoundFile> that will tell Solr to use the compound index structure more and will thus reduce the number of files that create the index and the number of merges required.
Verify if there's some merge policy bug opened for your Solr/Lucene version.
Some additional interesting info can be found in this answer.
I recently started playing around with Apache Solr and currently trying to figure out the best way to benchmark the indexing of a corpus of XML documents. I am basically interested in the throughput (documents indexed/second) and index size on disk.
I am doing all this on Ubuntu.
Benchmarking Technique
* Run the following 5 times& get average total time taken *
Index documents [curl http://localhost:8983/solr/core/dataimport?command=full-import]
Get 'Time taken' name attribute from XML response when status is 'idle' [curl http://localhost:8983/solr/core/dataimport]
Get size of 'data/index' directory
Delete Index [curl http://localhost:8983/solr/core/update --data '<delete><query>*:*</query></delete>' -H 'Content-type:text/xml; charset=utf-8']
Commit [curl http://localhost:8983/solr/w5/update --data '<commit/>' -H 'Content-type:text/xml; charset=utf-8']
Re-index documents
Questions
I intend to calculate my throughput by dividing the number of documents indexed by average total time taken; is this fine?
Are there tools (like SolrMeter for query benchmarking) or standard scripts already available that I could use to achive my objectives? I do not want to re-invent the wheel...
Is my approach fine?
Is there an easier way of getting the index size as opposed to performing a 'du' on the data/index/ directory?
Where can I find information on how to interpret XML response attributes (see sample output below). For instance, I would want to know the difference between the QTime and Time taken values.
* XML Response Used to Get Throughput *
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">0</int>
</lst>
<lst name="initArgs">
<lst name="defaults">
<str name="config">w5-data-config.xml</str>
</lst>
</lst>
<str name="status">idle</str>
<str name="importResponse"/>
<lst name="statusMessages">
<str name="Total Requests made to DataSource">0</str>
<str name="Total Rows Fetched">3200</str>
<str name="Total Documents Skipped">0</str>
<str name="Full Dump Started">2012-12-11 14:06:19</str>
<str name="">Indexing completed. Added/Updated: 1600 documents. Deleted 0 documents.</str>
<str name="Total Documents Processed">1600</str>
<str name="Time taken">0:0:10.233</str>
</lst>
<str name="WARNING">This response format is experimental. It is likely to change in the future.</str>
</response>
To question 1:
I would suggest you should try to index more than 1 XML (with different dataset) file and compare the given results. Thats the way you will know if it´s ok to simply divide the taken time with your number of documents.
To question 2:
I didn´t find any of these tools, I did it by my own by developing a short Java application
To question 3:
Which approach you mean? I would link to my answer to question 1...
To question 4:
The size of the index folder gives you the correct size of the whole index, why don´t you want to use it?
To question 5:
The results you get in the posted XML is transfered through a XSL file. You can find it in the /bin/solr/conf/xslt folder. You can look up what the termes exactly means AND you can write your own XSL to display the results and informations.
Note: If you create a new XSL file, you have to change the settings in your solrconfig.xml. If you don´t want to make any changes, edit the existing file.
edit: I think the difference is, that the Qtime is the rounded value of the taken time value. There are only even numbers in Qtime.
Best regards
I am using solr to index about 40m items, and the final index file is about 20G. Below is the message after a delta import:
<lst name="statusMessages">
<str name="Time Elapsed">0:51:44.149</str>
<str name="Total Requests made to DataSource">1</str>
<str name="Total Rows Fetched">5634016</str>
<str name="Total Documents Skipped">0</str>
<str name="Full Dump Started">2012-09-27 01:25:17</str>
<str name="">
Indexing completed. Added/Updated: 5634016 documents. Deleted 0 documents.
</str>
I am wondering what solr is doing this status? and the message replication?command=details return is :
<lst name="masterDetails">
<str name="indexSize">36.69 GB</str>
The index is almost double, and is still going to be bigger. This made me very confused. I am doing delta import, why index will be double size when replace?
If you are replacing most of your documents that's normal. An update in lucene consists of a deletion and a re-insertion of the documents, since the index segments are write-once. When you delete a document, you are not really deleting it but only marking it as deleted, again because the segments are write-once.
Deleted documents will be deleted for real when the next merge happens, when a new bigger segments will be created out of the small segments that you have. That's when you should see a decreasement of the index size. That means that your index size shouldn't only increase. Merges happen more or less according to the merge policy in use. If you want to manually force a merge you can use the forceMerge operation, which is the new name for the optimize. Depending on the solr version in use you need to use either the first or the second one. Be careful, since the forceMerge takes a while if you have a lot of documents. Have a look at this article too.
Before Solr 3.6, dataImportHandler set optimize=true by default:
http://wiki.apache.org/solr/DataImportHandler
This triggers merging of all segments into one regardless of other settings. I think you might be able to address this by adding an optimize checkbox to debug.jsp, though I haven't actually tried it.