Especially after a large software update on multiple machines, there may be many thousands of reports from clients. The purpose of this section is to explain potential pitfalls related to such heavy load, and how to avoid them.
When displaying many thousands of reports in the message panel, the browser may need excessive memory, start swapping, and consequentially become more or less completely unresponsive.
To avoid this problem, you should configure a reasonable limit for 'Displayed messages' (the maximum number of messages shown in the message panel). The default value of '0' will show at most 1200 messages, which should be fine even for low-end (128 MB RAM) hardware. However, you should configure high limits only if you are sure that you have sufficient memory available.
In pre-2.0.6 versions, Displayed messages=0 would mean 'all messages', but this has been changed (see above) because it may become a deadly trap for the unwary ...
Updating many thousands of items in the baseline database(s) takes time. However, PHP imposes resource limits ("max_execution_time", "memory_limit") on scripts. Default limits are pretty low, and if the PHP script runs into these resource limits, it will be terminated prematurely, and the update will fail. To avoid this problem, it is recommended that you:
(a) configure generous limits
especially for the maximum execution time
in your system's the PHP configuration file
(php.ini),
(b) use the Bulk Update feature for large updates (optimized for performance), or
(c) sort messages by hostname before you run a large update directly from the message panel (select + update); sorting by hostname will allow beltane to optimize the update procedure.
![[Note]](stylesheet-images/note.png) | NOTE |
|---|---|
Beltane will try to set the maximum execution time to 3600 sec
(which is very conservative — see bechmarks below),
but this
may be ignored if safe mode on. You should still check your
|
To give you an idea about the resource usage of an update process, the following numbers are from a test on a somewhat aged PC.
System: 500 MHz Celeron, 128 MB RAM, 10 GB IDE disk, disk speed (hdparm -t device) 12 MB/sec, Debian 3.0; Linux 2.4.18, Apache 1.3.26, MySQL 3.23.58, PHP 4.3.4; Mozilla 1.6. All processes (Browser, Beltane, Apache, MySQL ...) running on the same machine, no other significant load except the X server (3 per cent CPU, 20 MB memory).
Updating 10146 entries in baseline database: execution time of PHP script 249 sec; memory (PHP script) 5.2MB at start, 6.2 MB at end; memory (beltane_update subprocess, not counted towards PHP resource limits) about 8 MB at end.
Due to the way MySQL optimizes queries, and the failure of pre-2.0.15 versions of Beltane to update the status of the server timestamps (log_ref greater zero), these entries cause problems. To fix this, you can do one of the following:
(a) manually set entry_status = 'ACK' for entries with log_ref > 0, and upgrade to beltane 2.0.15 or later, or
(b) disable logging of server timestamps for received messages to the database (see the entry in the Samhain FAQ).