Oom

我的项目背景产生故障的零碎是基于spring cloud和Vue搭建的一套前后端拆散的零碎，次要是用来对接小程序来应用的，后端分为两个根底服务、四个核心服务以及三个对端服务，所有的流量都是从网关打到对端服务，再通过对端服务去调用核心服务和根底服务。会员注册数是四千万左右。遇到的挑战与解决办法 先说说第一个吧，第一个挑战产生在企业会员日当天的下午三点钟，这天经营人员在小程序中开启了一个秒杀流动，就是有一万张买一送一卷，当三点达到时大量用户同一时间涌入小程序中，这一时间的申请数大略是平时的五倍左右，但就在这时小程序呈现了长时间的卡顿和白屏景象，一个申请的响应工夫比平时慢了三倍左右，这段时间继续了五分钟，也就是当这一万张卷抢完后流量迅速下滑才复原。 在后续考察时发现上一次迭代的时候在小程序首页退出了一个新的查问接口，这个接口是在用户进入小程序时会主动触发，这也就导致在流量过高时，店铺零碎就会存在大量申请拜访数据库使得零碎响应工夫变长。零碎性能降落又导致用户反复点击操作，这又加深了零碎累赘，进而更加好转。 解决方案也很简略，就是在首页加一个交互，当用点击后才去触发当初的那个接口，并且在接口中减少缓存，防止数据库压力过大，这其实在开发中很常见，本人写的接口进行测试发现就几十毫秒的响应工夫，然而当用户申请数霎时暴增时数据库接受了他不该接受的分量而被压垮。 再来说说第二个，这次是在某天中，零碎忽然频繁奔溃，在重启后不到半小时就解体，在阿里云平台的ARMS监控中能够能够看到零碎在某个工夫节点内频繁的进行FULLGC,查看零碎谬误日志发现存在大量OOM异样，首先想到的就是会不会又是在搞什么经营流动，申请量暴增导致，然而在查看零碎申请数后发现曲线平缓，并没有峰值。 当临时没有脉络时就从第一个解体的服务开始查，发现其中有个发卷的接口响应工夫间接超时了，查看起因发现有个经营本人创立了一个扫码领劵的流动，每扫一次码就支付一百万张卷，他扫了四次，也就是给他发放了四百万张卷，最初一次扫码时接口就超时了，之后这个人去小程序中查看本人的卷包时导致的OOM，因为用户的卷最多也就几百张，所以在查问优惠券时没有进行分页，导致一次将几百万的对象存到内存中导致内存溢出。这也就导致当他进行查看一次优惠券，咱们零碎就会解体一次。 解决办法就是先在优惠券发放上加上限，以及分页查问优惠券，并且优化数据库连贯超时工夫，以前将超时工夫设置的太长，导致某个慢SQL长期霸占数据库资源，导致系统卡顿。 总结当遇到零碎解体时，不要慌乱，先从谬误日志以及对应的性能监控平台进行查看，收集有用的信息，友盟的性能监控平台目前还没有应用过，等有机会应用过再来谈谈其与别的监控平台的应用感触。 代码是不会有“灵异事件”的，如果有只能阐明是你还没有学到位，对于某些中央还存在缺点，所以不必胆怯，标准编码以及勤加思考和学习能力写出高质量的零碎。

最近我的项目常常会被 OOM kill 掉，然而没有在 /var/log/messages 看到 OOM 日志。其实不同 Linux 发行版 OOM 日志在不同的中央，然而能够通过 dmesg 查看。 [33350932.058517] Task in /kubepods/burstable/podbed004f6-87f6-415f-8b42-696e12d6096a/851f02a6960c8b872559de9e29feda1b8ed41d397096d95d3dc8d6f74e9de061 killed as a result of limit of /kubepods/burstable/podbed004f6-87f6-415f-8b42-696e12d6096a[33350932.058524] memory: usage 14680064kB, limit 14680064kB, failcnt 811012[33350932.058525] memory+swap: usage 14680064kB, limit 9007199254740988kB, failcnt 0[33350932.058526] kmem: usage 194960kB, limit 9007199254740988kB, failcnt 0[33350932.058526] Memory cgroup stats for /kubepods/burstable/podbed004f6-87f6-415f-8b42-696e12d6096a: cache:0KB rss:0KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB[33350932.058540] Memory cgroup stats for /kubepods/burstable/podbed004f6-87f6-415f-8b42-696e12d6096a/3bf687dcb3254c8e7b66ad7b5a93918f65076cae647d84424f6f590ef13ba451: cache:0KB rss:0KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB swap:0KB inactive_anon:0KB active_anon:48KB inactive_file:0KB active_file:0KB unevictable:0KB[33350932.058550] Memory cgroup stats for /kubepods/burstable/podbed004f6-87f6-415f-8b42-696e12d6096a/851f02a6960c8b872559de9e29feda1b8ed41d397096d95d3dc8d6f74e9de061: cache:0KB rss:14482160KB rss_huge:0KB shmem:0KB mapped_file:528KB dirty:0KB writeback:3960KB swap:0KB inactive_anon:0KB active_anon:14485012KB inactive_file:16KB active_file:8KB unevictable:0KB[33350932.058559] Tasks state (memory values in pages):[33350932.058560] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name[33350932.059085] [ 53131] 0 53131 256 1 32768 0 -998 pause[33350932.059090] [ 53484] 0 53484 3804 826 73728 0 945 sh[33350932.059093] [ 53511] 0 53511 27556 708 253952 0 945 sshd[33350932.059096] [ 53565] 0 53565 21333 1104 212992 0 945 su[33350932.059099] [ 53567] 0 53567 27538 711 86016 0 945 opagent[33350932.059101] [ 53579] 1602 53579 12617494 3622901 34770944 0 945 java[33350932.059104] [ 59796] 0 59796 1933 180 57344 0 945 sleep[33350932.059248] Memory cgroup out of memory: Kill process 53579 (java) score 1934 or sacrifice child[33350932.065172] Killed process 53579 (java) total-vm:50469976kB, anon-rss:14454940kB, file-rss:36664kB, shmem-rss:0kB[33350933.005245] oom_reaper: reaped process 53579 (java), now anon-rss:0kB, file-rss:8kB, shmem-rss:0kBDocker 给了 15G 的内存，JVM 调配了 12G，还有各种 Buffer 和 Cache 的内存，后果就超过了限度，被 OOM 了。 ...

摘要：该我的项目是DAYU平台的数据开发（DLF），数据开发中一个重要的性能就是ETL（数据荡涤）。ETL由源端到目标端，两头的业务逻辑个别由用户本人编写的SQL模板实现，velocity是其中波及的一种模板语言。Velocity之OOMVelocity的根本应用Velocity模板语言的根本应用代码如下： 1. 初始化模板引擎2. 获取模板文件3. 设置变量4. 输入在ETL业务中，Velocity模板的输入是用户的ETL SQL语句集，相当于.sql文件。这里官网提供的api须要传入一个java.io.Writer类的对象用于存储模板的生成的SQL语句集。而后，这些语句集会依据咱们的业务做SQL语句的拆分，一一执行。 java.io.Writer类是一个抽象类，在JDK1.8中有多种实现，包含但不仅限于以下几种： 因为云环境对用户文件读写创立等权限的安全性要求比拟刻薄，因而，咱们应用了java.io.StringWriter，其底层是StringBuffer对象，StringBuffer底层是char数组。 简略模板Hellovelocity.vm： ; "复制代码") set($iAMVariable = 'good!')set($person.password = '123')Welcome ${name} to velocity.comtoday is ${date} foreach($one in $list)$oneendName: ${person.name}Password: ${person.password} ; "复制代码") HelloVelocity.java; "复制代码") package com.xlf; import org.apache.velocity.Template;import org.apache.velocity.VelocityContext;import org.apache.velocity.app.VelocityEngine;import org.apache.velocity.runtime.RuntimeConstants;import org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader; import java.io.StringWriter;import java.util.ArrayList;import java.util.Date;import java.util.List; public class HelloVelocity { public static void main(String[] args) { // 初始化模板引擎 VelocityEngine ve = new VelocityEngine(); ve.setProperty(RuntimeConstants.RESOURCE_LOADER, "classpath"); ve.setProperty("classpath.resource.loader.class", ClasspathResourceLoader.class.getName()); ve.init(); // 获取模板文件 Template template = ve.getTemplate("Hellovelocity.vm"); VelocityContext ctx = new VelocityContext(); // 设置变量 ctx.put("name", "velocity"); ctx.put("date", (new Date())); List temp = new ArrayList(); temp.add("Hey"); temp.add("Volecity!"); ctx.put("list", temp); Person person = new Person(); ctx.put("person", person); // 输入 StringWriter sw = new StringWriter(); template.merge(ctx, sw); System.out.println(sw.toString());}} ...

作者：秦福朗爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查。酷爱 IT，喜爱在互联网里畅游，善于摄影、厨艺，不会厨艺的 DBA 不是好司机，didi~本文起源：原创投稿*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。一、问题背景业务反馈，数据库最近总是隔一段时间连贯失败，过一会又没事了，一天能产生了 2、3 次，起初发现和主机传统大页的配置无关，具体起因是什么，请持续看。 二、环境背景：MySQL 5.6.25  vmware 虚拟机 CentOS 7.1 CPU 32C 内存 64G innodb_buffer_pool_size = 48G 三、排查过程1、首先查看了 mysql uptime 发现工夫在明天，阐明有过重启。2、查看以后内存 cpu 的应用：应用 free 查看零碎 64G 内存，used 应用了 61G+，还剩下 200 多 M 的 free，buffer/cache 也不多，应用 top 查看 MySQL RES 占用 20 多 G 左右。 应用 numa 查看以后 numa 调配： 发现每个 node 的残余内存均不多。 3、因为狐疑重启，所以查看下系统日志，发现了重启起因 发现 mysqld 发现了 OOM（什么是 OOM，能够在本公众号搜寻 OOM），且一天产生了 2、3 次和业务反馈是对的上的。 ...