我有许多 Linux 服务器(SUSE 9 和 10),用于运行向大型计算网格提供数据的 Web 服务。最近,我们遇到了一些难以解释的中断(即硬件和软件日志未显示任何明显错误),我们开始怀疑长时间正常运行(通常为 200-300 天)是否是问题所在。鉴于这些服务器的使用率很高,我是否应该考虑定期重启?
答案1
内核更新后必须重新启动(除非您使用 KSplice),其他任何事情都是可选的。我个人在维护窗口期间每月重新启动一次,以确保服务器和所有服务按预期恢复。这样,如果我必须进行计划外的重新启动(即关键内核更新),我可以相当确定系统将正常恢复。服务器和服务的自动监控(即 Nagios)也对帮助此过程大有帮助(重新启动,观察指示灯变红,然后希望全部恢复为绿色)。
PS 如果您确实定期重启,则需要确保适当调整 fsck 检查(即检查之间的最大挂载计数,否则如果服务器开始 fsck 几 TB 的数据,则快速 2 分钟重启可能需要 30 分钟。我通常将挂载计数设置为 0(tune2fs -c 0)并将检查间隔设置为 6 个月左右,然后每隔一段时间手动强制执行一次 fsck 并重置计数。
答案2
事实上,每当进行重大配置更改时,我都会定期重启服务器。重要的是要知道,在紧急情况下,服务器软件将毫不费力地启动。你最不想发生的情况是,你正试图从中断中恢复,但却不得不弄乱你的服务器配置,因为你在设置时没有彻底测试它。
答案3
Linux 服务器永远不需要重启,除非你绝对地需要更改正在运行的内核版本。大多数问题都可以通过更改配置文件并使用 init 脚本重新启动服务来解决。
您需要注意重启...如果您“动态”更改了任何内容而没有在服务配置文件中反映您的更改,则重启后这些更改将不会应用。
不过,我通常会在预定的系统更新后重启。这通常没有必要,但我在办公室没人的时候重启,所以为什么不呢?无论如何,当我进行更新时,通常会有内核升级。
答案4
我认为如果最近有内核更新或 libc 更新,则应该重新启动。很多东西都与 libc 相关联,除非重新启动,否则不可能完全从内存中卸载该库并将其替换为新版本。
例如,即使像 /bin/ls 这样的最基本的东西以及 /bin 中的其他东西也使用 libc。如果您只是运行控制台并使用 bash,那么您就是在使用 libc。
$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
/lib/ld-linux.so.2 (0xb804b000)
$ ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
libc.so.6 => /lib/libc.so.6 (0xb7de7000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
/lib/ld-linux.so.2 (0xb7f61000)
libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)
是的,如果你更改了 /etc/init.d 中的文件,而这些文件在某种程度上影响了启动,我建议你重启一下。当你需要快速重新启动时,你肯定不想发现自己在启动文件中犯了一个小错误。
如果服务器已经很多天没有重启,实际上意味着无法确保它再次正常启动。再次强调,这是因为服务器上的许多配置文件可能已经更改,并且很长时间没有人重启它以确保它能够启动。此外,如果服务器有很多更新需要更新,并且您很长时间没有重启,请重启前您应用更新,否则如果出现问题,您无法确定它是由很久以前的配置错误还是您应用的新更新引起的。
最后,如果您在很长时间后重新启动关键服务器,则 fsck 可能意味着您必须等待很长时间才能恢复。您可以使用 tune2fs 来避免这种情况,但我认为定期检查它是个好主意。这就是为什么您不应该处于仅依赖 1 台服务器的境地,如果那台服务器坏了,您的整个网站就没了。您应该有另一台待命。