Maintenance and Tuning |
System Administration entails planning, installation, setup and maintenance.
Maintenance consists of making sure that there is sufficient disk space on the ViewsFlash disks and that its data directories are backed up periodically. ViewsFlash will restart automatically and restore its state from its files as needed if the server is recycled.
ViewsFlash backups are kept, by default in a "backup" subdirectory of the main "data" directory. The servlet initialization parameter "backupdir" can be used to specify a different directory. If the backup directory is on a different volume, however, performance can degrade seriously.
When an error occurs, ViewsFlash sends an e-mail alert to the person identified in the Administration page and writes them to the ViewsFlash log. Both of these should be monitored constantly.
Tuning.
Monitor CPU utilization of each server to keep average under 75%. In a non-database configuration, the flushtime, flushvotes, flushsize servlet parameters should be fine-tuned until results under load are nearly real-time. In a database configuration, the storeflushtime, refreshresultstime and notificationinterval servlet parameters should be fine-tuned.
Monitoring API
Large installations use software monitoring and diagnostic tools to ascertain
application health. The ViewsFlash Monitoring API consists of a series of
HTTP commands that a monitoring application can send ViewsFlash and can then
ascertain application health by examining the response, as follows. Make
sure ViewsFlash is up and running on each machine before using this API!
Please test this API with your systems monitoring software carefully before
putting into production.
cmd=selftest
This will check that ViewsFlash has access to its data directory in either
read or read/write mode, depending on whether the ViewsFlash instance is
running as a satellite or a master.
cmd=selftest&masterul=1
In a satellite instance, this command will also check to see if the satellite
can reach the master servlet at the address indicated by the masterurl parameter.
The selftest command will return "OK" as the first two letters if the tests are successful. Otherwise, the first two letters will be "NG", and the rest of the line will indicate the cause of failure, as follows. The 4th and 5th character describe the error state, which can be interpreted accordingly. Note that NOT all error returns are fatal.
| Return Message | Meaning |
| NG,01, missing 'data' parameter on Master | Servlet unusable. Check the servlet parameters. |
| NG,02, cannot write data on Master | Servlet unusable. The 'data' directory cannot be written to. |
| NG,03, missing 'data' parameter on Satellite | Servlet unusable. Check the servlet parameters. |
| NG,04, cannot read data on Satellite | Servlet unusable. The 'data' directory cannot be read from. |
| NG,05, failed to connect to Master |
Danger condition. The satellite cannot communicate to the master. The condition should be remedied as quickly as possible. If it persists for a more than a few minutes, the satellite should be marked as temporarily unavailable, until the selftest command returns OK again. The satellite keeps trying to reach the master up to 100 times until the connection is restored. If possible, do not bring down the satellite while restoring the connection. This code requires that you include the masterurl=1 parameter in the command string. |
| NG,06, missing 'data' parameter | Servlet unusable. Check the servlet parameters. |
| NG,00, something's wrong | Unexpected condition. If an unexpected exception occurs during the self-test, it is reported here. It should be examined. The servlet should not be considered unusable just because this message appears. |