Size limit on the log file
The ax-admin script reads and processes the entire log file with each request. The entire log -- containing potentially tens of thousands of records -- is stored in memory while ax-admin runs.
There will come a point where the log file is so big, and processing it requires so many resources, that the ax-admin script will fail. It fails because the web server has time and resource limits that it enforces on all CGI child processes. ax-admin will exceed those limits for sufficiently large logs, and when that happens the web server will kill the script. The visitor will see either an "internal server error" message or will see a response from the script that stops in the middle of the page.
When this happens, the solutions are:
Delete the AXS log file (by default, /axs/log.txt) from the server. You may want to download a copy for your records before deleting it. You may need to create a zero-byte, script-writable log.txt file in place of the one you delete.
Or, you can change the resource limits in place on the web server. If you don't know how, you can contact your web hosting company and ask them to take care of it.
Or, you can stop running the resource-intensive ax-admin script on your web server, and run it on your local computer instead. To do this right, you'd need to have a Perl CGI-enabled web server running on your local computer. (The steps required to set that up are highly platform-dependent and are beyond the scope of this help file.) You then install AXS on both your server and your local computer. The server runs ax.pl to create the log.txt file. You then periodically download log.txt to your local computer and use ax-admin there to analyze the data.
This approach is more involved, but it has the advantage of freeing you to process larger logs without adversely impacting the web server.
How to know when log file size is the problem
The size of the log file at which this problem arises will be different on every host, due to differences in server power and configuration. Because of this, and because no meaningful error message is printed, it can be difficult to tell when log file size is the cause of a problem.
To determine whether log size is the problem, follow these steps:
First, connect to your web server with FTP.
Find the AXS log.txt. If it is small (less than 1MB), then this probably isn't the problem. Otherwise, rename "log.txt" to "log.bak".
Then create an empty "log.txt" with the same permissions as the previous one.
Then try to visit ax-admin in your web browser.
If ax-admin now works, then the problem was due to a log file that was too large.
Otherwise, if ax-admin continues to have problems, then the problem is not isolated to the log file size. In that case, you should delete the temporary empty "log.txt" that was just created, and rename "log.bak" back to its original name.
Future versions of AXS will be more efficient at reading large logs, and will print some meaningful warning message before being killed for violating a resource limit.
"Size limit on the log file" http://www.xav.com/scripts/axs/help/1001.html