10. 监控和管理

一旦 Usenet 新闻系统安装并运行,新闻管理员需要借助系统生成的各种报告来监控系统。此外,他还需定期检查特定目录和文件,以确保系统平稳运行。

10.1.newsdaily报告

此报告由脚本生成newsdaily通常通过cron运行。我将根据我的观察,列举一些该报告报告的问题。

10.2. 来自newswatch

我收到的大部分问题是空间不足或持久锁。有时,脚本创建了锁文件,并在未删除锁文件的情况下中止/终止。有时,这些锁文件删除也无伤大雅,但应该在仔细分析后确定。它们可能表明系统的某些部分无法正常工作。例如,当 sendbatches 异常终止并尝试传输巨大的 togo 文件时,我会收到此错误消息。我必须确定 sendbatches 频繁失败的原因。

空间不足的问题必须立即解决。您可以运行doexpire删除不需要的文章,或者在操作系统层面增加更多磁盘空间。

10.3. 磁盘空间

$NEWSBIN区域占用的空间是固定的。由于二进制文件安装后不会增长,因此您无需担心此处的磁盘空间不足。随着 feeds 的传入,占用更多空间的区域是$NEWSCTL$NEWSARTS。每个 feed 都会使$NEWSCTL包含的日志文件不断增长。随着大量文章被处理,$NEWSARTS区域会持续增长。此外,如果您选择在过期时存档文章,您还需要空间。根据您订阅的层级数量以及每天传入的 feeds 数量,为$NEWSARTS分配几 GB 的磁盘空间。$NEWSCTL$NEWSARTS相比,增长比例较小。相应地为此分配空间。

10.4. CPU 负载和 RAM 使用率

使用现代 C-News 和 NNTPd,处理新闻文章流时,这些系统资源的使用率非常低。诸如newsrunsendbatches之类的关键组件不会占用太多系统资源,除非您有大量的压缩传出批次,并且压缩实用程序经常被sendbatches频繁运行。newsrun在当前的 C-News 版本中非常高效。即使需要半小时来处理大量批次,它也几乎不会增加速度较慢的 Pentium 200 MHz CPU 的 CPU 负载,也不会在 64 MB 系统中占用太多 RAM。

降低系统速度的一件事是大量用户使用 NNTP 连接来浏览新闻组。我们没有现成的基于启发式方法的数据来提供资源消耗的指导数据,但我们发现,对于一定数量的活动用户调用nntpd,CPU 和 RAM 的负载高于相同数量的用户连接到同一系统的 POP3 端口来提取邮箱。例如,几百个活跃的 NNTP 用户会真正降低双 P-III Intel Linux 服务器的速度。此负载与您使用的是 INN 还是nntpd无关;两者对于 NNTP *读取* 的实现几乎相同,仅在处理 feeds 方面有所不同。

降低 Usenet 新闻服务器速度的另一种情况是,下游服务器连接到您,使用 pull 方法拉取 NNTP feeds。前面已经提到过这一点。这会真正增加服务器的 I/O 系统和 CPU 的负载。

10.5.in.coming/bad目录

in.coming目录是您从 NDN 收到 feeds 后,以及在处理发生之前,批次/文章所在的位置。定期检查此目录以查看是否存在批次是确定 feeds 是否传入的好方法。批次和文章具有不同的命名方式。通常,批次的名称类似于 *nntp.GxhsDj*,单个文章的名称以数字开头,如 *0.10022643380.t*

bad子目录位于in.coming下,保存由relaynews处理时遇到错误的批次/文章。您将需要查看此目录中的单个文件以确定原因。理想情况下,此目录应为空。

10.6.out.going

中长期排队的队列待补充。

10.7. 与nntpxmitnntpsend

中长期排队的队列待补充。

相关的问题10.8.junk控制组

控制消息是指主题行中包含newgroup/rmgroup/cancel/checkgroup的消息。此类消息会导致relaynews调用相应的脚本,并在执行时,会将有关所采取操作的消息邮寄给管理员。这些控制消息存储在junk$NEWSARTS目录中。为了传播此类消息,必须订阅junk层级结构。

当您的新闻系统确定您未订阅某个文章时,该文章会被 "junked"(丢弃),即此类文章会出现在 junk 目录中。此目录在将文章传输到 NDN 时起着关键作用,因为他们会订阅 junk 层级结构以接收 feeds。如果您是叶节点,则没有理由在此处堆积文章。每天删除它们。