Some tricks¶
Increasing the debug level¶
By default, the logging level of AiiDA is minimal to avoid filling logfiles. Only warnings and errors are logged to the daemon log files, while info and debug messages are discarded.
If you are experiencing a problem, you can change the default minimum logging level of AiiDA messages:
verdi config logging.aiida_loglevel DEBUG
You might also be interested in circus log messages (the circus
library is the daemonizer that manages the daemon runners) but most often it is used by AiiDA developers:
verdi config logging.circus_loglevel DEBUG
For each profile that runs a daemon, there will be two unique logfiles, one for
AiiDA log messages (named aiida-<profile_name>.log
) and one for the circus logs (named circus-<profile_name>.log
). Those files can be found
in the ~/.aiida/daemon/log
folder.
After rebooting the daemon (verdi daemon restart
), the number of messages
logged will increase significantly and may help in understanding
the source of the problem.
Note
In the command above, you can use a different level than DEBUG
.
The list of the levels and their order is the same of the standard python
logging module.
In addition to the standard logging levels, we define our custom REPORT
level,
which, with a value of 23
, sits between the standard INFO
and WARNING
levels. The REPORT
level is the default logging level as this is what is used
by messages from, among other things, the work chain report..
When the problem is solved, we suggest to bring back the default logging level, using the two commands:
verdi config logging.circus_loglevel --unset
verdi config logging.aiida_loglevel --unset
to avoid to fill the logfiles.
The config options set for the current profile can be viewed using:
verdi profile show
in the options
row.
Tips to ease the life of the hard drive (for large databases)¶
Those tips are useful when your database is very large, i.e. several hundreds of thousands of nodes or more. With such large databases the hard drive may be constantly working and the computer slowed down a lot. Below are some solutions to take care of the most typical reasons.
Repository backup¶
The backup of the repository takes an extensively long time if it is done through a standard rsync or backup software, since it contains as many folders as the number of nodes (and each folder can contain many files!). A solution is to use instead the incremental backup described in the repository backup section.
mlocate cron job¶
Under typical Linux distributions, there is a cron job (called
updatedb.mlocate
) running every day to update a database of files and
folders – this is to be used by the locate
command. This might become
problematic since the repository contains many folders and
will be scanned everyday. The net effect is a hard drive almost constantly
working.
To avoid this issue, edit as root the file /etc/updatedb.conf
and put in PRUNEPATHS
the name of the repository folder.