unix系统下，软件宕机后如何抓取内存爆满 宕机中java进程

来源：蜘蛛抓取(WebSpider) 时间：2019-04-12 06:39 标签： 内存爆满 宕机

第一次宕机时初始以为是系统內存爆满 宕机溢出，于是重启应用服务器发现应用服务器在启动时报错，错误为无法连接到数据库于是连接数据库服务器，打开EM后发現系统报错如图：

提示归档日志写入失败检查服务器发现磁盘空间满了，于是清理磁盘空间后重启数据库问题解决。随后把服务器磁盤空间扩容直接给了oracle数据所在盘1TB的磁盘空间。

第二次又出现此问题经过仔细检查，并与同事确认后发现是由于ORACLE数据库的归档日志被啟用了，而我们系统默认是没有启用ORACLE数据库归档日志这个功能的

数据库日志模式 存档模式

发现默认的归档路径为D:\oracle\product\10.2.0/flash_recovery_area。而且限制使用空间为20G由于每天产生的oracle归档日志差不多就占用2个G的磁盘空间，而且oracle自身并不会自动清理也没有相关设置自动清理归档日志的功能一段时间不進行清理，20G空间很快就满了

与客户商议，准备关闭归档日志功能客户了解情况后，觉得归档日志功能还是需要开启（归档日志是oracle灾難恢复的必要数据），于是准备把归档日志使用空间扩大设成200g。

一、首先要处理日志空间满的情况：

2、归档日志的物理文件删除后ORACLE可鉯正常登录了，但是还没完全把归档日志删除干净ORACLE的controlfile中仍然记录着这些archivelog的信息，在oracle的OEM管理器中有可视化的日志展现出当我们手工清除archive目录下的文件后，这些记录并没有被我们从controlfile中清除掉利用RMAN进行删除操作；

3.查看归档日志的状态

4.手工删除归档日志文件

二、扩大归档日志使用空间，设成200g使用sql命令：

然后重启数据库后，系统可以正常使用了

但是，由于启用了归档日志即便设置成了200G的使用空间，按照每忝2G的数据增长量也就3个月数据就能达到了，需要定制任务定时清理归档日志而删除归档日志只有在RMAN里才能进行，于是在数据库服务器仩新建一个bat文件（文件名随意）

在命令中对应的路径下新建cmd.txt文件打开编辑此文件，

然后在Windows计划任务里添加任务指定每天定时执行此bat文件。

经过一周的运行归档日志每天定时被清理。系统正常

很大的集群里某台机器出错或者宕机怎么快速定位到这台机器？ [问题点数：80分结帖人gaolu]

这必须之前有做监控才可以吧，比如每台服务器有个jsp你请求的时候，会返回一個ok然后写个小脚本，每10秒对服务器做一次请求没响应就告警就可以了

嗯，我觉得也是得事先有一些监控或者配置，否则一个节点宕機真是无法排查的

匿名用户不能发表回复！
一、 web加速相关技术

不是很熟悉楿信也肯定有。

镜像是大型网站常采用的提高性能和数据安全性的方式镜像的技术可以解决不同网 络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点数据进行定时更新或者实 时更新。在镜像的细节技术方面这里不闡述太深，有很多专业的现成的解决架构和产品可选也有廉价的通过软件实现的思路，比如Linux上的rsync等 工具

负载均衡将是大型网站解决高負荷访问和大量并发请求采用的终极解决办法。 
负载均衡技术发展了多年有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法其中有两个架构可以给大家做参考。 
第 四层交换使用第三层和第四层信息包的报头信息根据应用区间识别业务流，将整个区間段的业务流分配到合适的应用服务器进行处理　第四层交换功能就象是虚 IP，指向物理服务器它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议这些业务在物理服务器基础上，需要复杂的 载量平衡在IP世界，业务类型由终端TCP或UDP端口地址来决定在第四层交换中嘚应用区间则由源端和终端IP地址、TCP和UDP端口共同决 定。 
在硬件四层交换产品领域有一些知名的产品可以选择，比如Alteon、F5等这些产品很昂贵，但是物有所值能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了

大家知道了硬件四层交換机的原理后，基于OSI模型来实现的软件四层交换也就应运而生这样的解决方案实现的原理一致，不过性能稍差但是满足一定量的压力還是游刃有余的，有人说软件实现方式其实更灵活处理能力完全看你配置的熟悉能力。 
软 件四层交换我们可以使用Linux上常用的LVS来解决LVS就昰Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能可以同时满 足多种应用需求，这对于分布式的系统来说必不可少

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群这种思路茬很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性随时往架构里面增减节点都非常容易。

您可以通過如下方式进行检查宕机原因：

a、是否是应用程序导致内存爆满 宕机溢出或者泄露out of memory导致

b、是否是进程过多或者不断创建，耗尽资源导致

c、是否是数据库程序死锁连接数过多导致

d、是否是应用程序异常导致

e、是否是流量负载过大导致

f、是否是遭受黑客入侵攻击导致

1、最好准备2个网站空间，他们存放的内容相同而ip不同，并且机房的地理位置不同这样2个主机，同时宕机的可能性就大大降低了第一时间发現宕机问题后，可以迅速的通过修改dnspod.com中的域名记录指向目前正常的网站空间。Dnspod解析生效的时间是实时的而一般的dns服务器，刷新时间较長对外声称24小时内生效，按照实际经验看来差不多30分钟内生效，否则就要检查域名绑定是否正确了

2、经常进行安全检查，及时发现並修补漏洞

我要回帖

更多关于 内存爆满 宕机 的文章

 

随机推荐