BUG: Synchronization Issues #2681
Comments
|
More details about the WP-CLI issue. Full index runs into out of memory conditions after using more than 1.6 GB of memory. We switched to separate calls. Where posts are resumed: Now we see all posts in the index. Then we continue with the others: However, this index only has 1000 users instead of the added 278000 users. This is our staging environment. Once this issue is solved we will upgrade our production environment to the latest ElasticPress version. |
|
Hey @cbratschi, this is great debugging information, thank you very much. FWIW, instead of Some questions for you:
If you can add the content of this gist to your codebase, run a sync and then share your logs with us, that may give us some additional ideas of what could be the root cause of the problem. |
|
This issue has been automatically closed because there has been no response to our request for more information. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further. See this blog post on bug reports and the importance of repro steps for more information about the kind of information that may be helpful. |
|
We are using these plugins:
LiteSpeed Cache uses an Object Cache. I will share the debug logs later. Please reopen. I will wait for the next release to try WP-CLI again. |
|
This is the log of this endless sync cycle: |
|
Yeah, @cbratschi, that log indicates it is sending the same things over and over again. Did you already try to sync while having LiteSpeed Cache disabled? ps.: Issues marked as "reporter feedback" here in our repository are automatically closed after 3 days without a response from the creator but it'll automatically reopen if you come back after that time. |
|
@felipeelia did not yet try without LiteSpeed Cache but will run a sync soon again. |
|
@felipeelia I disabled LiteSpeed Cache and tried to sync it again. Several attempts failed without any output in the debug log. After reloading the sync page I got a full sync done. So it seems to be related to LiteSpeed Cache. What do you suggest? We could patch the LiteSpeed Cache plugin code to temporarily be disabled if a REST API call is ongoing. However, LiteSpeed Cache is very critical to our setup and we need a way to keep it running while performing a sync. |
|
@cbratschi, I tried to reproduce the problem in a local installation but I couldn't. Would it be possible for you to send us an export of your LiteSpeed settings? In the WP Dashboard that is available under LiteSpeed Cache -> Toolbox -> Export Settings. You can send it to us via the form at https://www.elasticpress.io/request-a-demo/. Here are some of the suggestions you may already try:
Can you give those a try and let us know, please? Thanks in advance! |
|
I just sent you the settings. Will try excluding AJAX now. Admins are already in the do not cache settings. |
|
Disable AJAX caching did not improve anything. |
|
Hey @cbratschi, I've tried locally with those settings and I'm still unable to reproduce the problem. While we keep investigating it, can you let me know if you have any other cache layer like Cloudflare or Varnish, for example? |
|
Hi @felipeelia, No, this is the only cache plugin running. |
|
We have the same issue. Endless the same message: We have no cache plugins available (we did use redis object cache before, but already deactivated it, because it would prevent elasticpress from working). |
|
The repeated message is something we are handling in #2737. Did you try via WP-CLI with the |
|
I got the same behaviour as well with the gui and the wp-cli tools. Sorry, didn't try it with the --show-errors flag. After multiple attempts (with deleting settings and the index in between, partly manually in the filesystem and phpmyadmin, because it sometimes wouldn't properly reset the index) it finally ran through without errors. We have a rather large website with 130.000 posts in production. I don't want to risk it again to reset it, but if it should occur again anytime I'll report back again. |
|
Same issue here on version 4.1.0 of the plugin and no caching plugins used. The indexing ran to 99% and got stuck somewhere toward the very end... doh, so close. What's weird is the indexing worked without issues before, but we've been making some changes and reindexed several times, until today when it got stuck. Edit: I tried to start and stop (ctrl-C) an index with wp cli, then loaded the web UI and saw this repeating several times a second. Looks like a buggy behavior: There should really be a way to stop wp-cli indexing properly without clearing the index. #2227. Update: Wait, |
|
Hey @archon810, thanks for the detailed report! We've recently changed a bit that error handling, the code for that is already merged and planned to be released in our next version. I've also just created a PR addressing a problem that might be affecting you as well. |
|
Sorry, this is a production env, and I'll wait for the official update with the fixes. Btw, I also wanted to point out the "Last Object ID: 5" in my first screenshot. That doesn't sound right. Edit: Is this what your new PR is addressing? |
|
I ran a full resync with wp cli and it finished this time. Here's the final output. This explains where ID 5 came from previously. Time elapsed doesn't seem to make any sense (as well as total time elapsed). This process ran for hours. |
|
Hi there! As the issues listed here were fixed by ElasticPress 4.2.0 I'm going ahead and closing this one out. If any of you face any issues with the latest release please open a new issue linking to this one. Thanks! |
ghost
mentioned this issue
Describe the bug
Synchronization using the new sync UI did not progress after a while without showing any errors. Using WP-CLI ended in out of memory conditions while indexing posts and failed afterwards in users too. So we split the command to use separate cycles for each indexable. However, this ended in users and terms to contain only 1000 documents.
I saw similar open issues but our issue is probably a little bit different. Therefore creating a new bug report to discuss further details.
Steps to Reproduce
Expected behavior
Should synchronize all indexables.
Screenshots
Environment information
Site Health Info:
Additional context
The text was updated successfully, but these errors were encountered: