CentOS Server网络是可访问的,但终端没有响应


0

我运行一个CentOS7x86服务器。

以下问题经常发生,但我不知道在哪里看。

  1. 运行服务器
  2. 运行一些docker容器(Jenkinsgitlab...)
  3. 它看起来很好,但几天后,无法访问 ssh
  4. 在这种情况下3ping服务器看起来很好但无法访问ssh
  5. 同样在服务器设备中,第一个终端看起来很好(等待用户输入。)但是只要我把它放到任何命令,就会挂起。(例如,我试过了firewall-cmd --list-port
  6. top之前使用时,它有足够的内存

我该如何解决这个问题?

  • 我可以假设它只是网络问题,因为我可以访问ping吗?
  • 是否可能只有端口22被阻止?

我需要任何建议如何开始这种问题。谢谢。

==================编辑========================

sar 命令报告如下

[ice@ice ~]$ sar
Linux 3.10.0-123.el7.x86_64 (DCSF-DEV08)    08/03/2017  _x86_64_    (24 CPU)

12:00:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
12:10:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
12:20:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
12:30:01 AM     all      2.74      0.00      1.61      0.02      0.00     95.62
12:40:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
12:50:01 AM     all      2.75      0.00      1.62      0.02      0.00     95.62
01:00:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
01:10:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
01:20:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.62
01:30:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
01:40:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
01:50:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
02:00:02 AM     all      2.74      0.00      1.62      0.02      0.00     95.63
02:10:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.63
02:20:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
02:30:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
02:40:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.63
02:50:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
03:00:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
03:10:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.62
03:20:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
03:30:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
03:40:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
03:50:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
04:00:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
04:10:01 AM     all      2.74      0.00      1.63      0.02      0.00     95.62
04:20:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
04:30:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
04:40:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.62
04:50:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
05:00:02 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
05:10:01 AM     all      2.75      0.00      1.62      0.02      0.00     95.62
05:20:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
05:30:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.62
05:40:01 AM     all      2.75      0.00      1.62      0.02      0.00     95.62
05:50:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
06:00:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
06:10:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.62
06:20:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
06:30:01 AM     all      2.75      0.00      1.62      0.02      0.00     95.62
06:40:01 AM     all      2.75      0.00      1.62      0.02      0.00     95.62
06:50:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.62
07:00:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
07:10:01 AM     all      2.75      0.00      1.62      0.02      0.00     95.62
07:20:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
07:30:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
07:40:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
07:50:02 AM     all      2.74      0.00      1.62      0.02      0.00     95.63
08:00:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.62

08:00:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
08:10:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
08:20:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.62
08:30:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
08:40:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
08:50:01 AM     all      2.74      0.00      1.61      0.02      0.00     95.63
09:00:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
09:10:01 AM     all      2.74      0.00      1.61      0.02      0.00     95.63
09:20:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
09:30:01 AM     all      2.75      0.00      1.61      0.02      0.00     95.63
09:40:01 AM     all      2.74      0.00      1.61      0.02      0.00     95.62
09:50:01 AM     all      2.74      0.00      1.62      0.02      0.00     95.62
10:00:01 AM     all      2.79      0.00      1.64      0.02      0.00     95.55
10:10:01 AM     all      2.75      0.00      1.62      0.02      0.00     95.62
Average:        all      2.74      0.00      1.62      0.02      0.00     95.62

对我来说,由于idle超过90%,内存问题不应该发生。

仅供参考,我的交换设置为(sysctl -a | grep swappiness):

vm.swappiness = 60

如果它挂在控制台中,则cpu可能已经饱和 - 通常这是因为如果内存已满,i / o等待内存,交换会使事情显着减慢。如果你离开uptime很长时间,那么它是否正常回来?这将告诉你它是否是CPU负载。
保罗于

谢谢@Paul是的。它看起来像virsh图像占用了太多的内存。不幸的是,它没有恢复正常。所以我必须重启设备。但是有没有任何系统日志可以告诉为什么突然交换内存使用变得如此之高?我得到了systemstat,但没有说明具体原因。
Juneyoung哦2010年

很难弄清楚事后发生的事情。据推测,你对容器有内存限制吗?
保罗

@Paul我运行了4个docker容器和1个qemuVM。当它发生时,4泊坞服务仍处于活动状态,但qemu服务已关闭。所以我猜我的qemu VM设置有一些内存问题。这对我来说是非常有用的解释(刚刚开始使用服务器设备管理)。非常感谢
Juneyoung Oh

@Paul如果您不介意,我想提供更多信息。我在原帖中添加了一些额外的信息。据我从互联网搜索,当用户使用率超过60%时,它将使用swap。然而,由于闲置率超过90%,交换不应该是重要的。有什么建议可以防止这样的服务器问题吗?
Juneyoung哦2010年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.