Linuxdoc Linux Questions
Click here to ask our community of linux experts!
Custom Search

10. Monitoring and administration

Once the Usenet News system is in place and running, the news administrator is then aided in monitoring the system by various reports generated by it. Also, he needs to make regular checks in specific directories and files to ascertain the smooth working of the system.

10.1. The newsdaily report

This report is generated by the script newsdaily which is typically run through cron. I shall enumerate some of the problems that are reported by it, based on my observations .

  • bad input batches: This gives a list of articles that have been declared bad after processing and hence have not been digested. The reason for this is not given. You are expected to check each article and determine the cause.

  • leading unknown newsgroups by articles: Newsgroup names that do not appear in the active file but their hierarchy has been subscribed to, would find their names mentioned under this heading. Choose to add the name in the active file if you think it is important. For e.g., you would see this happen if you have subscribed to the hierarchy comp but the active does not contain the newsgroup name You could deny subscription to this particular newsgroup by specifying so in the sys file.

  • leading unsubscribed newsgroups: If the news server receives maximum articles of a particular newsgroup hierarchy to which you haven't subscribed, it will appear under this heading. You really cannot do much about this except to subscribe to them if they are required.

  • leading sites sending bad headers: This will list your NDNs who are sending articles with malformed/insufficient headers.

  • leading sites sending stale/future/misdated news: This will list your NDNs who are sending you articles that are older than the date you have specified for accepting feeds.

  • Some of the reports generated by us: We have modified the newsdaily script to include some more statistics.

    • disk usage: This reports the size in bytes of the $NEWSARTS area. If you are receiving feeds regularly, you should see this figure increasing.

    • incoming feed statistics: This reports the number of articles and total bytes recevied from each of your NDNs.

    • NNTP traffic report: The output of nestor has also been included in this report which gives details of each nntp connection and the overall performance of the network connection read from the newslog file. To understand the format, read the manpage of nestor.

  • Error reporting from the errorlog file: Reports errors logged in the errorlog file. Usually these are file ownership or file missing problems which can be easily handled.

10.4. CPU load and RAM usage

With modern C-News and NNTPd, there is very little usage of these system resources for processing news article flow. Key components like newsrun or sendbatches do not load the system much, except for cases where you have a very heavy flow of compressed outgoing batches and the compression utility is run by sendbatches frequently. newsrun is amazingly efficient in the current C-News release. Even when it takes half an hour to digest a large consignment of batches, it hardly loads the CPU of a slow Pentium 200 MHz CPU or consumes much RAM in a 64 MB system.

One thing which does slow down a system is a large bunch of users connecting using NNTP to browse newsgroups. We do not have heuristic based figures off-hand to provide a guidance figure for resource consumption for this, but we have found that the load on the CPU and RAM for a certain number of active users invoking nntpd is more than with an equal number of users connecting to the POP3 port of the same system for pulling out mailboxes. A few hundred active NNTP users can really slow down a dual-P-III Intel Linux server, for instance. This loading has no bearing on whether you are using INN or nntpd; both have practically identical implementations for NNTP reading and differ only in their handling of feeds.

Another situation which will slow down your Usenet news server is when downstream servers connect to you for pulling out NNTP feeds using the pull method. This has been mentioned before. This can really load your server's I/O system and CPU.