release notes | Book: 1.9.5, 1.9.12 (opt, FHS), 2.7 (FHS), 2.8 (FHS), 2.9 (FHS), 2.10 (FHS), 2.11 (FHS), 2.12 (FHS), 2.13 (FHS), | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg
The billing database
Prev Chapter 15. The billing Service Next
The dCache Book > Configuration of dCache > The billing Service > The billing database

The billing database

In order to enable the database, the following steps must be taken.

  1. 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 srmdcache -U postgres billing

    If you are using a version of PostgreSQL prior to 8.4, you will also need to do: 

    [root] # createlang -U srmdcache 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).

  2. 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 to true and restart the domain in which the httpd service is running.

    Note

    Please take care to define the billing service before the httpd service in your layout file. If the billing service is defined in a separate domain, this domain should be defined before the domain in which the httpd 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

[return to top]

Customizing the database

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 chimera   Yes        Yes
namespaceDomain cleaner     chimera  localhost chimera   No         No
httpdDomain     billing     billing  localhost srmdcache 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 to 10000)
    • billing.db.inserts.timeout-before-commit (defaults to 5)

    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 to 100000)
    • billing.db.inserts.max-batch-size (defaults to 1000)

    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 to true)

    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 to org.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 the billing.db.driver and billing.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.

Prev Up Next
The billing log files Home Generating and Displaying Billing Plots