Glossary
Programs:
- data-driven web pages: Pages that require database access to be generated.
Pages like the forums, or ones that contain statistics or client version information, etc.
are occasionally turned off (by hand) when the database is down.
- upload/download server: Handles workunit/task (result) transactions initiated by BOINC clients.
When a client requests a workunit, this server sends it out. When a client has
a result to send back, this server reads it and saves it to disk for later validation/assimilation/etc.
- scheduler: Determines what work is going to be sent to/received from requesting clients.
Clients go to the scheduler first to request work, and the scheduler tells the client what to get
and where to get it. If this is off, you cannot get any new work. After a client sends a result
back, it then contacts the scheduler which then marks it as received.
- feeder: Fills up the scheduler work queue with workunits ready to be sent.
The scheduler is usually too busy handling client transactions to maintain such a queue itself.
- transitioner: Handles state transitions of workunits and tasks (results).
Basically, the transitioners keep track of the tasks (results) in progress
and makes sure they properly move down the pipeline. It is always asking the
questions: Is this workunit ready to send out? Has this result been received
yet? Is this a valid result? Can we delete it now?
- file_deleter: Deletes input/output files when no longer needed (i.e. after assimilation).
This program keeps our upload/download disks as empty as possible.
- db_purge: Deletes result/workunit records when no longer needed (i.e. after the associated
files have been deleted). Depending on server load, we usually wait 7 days between the files have
been removed before purging the corresponding results so people can still view these results online
for a week after they've been processed/assimilated. This program keeps our BOINC database as small as possible
so that it fits in RAM (and therefore operates much faster).
- llpt_validator: Validates Lucas-Lehmer primality test results by comparing them with similar
results returned by other users. If enough results for the same workunit have
been returned, the validator compares the data, deems one result from the set the
"canonical" result, and issues credit to all responsible users accordingly.
- llpt_assimilator: Takes scientific data from validated results and
puts them in the Mersenne@home database for later analysis.
Hosts:
- mersenne: HP ProLiant DL380 G4 running Gentoo Linux
- 2x 3.2GHz Xeon
- 16GB RAM
- 2x GB NIC
- HP SmartArray 6400/w 512MB BBWC
- 2x 72.8GB 15kRpm in RAID1 for OS
- 4x 300GB 15kRpm in RAID10 for BOINC
Database/file status states:
- Tasks ready to send: For each workunit, results are generated
that are then sent out to individual users to be executed.
This is the number of excess results ready to be sent out, i.e. a backlog
in case demand exceeds the current rate of creation.
- Tasks in progress: Number of results currently being processed by clients.
- Workunits waiting for validation: The number of workunits that reached
quorum and are waiting to be validated.
- Workunits waiting for assimilation: The number of workunits waiting to
have data from their canonical task input into the master science database.
- Workunit/Files waiting for deletion: The number of files
which can be deleted from disk, as the workunit has been assimilated, and there is no
more use for it or its constituent results.
- Transitioner backlog: Amount of time that the transitioner is behind (i.e.
the age of the oldest task in the database waiting to be transitioned to another
state).
|
