精华内容
下载资源
问答
  • 服务器经常挂掉的6个原因

    万次阅读 2017-11-01 11:08:53
    如果没有任何经验,学习如何扩展一个网站是相当困难。假设现在你有很多像highscalability.com那样网站,你需要一些好解决方案来扩展它们,但是世上没有“万能药”,没有哪个解决方案可以适应所有网站需要。你...

    如果没有任何经验,学习如何扩展一个网站是相当困难的。假设现在你有很多像highscalability.com那样网站,你需要一些好的解决方案来扩展它们,但是世上没有“万能药”,没有哪个解决方案可以适应所有网站的需要。你不得不自己动手,通过不断地思考来找到一个能满足你的需求的解决方案。我也是这样做的。

    几年以前,我的老板来找我,然后对我说:“我们有一个新项目想交给你来做。主要是一个网站的重构,在一个月内,这个站点已经拥有100万个用户了。你必须重新构建这个网站,来确保我们可以应对将来逐渐增加的用户数量。”我已经是一个有经验的程序员了,但是在这些方面并不擅长,所以我不得不开始学习如何扩展一个网站——整个过程历尽了艰难困苦。(相关文章推荐:重构:“为什么”和“怎么做”)

    这个网站的后台软件是一个PHP内容管理系统,基于Smarty和MySQL。第一个任务是找到一个合适的托管公司,这个公司需要具有丰富的经验,可以为我们管理服务器。经过一番调查研究,我们找到了一家这样的公司,然后告诉他们我们的需求,他们给我们推荐的配置如下:

    • 负载均衡器 (+Fallback)
    • 2个Web服务器
    • MySQL服务器(+Fallback)
    • 开发机器

    他们说,这就是我们需要的所有东西了——对此,我们深信不疑。我们最后得到的配置是:

    • 负载均衡器 (单核, 1GB 内存, Pound)
    • 2个Web服务器 (双核, 4GB 内存, Apache)
    • MySQL服务器 (四核, 8GB 内存)
    • 开发机器 (单核, 1GB 内存)

    这个配置十分的基础,并没有做进一步优化。为了同步文件(PHP和媒体文件),他们建立了一个active-active DRBD。最后,重构开始了——当然,我们很兴奋。一大早,我们把域名切换到了新的IP上,运行我们的监控脚本,然后盯着屏幕看。我们马上在这些机器上看到了流量,一切似乎都工作的很好。页面载入的很快,MySQL负担了大量的查询任务,我们所有人都很高兴。

    然后,突然我们的电话开始响个不停:“我们不能访问你们的网站了,这是怎么回事?”我们看了一下我们的监控软件,事实的确如此——服务器都被frozen了,站点处于离线状态!当然,我们做的第一件事情是打电话给我们的托管服务提供商:“我们的所有服务器都死机了。这是怎么回事?”他们答应检查一下机器,一会再打过来。这个电话来了:“你的系统根本就无法插手。你做了什么?它完全被搞砸了。”他们停止了负载均衡器,然后让我观察一下其中一个Web服务器。看到那个index.php文件,我大吃一惊。它包含一些奇怪的C代码片段,错误消息和一些看起来像日志文件的东西。经过进一步的调查,我们发现是DRBD引发了这次事故。

    "杀死"你的服务器的方法之一

    把Smarty compile和模板缓存放到一个高负载的active-active DRBD集群上,那么你的服务器将会挂掉!当我们的托管服务提供商修复了Web服务器的时候,为了在这些服务器的本地文件系统上存储Smarty缓存文件,我重写了部分CMS代码。我们再次上线了!

    现在是午后。这个网站通常在下午的晚些时候到傍晚达到峰值。晚上,几乎没有什么流量。我们一直盯着监控软件,我们所有人都紧张得不得了。这个网站可以被载入,但是后来,系统负载越高,响应就越慢。我增加了Smarty模板缓存的生存期,希望这能产生效果——但是很可惜,这并没有产生效果!不久,服务器开始给出超时提示,空白页面和错误信息。有两台机器不能处理负载。

    我们的客户这个时候有一点紧张,但是他说:OK,重构通常会引发一些问题的。只要你能很快地修复它,那就没事了!

    我们需要一个计划来减少负载,然后,我们和我们的托管服务提供商讨论了这个问题。他们的一个系统管理员提出了一个好主意:“伙计,你的服务器现在运行在一个非常常见的Apache+mod_php架构上。把你的Web服务器换成Lighttpd怎么样?它是一个相当小项目,但是维基百科都在使用它。”我们同意了。(相关文章推荐:更好的选择 细数Apache服务器的四个替代者)

    "杀死"你的服务器的方法之二

    把一个开箱即用的Web服务器架设在你的机器上,并且一点也没有对它进行优化,那么你的服务器将会挂掉!那个管理员尽了他的最大努力,尽快地重新配置了所有的Web服务器。他抛弃了Apache,然后切换到Lighttpd+FastCGI+Xcache上来。后来,当我们重新上线的时候,我们几乎没有再感受到压力。这次,这些服务器会维持多长时间呢?

    这些服务器运行的出奇地好。负载比以前低很多,平均响应时间也不错。我们彻底放心了,然后我们都回家睡觉了。天已经很晚了,我们认为没有其他的事情需要我们做了。第二天,网站运行的相当好,但是在高峰时段,它一直接近于崩溃的边缘。我们发现MySQL是瓶颈,我们再次打电话给我们的托管服务提供商。他们建议在每个Web服务器上用MySQL从服务器进行MySQL的主-从同步。

    "杀死"你的服务器的方法之三

    再强大的数据库服务器也有它的极限,当你到达它的极限的时候,你的服务器将会挂掉!在这种情况下,某些时候你的数据库会变得十分缓慢,以至于队列中大量的网络连接会再次“杀死”我们的Web服务器。不幸的是这个问题很难修复。内容管理系统在这方面十分的简单,它本身并不支持单独地读取和写入SQL查询。重写这一切花了很长时间,但是相对于每分钟都遭遇到挂起休眠来说,是相当值得的。

    MySQL同步真的成功了,网站最终稳定了!在接下来的几周,几个月里,网站取得了成功,用户的数量开始不断地增加。流量再次超过我们的资源限制,这只是时间的问题。

    "杀死"你的服务器的方法之四

    不提前作规划,你的服务器可能会挂掉!

    幸运的是,我们一直在思考,并且一直在做规划。我们优化了代码,减少了每个页面载入的时候需要的SQL查询的数量,我们意外地发现了MemCached这个好东东。首先,我们在一些核心功能上添加了对MemCached的支持,在一些重量级(运行缓慢)的功能上我们也添加了对MemCached的支持。当我们把这些变更部署以后,我们简直不能相信这个结果——这感觉有点像发现了“圣杯”。我们每秒查询的数量至少降低了50%。我们决定更多地使用MemCached,而不是购买另外一个Web服务器。

    "杀死"你的服务器的方法之五

    忘记做缓存,你会浪费很多钱,而且,你的服务器还会挂掉!事实证明,MemCached帮助我们减少了70%-80%的MySQL服务器上负载,同时,在Web服务器上,也产生了巨大的性能提升。页面载入的相当快。

    最终,我们的配置看起来似乎是完美的。即使在高峰时段,我们也无须再担心崩溃或页面响应缓慢了。我们搞定它了吗?不!一台蓝色的Web服务器开始有一点响应缓慢了。然后出现了一些错误消息,空白页面等等。这个系统负载能力很不错,在大多数情况下服务器也都在工作,但是只是在“大多数情况下”而已。

    "杀死"你的服务器的方法之六

    把成百上千个小文件放在一个文件夹里,当索引节点耗尽的时候,你的服务器将会挂掉!

    是的,你没有看错。我们过去只是关注MySQL,PHP和Web服务器本身,并没有太关注文件系统。Smarty缓存文件存储在本地文件系统里——所有的缓存文件都存储在同一个目录下。解决方案是把Smarty放在一个专用的ReiserFS分区里。另外,我们还打开了Smarty的“use_subdirs”选项。

    在过去的几年里,我们一直在优化页面。我们把Smarty缓存放到了memcached中。为了更快速地处理静态文件,我们安装了Varnish来减少I/O负载。我们还切换到了Nginx(Lighttpd会随机的产生error 500的消息),安装了更多的内存,购买了更好的硬件,更多的硬件......这个列表永远不会结束。

    总结

    扩展一个网站是一个永远不会结束的过程。当你解决了一个瓶颈以后,很可能马上会遇到下一个瓶颈。永远都不要这样想:“就是这样,我们大功告成了”然后就靠边站了。这会“杀死”你的服务器,甚至是你的业务。规划和学习是一个持续的过程。如果你因为缺乏经验或资源而不能自己完成这个工作,那么可以找一个有能力胜任这个工作,而且很可靠的合作伙伴,和它一起来做这个工作。永远都不要停止和你的团队和合作伙伴沟通当前遇到的一些问题和即将会遇到的一些问题。思考在前才能争取主动。

    展开全文
  • linux上tomcat服务器突然挂掉了,查看catalina.out没有发现什么错误信息。 查看/var/log/messages文件发现是因为内存不足系统杀死 kernel: Out of memory: Kill process 15983 (java) score 149 or sacrifice ...

    linux上tomcat服务器突然挂掉了,查看catalina.out没有发现什么错误信息。
    查看/var/log/messages文件发现是因为内存不足系统杀死的
    kernel: Out of memory: Kill process 15983 (java) score 149 or sacrifice child
    linux 系统内存满了自动杀了不受保护的线程
    需要将Java进程加入到受保护的进程里

    展开全文
  • 记录一次有关redis缓存服务器挂掉的生产故障 就在上个星期,生产环境,由于redis主机挂掉,业务受阻差不多30分钟,导致甲方损失差不多300万,甲方一天的收入大概一个亿左右。 后来回顾发生此故障的原因是,虽然生产...

    记录一次有关redis缓存服务器挂掉的生产故障

    就在上个星期,生产环境,由于redis主机挂掉,业务受阻差不多30分钟,导致甲方损失差不多300万,甲方一天的收入大概一个亿左右。
    后来回顾发生此故障的原因是,虽然生产环境redis集群配置的是主从模式,并且每个主(master)节点都有3个 从(slave)部署在不同的服务器上,但是这只是解决了读写分离和数据备份的问题,并没有保障redis缓存集群的高可用性,在主从模式下,主节点故障,集群则无法进行工作,从节点升主节点需要人工手动干预!也就是无法在redis主节点挂掉以后,不能进行主从切换和选举!
    后来在平台组的介入下,我们将生产环境的redis集群做了高可用的方案,redis主从模式+Sentinel(哨兵)-架构图如下:
    在这里插入图片描述
    Sentinel 哨兵是 redis 官方提供的高可用方案,可以用它来监控多个 Redis 服务实例的运行情况。Redis Sentinel 是一个运行在特殊模式下的 Redis 服务器。Redis Sentinel 是在多个Sentinel 进程环境下互相协作工作的。Sentinel 系统有三个主要任务:

    监控:Sentinel 不断的检查主服务和从服务器是否按照预期正常工作。

    提醒:被监控的 Redis 出现问题时,Sentinel 会通知管理员或其他应用程序。
    自动故障转移:监控的主 Redis 不能正常工作,Sentinel 会开始进行故障迁移操作。将一个从服务器升级新的主服务器。让其他从服务器挂到新的主服务器。同时向客户端提供新的主服务器地址。

    如果当初在架构设计的时候,就采用主从模式+哨兵的高可用方案,可能就不会出现上个星期的生产事故!被动的等到出了问题时候补救的方式,远远不如主动的思考目前我们当下所采用的的架构设计是不是存在某些隐患!防范于未然才是最重要的!

    展开全文
  • 小项目用到的服务器老旧,其中一台周末因为总线等硬件原因挂掉了,各种监控报警,运维尝试恢复失败后直接建议更新设备,于是需要服务迁移和恢复。 其中ZooKeeper&Flink&Hadoop集群因为单节点连接失败也开始...

    背景:

    小项目用到的服务器老旧,其中一台周末因为总线等硬件原因挂掉了,各种监控报警,运维尝试恢复失败后直接建议更新设备,于是需要服务迁移和恢复。

    其中ZooKeeper&Flink&Hadoop集群因为单节点连接失败也开始罢工了。

    组里的架构加运维大牛走了,小白尝试恢复集群服务。所以本文只涉及简单的服务恢复和报错处理。

    Tips:要学会利用日志、日志、日志排查问题。

     

    一、ZooKeeper

    最初尝试恢复的实际是Flink,恢复失败后发现其日志中关于zooKeeper的报错(如下),于是又恢复zookeeper。项目用到的Kafka同样依赖zookeeper,恢复zookeeper后kafka服务自动恢复。

    2021-01-11 14:42:40,259 INFO  org.apache.flink.shaded.zookeeper.org.apache.zookeeper.ClientCnxn  - Opening socket connection to server 10.*.*.*/10.*.*.*:2181
    
    2021-01-11 14:43:00,281 INFO  org.apache.flink.shaded.zookeeper.org.apache.zookeeper.ClientCnxn  - Client session timed out, have not heard from server in 20266ms for sessionid 0x0, closing socket connection and attempting reconnect

    恢复方法:

    1. 登录正常的集群服务器,进入zookeeper的服务路径,查看配置文件:

    cd /data1/apache-zookeeper-3.5.6-bin
    
    vim conf/zoo.cfg

    2. 去掉失效节点的配置

    server.1=server132:2888:3888
    server.2=server138:2888:3888
    server.3=server137:2888:3888
    server.4=server166:2888:3888

    例如上面原配置中的server.3失效了,删除原server.3,把原server.4改成server.3。

    3. 重启服务

    ./bin/zkServer.sh restart 

    在配置文件中涉及的每台集群机器上重复以上步骤。

    通过日志查看重启是否成功:tail -f logs/zookeeper-root-server-server138.out

    4. 错误警告:

    在server166的服务器上,因为其id从4变为3,在重启之后会报错:

    java.lang.RuntimeException: My id 4 not in the peer list

    原因是:配置文件zoo.cfg中的server顺序id与 vim  /data1/apache-zookeeper-3.5.6-bin/tmp/myid 中的id不一致。

    即配置变更中涉及到id变更的服务器,需要修改myid使其跟配置文件中一致,然后再重启就可以了。

     

    二、Flink

    恢复方法:

    1. 登录集群的正常的服务器,查看配置文件确认Flink的主从配置。

    vim /data1/flink-1.10.1/conf/master
    
    vim /data1/flink-1.10.1/conf/slaves

    master配置中是IP端口号,slaves配置中就是IP列表

    2. 更新配置文件,把失效节点去掉

    3. 在master服务器上执行服务重启

    cd /data1/flink-1.10.1
    
    ./bin/start-cluster.sh 

    在集群各台服务器上通过jps命令(TaskManagerRunner等各进程是否正常启动)或日志查看服务的重启情况(例如:tail -f log/flink-root-taskexecutor-1549-server138.log)。

    4. 错误预警

    启动的shell脚本是通过ssh远程连接其他master或slave机器进行控制的,所以执行命令的机器公钥需要放到被连接的机器的公钥授权文件中。否则会报错:

    Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

    操作步骤:

    在执行机器通过: cat ~/.ssh/id_rsa.pub   or  cat /root/.ssh/id_rsa.pub  获取公钥

    在被连接机器上编辑:vim ~/.ssh/authorized_keys 添加公钥

     

    三、Hadoop

    恢复步骤:

    1. 登录集群机器,修改配置文件

    cd /data1/hadoop/etc/hadoop
    
    vim core-site.xml
    
    vim hdfs-site.xml 
    
    vim yarn-site.xml
    
    vim  workers

    涉及节点配置的配置文件有4个,在每台集群机器上都同步修改。

    2. 重启

    在其中一台服务器上执行即可。

    cd /data1/hadoop 
    
    ./sbin/start-all.sh
    
    #单独启动nodemanager:
    
    ./sbin/yarn-daemons.sh start nodemanager

    同样,可通过jps或日志(tail -f  logs/hadoop-root-nodemanager-server138.log )确认重启的情况。

    3. 错误预警

    项目中Hadoop中用到了两台服务器,在server1中执行重启命令后,nodemanager启动15分钟后就又自动关闭了,报错信息如下:

    org.apache.hadoop.yarn.server.nodemanager.NodeStatusUpdaterImpl: Unexpected error starting NodeStatusUpdater
    
    org.apache.hadoop.yarn.exceptions.YarnRuntimeException: java.net.ConnectException: Call From server138/10.13.1.138 to server132:8031

    在网上查到的信息大多是:

    yarn.resourcemanager.resource-tracker.address的默认端口,yarn-site中没有配置这个的地址,结果连接到本地的8031端口等,需要修改配置文件等。

    如:https://www.cnblogs.com/zwgblog/p/6071603.html

    实际还有一种情况,即被连接机器的服务有问题,如log中的server132(日志中显然尝试连接的并不是本地)

    且两台服务器通过 netstat -ntual |grep 8031 查看端口,根本就没启动。

    到server132上查看Hadoop日志,发现是这台服务器的/data1/磁盘空间不够了。

    2021-01-13 15:07:39,575 WARN org.apache.hadoop.yarn.server.nodemanager.DirectoryCollection: Directory /data1/hadoop/data/nm-local-dir error, used space above threshold of 90.0%, removing from list of valid directories
    
    2021-01-13 15:07:39,575 WARN org.apache.hadoop.yarn.server.nodemanager.DirectoryCollection: Directory /data1/hadoop/logs/userlogs error, used space above threshold of 90.0%, removing from list of valid directories
    
    2021-01-13 15:21:49,947 ERROR org.apache.hadoop.yarn.server.nodemanager.NodeStatusUpdaterImpl: Unexpected error starting NodeStatusUpdater

     

    展开全文
  • 早在2010年时候遇到过这样的事情,因为file_get_contents函数造成服务器挂掉的情况,现在觉得很有必要总结下。 公司里有经常有这样的业务,需要调用第三方公司提供的HTTP接口,在把接口提供的信息显示到网页上,代码...
  • 开始只是感觉硬盘满了 需要清理 所以每次都删除一些文件 然而第二天网站又挂掉 输入df命令查看磁盘使用情况 df 进入文件最大目录继续追踪 那么到底是什么导致文件每天都在飞速增长呢 输入  du ...
  • QUESTION:服务器上的Linux中Tomcat有时会挂掉的问题及方法? 目录 QUESTION:服务器上的Linux中Tomcat有时会挂掉的问题及方法? ANSWER: 一、内存不足 二、服务器内存不足 三、解决方法 3.1Tomcat内存优化 ...
  • 服务器集群技术(备份服务器方案和均摊工作方案)(用来解决服务器挂掉问题) 一、总结 1、在一个集群里面,比如老大因为莫名其妙的原因挂掉了,集群监测到老大挂掉了直接给他断掉电源(等待维修),然后让老二上...
  • JAVA服务线上毫无征兆的直接crash掉,打开日志查看,日志文件毫无相关挂掉的信息,所以当时直接选择了重启,当时的猜测是:服务内存不足导致程序进程直接挂掉? 查找原因 后来学习查找到一个命令dmesg命令,这个...
  • MAC 上运行到MTCNN相关代码时,jupyter notebook 就死 通过在terminal中查看日志: 8. Tune using inter_op_parallelism_threads for best performance. OMP: Error #15: Initializing libiom
  • 在日常开发维护过程中,我们服务会因为各种原因挂掉,这个时候实现自动重启服务就比较重要! 服务异常挂掉后,自启 实现原理:使用linux系统crontab定时任务,对服务进程进行监听,当服务进程不在时候,我们来执行...
  • 服务器的tomcat总是自己挂掉,而且日志里没有严重错误,服务器四核八线程,端口也没有被占用,到底是什么原因呢? <p>02-Jun-2021 09:26:30.021 信息 [main] org.apache.coyote....
  • 很多人遇到过服务器RAID5挂掉,往往掉一个盘后,第二个盘也立刻挂掉。 大家都知道RAID5 一次允许一个盘缺失, RAID 5也是以数据校验位来保证数据安全,但它不是以单独硬盘来存放数据校验位,而是将数据段...
  • 准生产上项目太长时间没人动他,昨天发现莫名其妙的挂了,同事手动起来tomcat和dubbo服务,今天联通那边说 接口调不通,不得不今天来排查看看什么原因。初步排查 是tomcat里日志文件太大。 随着项目运行,...
  • 2、可能是内存溢出了,一般在tomcat挂掉之前会生成一个hs_err_pid8788.log日志,一般这个日志在tomcatbin里面,从中可以看到一些错误信息;3、如果数据库都没有了,那就是被黑客黑了,一般被黑客黑了,会留一条...
  • 原因FTP或数据库服务器设置了会话无操作timeout,当无操作时间大于这个值时候,将会导致服务器将连接切断(connection reset by peer)解决 方法一:将服务器的timeout值设置得更长或者禁止服务器自动切断连接 ...
  • 不停地接到电话说是mysql挂了,我人又在外面不能操作,眼当花钱打广告得到的用户因为这样的原因又走掉了,我自认为是一个很努力的网管,但仍感无能为力,我还有一台服务器非常奇怪,每天早上5点钟定期挂掉...
  • 我用ireport 制作pdf模板最近在系统中时不时出现因为某个jasper文件导致系统挂掉服务器内存被调用这个文件一个进程占用完了但是再次在系统中打印预览这个文件又正常了。不存在数据量大问题,求各位高手...
  • 即使在程序没有挂掉时把程序停掉,系统内存也不会被释放。 找原因的过程 这个问题已经困扰我好几个月了,分析过好多次都没有找到原因,网上查了一下该问题其他人也都遇到过,不过并没有什么好解决方案,因为...
  • 第二个错误连续出现十多次,IIS也挂掉了三次。访问量一分钟大约三四百,请问有可能什么原因造成呢? 查看系统错误为: 1.在与 SQL Server 建立连接时出现与网络相关或特定于实例错误。未找到或无法访问服务器...
  • 笔者使用是anacondajupyter notebook,再使用pytorch构建神经网络时候,每一次加载torch就会...被逼无奈之下,卸载了anaconda,然后重新安装了下(实际原因是不小心卸载了tornado[一个用来网络编程,链接jupyter
  • 今天在CentOS 系统上部署几个项目,然后运行一段时服务就会莫名其妙会挂掉一两个,然后重新启动挂掉的服务之后又会出现其他服务挂掉的情况,查看启动日志也并没有发现有异常抛出。 排除掉技术原因后,发现是因为启动...
  • 中间睡眠20秒是让我自己有时间关闭服务器,是用来模拟服务器挂掉的时候当前操作只进行了一部分,服务器挂了之后睡眠前的数据持久化到数据库了,睡眠后的数据没有持久化到数据库,我想不明白是什么原因,我觉得既然...
  • 一、故障现象服务器是放10来个游戏服的,最近发现总有一个游戏服会无缘无故挂掉,程序日志和命令记录也没有找到挂掉的原因,后来在系统日志(/var/log/messages)找到报错信息:messages从报错可以看到时间点是对得上...

空空如也

空空如也

1 2 3 4 5 ... 15
收藏数 297
精华内容 118
关键字:

服务器挂掉的原因