Issue: VaultWiki hogs CPU on IIS 10, making forum unusable

You should check your server's access logs to see whether there are unusual duplicate requests that would be spinning up extra PHP instances.

If it appears to be a deferred task (deferred.php), you may have a huge backlog of incomplete tasks in the vw_defer table, or you may have a task which is stuck in a loop. Check the table for entries that have completed = 0 for clues.

If it is a different request that is duplicating, we will have to consider that on a case-by-case basis.
Once you know what request is causing the issue, it may require a ticket to investigate further or to repair the installation: https://www.vaultwiki.org/members/?do=newticket

I currently cannot see anything suspicious in the access logs. vw_defer contains two entries with "completed = 0", both denoted as "import". Another clue might be that it primarily starts happening in the evening, when more people are active on our forums...

I've been searching but I don't see a way that VaultWiki would be able to generate new PHP instances recursively (without suspicious requests), either on its own or if told to access a malicious third-party server that loops the request back. The maximum number of recursive requests possible from what I can see is 2 (on the second request it would hit a lock that was created in the first request, which was designed to prevent this kind of problem).

If you can cross reference the PHP process logs at the time of the slow downs (looking for processes that time out) with your access logs at the same time, you may be able to determine what requests are leading to an issue, or at least narrow it down. The request state will give us some idea what functions are being used that might be problematic.

If the PHP processes are never timing out, then you will want to first adjust your PHP configuration so that you have a reasonable timeout like 15-30 seconds (at least for PHP that the public can access -- since you may not want such a limit for command-line PHP). Also, since your server's CPU hits 99% with the number of processes being created, you will want to adjust your config to reduce the maximum number of PHP processes to an amount that the server can handle (such as by dividing the max amount of RAM you want to dedicate to PHP -- less than the amount your server actually has -- by the max amount of RAM you want each request to be able to use). Once you have these limits in place, it will be possible to troubleshoot the underlying problem without causing so many other issues.

If this CPU spike occurs starting at the moment VW is enabled (or disabled) and then subsides until it is enabled/disabled again, then you may be experiencing this known issue which is a design flaw in XenForo: https://xenforo.com/community/thread...idated.172164/

Since VaultWiki has a large number of templates and phrases, the add-on rebuild process would take longer, resulting in a longer period of constant re-invalidations by XenForo. As discussed in the XenForo bug report, it could be resolved by only invalidating the caches at the end of the entire add-on rebuild process.

Nice guess, but that's not it. It happens when the add-on is "silently" running in the background (as it should in regular production). I'll try to fetch some more information - unfortunately it's rather hard to fetch that when the entire server becomes unresponsible.

Since there has been no further update to this in over six months, I'm going to assume my server-tuning suggestions made a positive impact on the issue. Closing this issue.

Unfortunately not, I simply had to stop using VaultWiki. But thank you for your efforts!

Another idea, could be related to this XF2 bug: https://xenforo.com/community/thread...tances.183693/
Since VaultWiki is cron-job heavy (multiple new batch jobs every 5 minutes), using VaultWiki dramatically increases the likelihood of triggering XenForo's infinite loop bug. The bug was fixed in XenForo 2.2.0 Beta 2. You may wish to test.

Even so, my server tuning suggestions earlier would likely have reduced the impact of this bug, if you are using only activity-based cron with no CLI cron.