In order to enable the database, the following steps must be taken.
If the billing database does not already exist (see further below on migrating from an existing one), create it (we assume PostgreSQL here):
[root] #
createdb -O dcache -U postgres billing
If you are using a version of PostgreSQL prior to 8.4, you will also need to do:
[root] #
createlang -U dcache plpgsql billing
No further manual preparation is needed, as the necessary tables, indices, functions and triggers will automatically be generated when you (re)start the domain with the billing database logging turned on (see below).
The property
billing.enable.db
controls whether the billing cell sends billing messages to the database. By default the option is disabled. To activate, set the value totrue
and restart the domain in which thehttpd
service is running.Note
Please take care to define the
billing
service before thehttpd
service in your layout file. If thebilling
service is defined in a separate domain, this domain should be defined before the domain in which thehttpd
service is running.Example:
Extract from the layout file:
[httpdDomain] billing.enable.db=true [httpdDomain/billing] [httpdDomain/httpd] ...
[root] #
dcache restart httpdDomain
Stopping httpdDomain 0 1 done Starting httpdDomain done
In most cases, the billing service will be run out-of-the-box; nevertheless, the administrator does have control, if this is desired, over the database configuration.
Database name, host, user, and password can be easily modified using the properties:
billing.db.name
billing.db.host
billing.db.user
billing.db.password
The current database values can be checked with the dcache database ls command.
Example:
# dcache database ls DOMAIN CELL DATABASE HOST USER MANAGEABLE AUTO namespaceDomain PnfsManager chimera localhost dcache Yes Yes namespaceDomain cleaner chimera localhost dcache No No httpdDomain billing billing localhost dcache Yes Yes
Database inserts are batched for performance. Since 2.8, improvements have been made to the way the billing service handles these inserts. As a consequence, the older in-memory caching threshold properties are now obsolete:
billing.db.inserts.max-before-commit
(defaults to10000
)billing.db.inserts.timeout-before-commit
(defaults to5
)
Inserts can now be tuned by adjusting the queue sizes (there are four of them, each mapped to the four main tables: billinginfo, storageinfo, doorinfo, hitinfo), and the maximum database batch size.
billing.db.inserts.max-queue-size
(defaults to100000
)billing.db.inserts.max-batch-size
(defaults to1000
)
There is further the option as to whether to drop messages (default is true) or block when the queue maximum is exceeded.
billing.db.inserts.drop-messages-at-limit
(defaults totrue
)
The property which sets the delegate class is merely there for potentially future use; currently there is only one option.
billing.db.inserts.queue-delegate.type
(defaults toorg.dcache.services.billing.db.impl.DirectQueueDelegate
)
The default settings should usually be sufficient.
You can now obtain statistics (printed to the billing log and pinboard) via the dcache admin command: display insert statistics <on/off> command. Activating this command logs the following once a minute:
Example:
insert queue (last 0, current 0, change 0/minute) commits (last 0, current 0, change 0/minute) dropped (last 0, current 0, change 0/minute) total memory 505282560; free memory 482253512
"insert queue" refers to how many messages actually were put on the queue; "commits" are the number of messages committed to the database; "dropped" are the number of lost messages. "last" refers to the figures at the last iteration. For insert queue, this is the actual size of the queue; for commits and dropped, these are cumulative totals.
You can also generate a Java thread dump by issuing the "dump threads" command.
Should finer control over the DataNucleus layer (which talks to the database) be needed, then a new
datanucleus.properties
file must be provided. The path to this file, which will override the internal settings, should be indicated using:billing.db.config.path
(defaults to""
)
Changing this configuration requires an understanding of DataNucleus , and we expect it will be rather uncommon to utilize this option (it is suggested that the administrator in this case consult with a member of the dCache team).
Changing the database type (which defaults to PostgreSQL) to something else would entail the above-mentioned necessary modification of the
datanucleus.properties
as well as changing thebilling.db.driver
andbilling.db.url
properties appropriately. This is not a recommended procedure, though in certain exceptional circumstances, it may be desirable or necessary. Once again, consultation with the dCache team is suggested in this case.