应用性能调优的一些实践可视化界面在线生成JVM参数一次线上故障：数据库连接池泄露后的思考java内存溢出问题分析过程二(附MAT超全操作文档)使用Eclipse

输出一句话，在控制台输出几行记录后，打上了一个断点。这样做，对后续的任务有什么影响呢？可以看到，断点时的后续任务是阻塞着的，从图上，我们还可以看出初始化的名为pool-1-thread-1

前言今天整理的这篇文章，整理自以前记录的日常笔记。刚开始接触JVM时，对待GC的日志，是保持"逃避"态度的，线上部署的程序没有达到期望的运行效率，或是预期目标时，往往会把问题的矛头指向内存上。是不是内存不够？GC日志怎么这么多？占用磁盘高达几个G?不想看到打印怎么多，甚至暴力的将程序日志屏蔽掉。我也曾经这样干过，写过的程序，同样导致过内存溢出，甚至是主机宕机。是的，java中的垃圾回收的确帮我们省了很多事，我们不像C/C++程序员一样，需要考虑分配（malloc）内存分配与（free）释放内存，但我相信每个java开发的小伙伴都会遇到GC问题，无论是在程序的性能优化，还是故障分析上。我们应该在一次又一次的失误中获得经验和教训，而不是去逃避或是草草解决问题了事。同样的知识点，回顾两次，就会产生

groupid）的复合索引，缩小了单个事务锁定的记录条数，也实现了不同计划下的推广组数据记录的隔离，从而减少该类死锁的发生几率。通常来说，对于数据库层的调优我们基本上会从以下几个方面出发：（1）在

在线生成JVM参数配置网址：http://jvmmemory.com堆参数设置-XX:+PrintGC使用这个参数，虚拟机启动后，只要遇到GC就会打印日志。-XX:+PrintGCDetails可以查看详细信息，包括各个区的情况-XX:+PrintHeapAtGC

Set。由图可以看出，C是E的直接支配节点，所以C的上级支配节点B也可以支配E。dump分析初步首先用MemoryAnalyzer工具打开dump文件。从整体情况可以看出，1.6

以下方式可以打开Histogram柱状图：（1）点击Overview页面Actions区域内的“Histogram视图”链接（2）点击工具栏的“histogram按钮”Histogram视图：

前言在时间的荒野里,遇见对的人，没有早一步,也没有晚一步,刚巧赶上了,正是因为天空辽阔，它才能缓缓投下光束，那正是你眼所里闪烁的。女神节快乐！快速定位性能故障并非一朝一夕之功，需要我们对很多概念有很深刻的理解，在前文中，我们介绍了heap

dump的类型），这个可以点击Configure按钮来设置。选择要dump的线程，点击Next按钮就可以生成dump文件了。有的时候进程列表可能为空，这时有必要调整下Heap

前言前一阵子，阿里云服务器促销，买了一台2G的主机来做测试学习用，搭好环境后基本就没怎么管它，最近发现CPU总是跑满，，于是按CPU消耗排序，排在第一的是一个名为“kdevtmpfsi”的进程，查了一下是一个挖矿木马，于是赶紧采取办法。1查看CPU占用Top

-ef是ps命令加上-ef参数，ps命令主要用于查看进程的相关状态，-e代表显示所有进程，而-f代表完整输出显示进程之间的父子关系，例如下面是笔者的虚拟机中的CentOS

前言在日常的开发和运维中，我们时常会使用Dockerfile脚本制作镜像。其实编写一个Dockerfile文件用到的标签并不会太多，但是不同的Dockerfile在制作后产生的镜像大小是不尽相同的，这篇文章就来梳理一下，编写脚本过程中，容易犯的错误。一、拉取最新的镜像在从镜像仓库拉取镜像时，不指定任何版本的情况下，默认会拉取最新（latest）的版本。这在我们构建集群和复用时会造成困扰，也就是说只要组件的镜像仓库还在更新，不同时间拉取到的镜像版本可能是不一样的，那样简直太混乱了，所以，在拉取镜像时，记得加上具体的版本号。二、在构建时使用外部脚本命令很多人在构建镜像时，没有明确的区分出在宿主机上和在容器内执行的区别。构建映像时，Docker读取Dockerfile中的命令并从中创建镜像，不应该在文件里使用一些宿主机上的命令，因为这些环境在容器内，可能压根就没有。如：#

由于redis是单线程模型，虽然避免了多线程下线程切换所耗费的时间，单一顺序的执行命令也很快，但是在大批量数据导入的场景下，发送命令所花费的时间和接收服务器响应结果耗费的时间就会被放大。

前言-CountDownLatch是什么？CountDownLatch是具有synchronized机制的一个工具，目的是让一个或者多个线程等待，直到其他线程的一系列操作完成。CountDownLatch初始化的时候，需要提供一个整形数字，数字代表着线程需要调用countDown()方法的次数，当计数为0时，线程才会继续执行await()方法后的其他内容。CountDownLatch(int

来源：https://sourl.cn/DsgGRq早上作为能效平台系统的使用高峰期，系统负载通常比其它时间段更大一些，某个时间段会有大量用户登录。当天系统开始有用户报障，发布系统线上无法构建发布，然后后续有用户不能登录系统，系统发生假死，当然系统不是真的宕机，而是所有和数据库有关的连接都被阻塞，随后查看日志发现有大量报错。1初步排查和数据库连接池相关：Causedby:

前言首次接触到Stream的时候以为它是和InputStream、OutputStream这样的输入输出流的统称，今天准备来梳理一下相关的知识点。流和集合的前世今生概念的差异在开发中，我们使用最多的类库之一就是集合。集合是一种内存中的数据结构，用来保存对象数据，集合中的每个元素都得先算出来才能添加到集合中，相比之下：集合用特定数据结构（如List，Set或Map）存储和分组数据。但是，流用于对存储的数据（例如数组，集合或I

前言可能你经历过这些Red。。。。等等那ES的Red是什么意思？这里说的red,是指es集群的状态，一共有三种，green、red、yellow。具体含义：冷静分析从上图可知，集群red是由于有主分片不可用，这种情况一般是由于节点宕机。有什么影响呢？至少一个主分片（以及它的全部副本）都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。此时我们可以执行相关的命令进行状态检查。集群节点是否都存在、查看集群状态。curl

前言elasticsearch提供了非常灵活的搜索条件给我们使用，在使用复杂表达式的同时，如果使用不当，可能也会为我们带来了潜在的风险，因为影响查询性能的因素很多很多，这篇笔记主要记录一下慢查询可能的原因，及其优化的方向。本文讨论的es版本为7.0+。慢查询现象查询服务超时最直观的现象就是提供查询的服务响应超时。大量连接被拒绝我们有时候写查询，为了图方便，经常使用通配符*来查询，这有可能会匹配到多个索引，由于索引下分片太多，超过了集群中的核心数。就会在搜索线程池中造成排队任务，从而导致搜索拒绝。查询延迟主机CPU飙高另一个常见原因是磁盘

请求间的相互影响，又能充分利用空闲的线程，于是做了一个“具有记忆功能的最小堆”线程池，如下图右边所示这个线程池包含两部分，一部分是记录当前正在线程上排队的请求个数的线程最小堆，一部分是记录当前正在

8小时。那么所有和时区有关的地方，都有可能成为“凶手”。如果是java写入es怎么解决时区问题？如果你使用java程序来写入es，我推荐你写入带T的时间字符串。提供程序如下：/**

前言前面我们学习过，master节点的职责有：负责决定当前某个分片要分配到哪个节点上面。在节点间移动分片，保证集群的平衡。等等。分片分配-基于集群分片分配是指将分片分配到某个主机节点上的一个过程。触发的场景有：初始化恢复分片副本分配集群平衡集群节点加入或者移除

call_list['indices'][index]['total']['indexing']['index_total']。也可以隔几分钟用CURL来粗略统计单个索引的数据量大小。命令如下：#

发现模块和集群的形成目标发现节点Master选举组成集群，在Master信息发生变化时及时更新。故障检测细分为几个子模块Discovery发现模块Discover是在集群Master节点未知时，互相发现对方的过程，例如新节点的加入或是先前的主节点宕机，如果一个节点不满足Master资格，则它将继续发现，直到发现了选定的主节点为止，其中，重试配置的属性为：discovery.findpeersinterval，默认值1s。官网上master-eligible的含义：设置了node-master：true的节点，表示有资格成为Master的节点。一、基于单播的方式发现可以在

背景运维人员反馈一个容器化的java程序每跑一段时间就会出现OOM问题，重启后，间隔大概两天后复现。问题调查一、查日志由于是容器化部署的程序，登上主机后使用docker

gen_client_node_cert的第一个参数一定要和elasticsearch.yml中配置的searchguard.authcz.admin_dn配置项下的

前言es用作海量数据和存储和检索，对于较大日志数据，如果全部存储在一个索引中，

前言记录当生产机器上的es索引需要增加字段，修改索引类型，并且要求不重启es集群时，可以使用别名进行索引重建。过程首先假设我们已经有一个索引名为student_v1,我们得先给他创建一个别名，操作如下：curl