First let me address your issue and question.
The log analyzer uses an engine similar to the backup engine. It tries to parse the log file by breaking the process in many steps, each one being a separate page load. I believe that in both cases the process is interrupted because the server is blocking requests from your IP address because it believes that you are using too many resources. There is no solution for that. In the end of the day there is an absolute minimum of work which has to be performed, an atom of work if you want. If your server cannot process this absolute minimum amount of work when we are parsing the log file there's nothing we can do on our end.
Regarding the Configuration Wizard, it is designed to detect hard, deterministic limits imposed by the server. Resource usage-based IP blocking, which is what you're experiencing, is stochastic in its nature. The non-deterministic way Linux kernel, the virtualization layer and automatic resource usage-based IP blocking works on your server makes it impossible to reliably identify the exact conditions that cause an automatic IP block. Moreover, the same non-deterministic processes involved in getting this result make it impossible to reliably reverse the problem to a set of time settings which will definitely work on your server. The best way to deal with that is trying three different sets of timing options (max/min/bias): 10/1/75 (fast), 5/3/50 (slow-ish) and 3/5/50 (snail pace, the one you used). If neither works then you need a very experienced developer with a system administration background (me) to take a look.
Even though I could go on and on about this, I don't think it makes sense. If you want a taste of how complicated things are, when you are using a virtualization layer (all modern servers do) the rate at which you read files may cause memory exhaustion despite having a hard limit of the filesystem cache size because the garbage collection process which clears the RAM used by filesystem cache doesn't have the time to run. Even though that sounds like something straight out of Simon's (the infamous, fictional Bastard Operator From Hell) calendar I can assure you that it's totally true and took me a good half day to debug two months ago. In the end of the day adding a half second delay between backup steps and shortening the backup step length to under 5 seconds gave the damned server enough time to clean the filesystem cache and not run out of RAM while taking a backup. It also improved the performance of the server during the backup. That's the level of non-determinism we are talking about.
Now, regarding your complaint about tickets. I am always alarmed when I hear that our clients think that they didn't get adequate assistance, so I went looking through all your tickets from the past year. I can't find one which is closed without resolution. Every ticket of yours I read from the last year ends up with you telling us that the solution is accepted, or us telling you that your suggestion will be discussed (it was not a ticket about a problem) or me telling you to contact Watchful about an issue that was on their end (and they subsequently told me they fixed). If you have a ticket which you believe was closed in error please tell us. All the tickets automatically closed after 30 days of inactivity send you an email reading "This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us". Tell us which ticket you believe was closed in error so we can understand where the communication problem was.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!