0

I am hoping to get some tips for troubleshooting this annoying timeout issue.

Configuration:

  • Windows 2012 R2 with IIS
  • PHP 7.3
  • MySQL 5.7
  • Wordpress.org 5.3.2
  • WP is configured as network with 5 sites using subdomains

Publishing client: OpenLiveWriter 0.6.2.0

The symptom is that after working with the XMLRPC interface, maybe about 20 publishes along with maybe twice as many listings of existing posts, OpenLiveWriter will time out and fail with the "Unable to connect to remote server" message.

If I wait a period of time (in hours), I can continue my work until it begins timing out again, then I have to wait again. Sometimes without waiting too long, I can manage to list 50 posts from the blog, but trying to list 100 posts will cause it to time out. Trying to open a post will cause the same. To me, this seems like a memory leak that gets flushed out over time. The more time you allow, the more you can get done until it fills up again.

The problem is, I can't find out how to clear this memory on my own. IISRESET doesn't do it. Stopping and restarting MySQL doesn't do it. Task Manager doesn't show any excessive CPU or memory usage during the unavailability. IIS logs don't show any abnormal requests that might suggest an attack. To be certain, I IP-filtered xmlrpc.php to only my IP address. This has not changed the behavior. WP and PHP logs show no errors. All blogs can be browsed while the XMLRPC is unavailable.

I have full access to the server and these blogs are in migration, so I can take some drastic measures if needed, but I'd rather not lose the effort I have put in migrating the hundreds of posts so far.

Let me know how you would troubleshoot this. Maybe a recommendation for a different publishing client?

Thanks for your insights!

Improve this question
2
  • Additional information request. RAM size, # cores, any SSD devices on MySQL Host server? Post on pastebin.com and share the links. A) complete (not edited) my.cnf or my.ini A2) post your complete php.ini From SSH login root, Text results of: B) SHOW GLOBAL STATUS; after minimum 24 hours UPTIME C) SHOW GLOBAL VARIABLES; D) SHOW FULL PROCESSLIST; E) complete MySQLTuner report url for Windows version - github.com/pmachapman F) SHOW ENGINE INNODB STATUS; for server workload tuning analysis to provide suggestions.
    – Wilson Hauck
    Commented Dec 28, 2019 at 21:28
  • Any chance you can post the additional information requested Dec 28, 2019 ?
    – Wilson Hauck
    Commented Mar 6, 2020 at 18:46

1 Answer 1

Reset to default
0

I was able to greatly reduce the severity of the problem by installing/activating the PHP extension file-info, which was flagged by WordPress as a configuration issue. While it didn't eliminate the issue completely, the lockup only happened once more during my post migration and the unavailability was much shorter than previous occurrences.

Now that the migration is complete, I don't ever expect to make so many edits to posts in the future, so I doubt I will see this problem again.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.