Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the CollectiveAccess support forum! Here the developers and community answer questions related to use of the software. Please include the following information in every new issue posted here:

  1. Version of the software that is used, along with browser and version

  2. If the issue pertains to Providence, Pawtucket or both

  3. What steps you’ve taken to try to resolve the issue

  4. Screenshots demonstrating the issue

  5. The relevant sections of your installation profile or configuration including the codes and settings defined for your local elements.


If your question pertains to data import or export, please also include:

  1. Data sample

  2. Your mapping


Answers may be delayed for posts that do not include sufficient information.

Rebuild search indexing errors on ElastichSearch and SqlSearch

Hello,
We use at the moment CA v. 1.6.2 - PROVIDENCE.

And we have some troubles about search indexing.

At the beginning we started to use ElasticSearch to search indexing but after big import of our data we have this errors (attached log file about CA and ElasticSearch)


...42.0% 146677/346729 ETC: 1 days, 4 hrs. Elapsed: 20 hrs, 59 mins [============>                  ]PHP Fatal error:  Uncaught exception 'Elasticsearch\Common\Exceptions\ServerErrorResponseException' with message '{"error":{"root_cause":[{"type":"illegal_index_shard_state_exception","reason":"CurrentState[RECOVERING] operations only allowed when shard state is one of [POST_RECOVERY, STARTED, RELOCATED]","index":"collectiveaccess","shard":"4"}],"type":"no_shard_available_action_exception","reason":"No shard available for [get [collectiveaccess][ca_objects][147267]: routing [null]]","caused_by":{"type":"illegal_index_shard_state_exception","reason":"CurrentState[RECOVERING] operations only allowed when shard state is one of [POST_RECOVERY, STARTED, RELOCATED]","index":"collectiveaccess","shard":"4"}},"status":503}'


We searched in forum if someone had this error but we didnt see it, so we decided to change search indexing first, and then to resolve that problem.

But now also with native search indexing (SqlSearch) we get mysql error after 84% of process (log error attached).


...84.0% 419689/499032 ETC: 3 hrs, 30 mins. Elapsed: 18 hrs, 35 mins [=========================>     ]PHP Warning:  Packets out of order. Expected 48 received 0. Packet size=5 in /data/www/html/cola/app/lib/core/Db/mysqli.php on line 292


We had this kind of error many time and every time that happened we resolved using solution described in some post of here, decreasing max_indexing_buffer_size (now we have max_indexing_buffer_size=50) in search.conf and increasing memory_limit (now we have memory_limit = 4096M) in /etc/php.ini

Can you help us?
Is this the correct way to increase so high memory in php.ini or we have to do other?


About our statistics we have:
- 499.026 objects
-  25.003 entities
-   8.248 places
-   1.762 occurrences
-  63.392 media

- 1.1748.089 attribute_values


DB Size: around 2 GB.

We attach also the printscreen of our configuration.


Thanks for your help

Luigi Montinaro
Csi Piemonte

Comments

  • Sorry, I've never seen these issues. I don't believe they are specific to CollectiveAccess.

    If you reindex using SqlSearch what happens?
  • Hi Seth,
    if we rebuild we obtain same error PHP Warning:  Packets out of order as you can see in log.

    This happened last time in an other test's server.
    And to solve problem in that server we had to increase memory_limit in php.ini and decrease max_indexing_buffer_size in app/conf/local/search.conf

    But now in this server (virtual server) we are already using maximum of RAM and then we suppose that our data base will improve more than 100% in next months.

    I will run an other time the rebuild from prompt's command, but we will wait maybe tomorrow to have the result because to finish it take time more than 18 hours.

    P.S. is it normal that duration is so long? and if we used ElasticSearch we had to wait more than 1 day to have the result (error result).
  • What version of PHP and MySQL are you running? The CA SqlSearch indexer uses compound INSERTs that could conceivably throw the "out of order" error. (That said I've never seen this error before – ever). 

    With regard to Elastic it's really hard to say what the issue is for sure without being on the system. The disk isn't full is it? There are many possible causes for those errors.

    The indexing time for a system depends on the speed of the system (particularly I/O performance), the indexer chosen, the nature of the data and the indexing configuration. More indexing = more time. For a system with ~600,000 records it's going to require hours... but a day seems high. Not impossible, but high.

    You may want to try updating to 1.7 and seeing how it works in that context. Use the latest GitHub develop code in your tests.

    seth
  • These are our version:

    PHP
    v: 5.6.25  (on Linux distro)
    MySQL v: 5.6.25  (on Linux distro)

    About Elastic, we did some months ago, so I dont remember now if disk was really full. I remember that I checked log error and I didnt see any error about disk space, but I will check.

    Instead for indexing we are using the attached search_indexing.conf (renamed search_indexing.txt to upload)
    We added some fields to index but we didnt suppose that this could be so high. And in future we will improve more than double db size.

    Yes, we want to update to 1.7, but before we was thinking first to fix our problems, and doubt and then do the upgrade.
    But now maybe it is better to do it soon.

    We will say to the group and then I'll tell you what will be our decision.

    Thanks a lot

    Luigi Montinaro
    Csi Piemonte
    CA - PROVIDENCE v. 1.6.2

    834 x 243 - 25K
    946 x 745 - 54K
Sign In or Register to comment.