Hi everyone Given that I am not an expert, I am doing tests with Solr, I installed following the guide but I have no benefits on the search, the search on the body on 28000 mails takes a few minutes and then goes to timeout. I had installed version 8.2.0 of solr then I thought that there is something not compatible with centos 7 so I installed version 7.7.0 as an example on the guide https://wiki2.dovecot.org/Plugins/FTS/Solr. I did several tests but I can't get it to work, this is the test server link: http://5.39.2.59:8987/solr/#/ I only changed the door because the 8983 is busy even making a query from the panel it seems to me not working .... thanks to all Bic
On 8/5/2019 12:02 PM, HTMLServices.it via dovecot wrote:
Given that I am not an expert, I am doing tests with Solr, I installed following the guide but I have no benefits on the search, the search on the body on 28000 mails takes a few minutes and then goes to timeout.
If the problems you're having are with Solr itself and not fts_solr, then the Solr mailing list or IRC channel is probably a better place to get help.
https://lucene.apache.org/solr/community.html#mailing-lists-irc
The following info, combined with your document count of 28000, will be very useful:
https://cwiki.apache.org/confluence/display/solr/SolrPerformanceProblems#Sol...
When gathering the screenshot, be sure that the process listing is sorted as described.
With no other info to go on, I suspect that maybe your Solr install is still configured with a 512MB heap and that the heap size needs to be increased to handle the index you've built.
I did several tests but I can't get it to work, this is the test server link: http://5.39.2.59:8987/solr/#/
If you have configured fts_solr with a URL that contains a # character, it's never going to work. URLs containing # are only usable in a browser and will not function correctly anywhere else.
Thanks, Shawn
Thanks Shawn for your reply I tried to bring the heap size to 5gb as you would like, but the problem was not solved. "/If you have configured fts_solr with a URL that contains a # character, it's never going to work./" I'm not sure how to configure this but in the 90-plugins.conf file I configured this:
plugin { #setting_name = value fts = solr fts_solr = url = http://5.39.2.59: 8987/solr/dovecot/ }
In the 10-mail.conf file I added this as a guide:
# Space separated list of plugins to load for all services. Plugins specific to # IMAP, LDA, etc. are added to this list in their own .conf files. mail_plugins = $ mail_plugins fts fts_solr
if I run one of these two commands as a guide curl http://5.39.2.59:8987/solr/dovecot/update?optimize=true curl http://5.39.2.59:8987/solr/dovecot/update?commit=true I get
<? xml version = "1.0" encoding = "UTF-8"?>
<Response> <lst name = "responseHeader"> <int name = "status"> 0 </int> <int name = "QTime"> 2 </int> </ Lst> </ Response>
this is right? have I forgotten or am I wrong? If you have time to see or try any queries, I have access to http://5.39.2.59:8987/solr/#/ without a password. thanks for your time!
Il 06/08/2019 23:30, Shawn Heisey via dovecot ha scritto:
On 8/5/2019 12:02 PM, HTMLServices.it via dovecot wrote:
Given that I am not an expert, I am doing tests with Solr, I installed following the guide but I have no benefits on the search, the search on the body on 28000 mails takes a few minutes and then goes to timeout.
If the problems you're having are with Solr itself and not fts_solr, then the Solr mailing list or IRC channel is probably a better place to get help.
https://lucene.apache.org/solr/community.html#mailing-lists-irc
The following info, combined with your document count of 28000, will be very useful:
https://cwiki.apache.org/confluence/display/solr/SolrPerformanceProblems#Sol...
When gathering the screenshot, be sure that the process listing is sorted as described.
With no other info to go on, I suspect that maybe your Solr install is still configured with a 512MB heap and that the heap size needs to be increased to handle the index you've built.
I did several tests but I can't get it to work, this is the test server link: http://5.39.2.59:8987/solr/#/
If you have configured fts_solr with a URL that contains a # character, it's never going to work. URLs containing # are only usable in a browser and will not function correctly anywhere else.
Thanks, Shawn
On 8/7/2019 4:23 AM, HTMLServices.it via dovecot wrote:
Thanks Shawn for your reply I tried to bring the heap size to 5gb as you would like, but the problem was not solved.
That machine only has 4GB of total memory, so setting the heap to 5GB will eventually be problematic and lead to major performance issues. If I were doing this with that hardware, I would set the heap to 1GB to start and maybe go as high as 2 GB. With only 28000 documents, this *should* be enough.
"/If you have configured fts_solr with a URL that contains a # character, it's never going to work./" I'm not sure how to configure this but in the 90-plugins.conf file I configured this:
plugin { #setting_name = value fts = solr fts_solr = url = http://5.39.2.59: 8987/solr/dovecot/ }
That URL looks good. It doesn't have the # character, and from what I can see, should be completely correct.
Note that you should restrict access to the Solr server, not allow the Internet to reach it. With it publicly accessible, anyone can delete the entire index or issue queries that cause denial of service. I was able to connect to it, and I can see that your Solr index has no data in it:
https://www.dropbox.com/s/9bsx2vfu3kab19j/dovecot-solr-user-issue-screenshot...
I don't know if it's empty because nothing ever got indexed, or if it's empty because somebody found the URL for your server on this mailing list and decided to delete your index.
If I attempt a query on your index, it fails, complaining that there is no _text_ field:
http://5.39.2.59:8987/solr/dovecot/select?q=hello
The solrconfig.xml file that is in the dovecot source should be setting the df parameter to a field that exists, perhaps "body". The field that it is using does not exist in the schema that is also in the dovecot source.
It might be that when fts_solr issues queries, it qualifies everything to search specific fields. If that's what it does, then this configuration issue would not break fts_solr in the wild.
Thanks, Shawn
participants (2)
-
HTMLServices.it
-
Shawn Heisey