See Software Requirements for details.
The hardware requirements for Open XDMoD depend on how many concurrent users you have and how much data you have. You’ll need roughly 300MB of disk space per 1 Million jobs on your MySQL server.
It is possible, but you must have PHP 5.3 installed.
Open XDMoD should work with MySQL 5.0, but it hasn’t been tested extensively, so we recommend MySQL 5.1 or 5.5.
If you are experiencing long ingestion times make sure that you have tuned MySQL properly. See Optimizing the MySQL Server for more details.
Here is an example of some server parameters that you can change. Be sure to understand any changes you make to your MySQL server configuration.
[mysqld] key_buffer_size = 1G sort_buffer_size = 8M read_buffer_size = 4M join_buffer_size = 16M innodb_buffer_pool_size = 64M max_allowed_packet = 16M tmp_table_size = 1G max_heap_table_size = 128M thread_stack = 256K thread_cache_size = 8 query_cache_limit = 16M query_cache_size = 1G group_concat_max_len = 16M
Non-root URLs are not supported at this time.
See HOWTO Change Summary Page Charts for details.
Just repeat the process found here with the new user names.
If you think the job data in your Open XDMoD database is corrupted, you may want to delete your job data and start over. To do so, use this command:
$ xdmod-admin --truncate --jobs
Running this command will truncate all the tables containing job data and you can then re-shred and re-ingest your resource manager data.
You need to set your timezone in your
php.ini file. Add the
following, but substitute your timezone:
date.timezone = America/New_York
The PHP website contains the full list of supported timezones.
This indicates that you are using a resource attribute that Open XDMoD does not recognize. This isn’t a problem and can be safely ignored.
You have binary logging enabled, but the user you
specified to create the Open XDMoD databases doesn’t have the
privilege. You should either disable binary logging (assuming you don’t
need it) or grant the
SUPER privilege to the user that
will create the databases. You may also use the less safe
Resource manager account log records may be missing some job data under certain circumstances. It is expected that a job record will have a start time, end time and wall time. If one of these is missing it will be calculated using the other two. If two or more are missing the error message in question will be displayed along with the values that were present in the job record. In addition to this error message a file will be produced at the end of the shredding process containing the job record that produced the error along with additional details. Look for the log message “Job errors written to …”.
One example of a situation that will produce this error is that some resource managers record a 0 start time in their accounting logs when a job is canceled before the job started. It is also possible that other errors occurred to produce these values so they are not ignored and this error message is produced. As of Open XDMoD 7.0 any job with a start or end time equal to 0 will not be ingested into the data warehouse and will not contribute to the job count or any other metrics. Previous versions of Open XDMoD did include these jobs which resulted in inaccurate results.
This indicates that the data needed by the new ACL system introduced in 7.0.0 is
not present. This is typically caused by failing to migrate the Open XDMoD
database from 6.6.0 to 7.0.0. The
xdmod-upgrade script must be executed
after upgrading the Open XDMoD RPM or source installation.
These errors include:
SQLSTATE[HY000]: General error: 1364 Field ... doesn't have a default value
SQLSTATE[HY000]: General error: 1366 Incorrect integer value: ''
If you see either of these errors, you should check your
Server SQL Modes. Open XDMoD does not support any of the strict
Server SQL Modes. You must set
sql_mode = '' in your MySQL server
This indicates that the script was run previously but most likely exited before
completion. One way to resolve this error is to provide the
acl-config. This will direct
acl-config to utilize these backup tables
to recover the User to Acl relations.
This indicates that the
--recover flag was present when calling
but there were no backup tables found to recover from. Remove the