checkpoint

postgresql的内存分配主要由 shared_buffers、temp_buffers、work_mem、maintenance_work_mem 参数控制。 shared_buffers 又可以叫做共享缓冲区， postgresql对数据操作时都要先将数据从磁盘读取到内存中，然后进行更新，最后再将数据写回磁盘。shared_buffers的功能就是用于存放从磁盘读取的数据。根据文档参数的设置范围一般在25%~40%之间 。windows与linux对内存的管理方式不同，在linux中需要注意共享段大小的设置(kernel.shmmax)。 temp_buffers 称之为临时缓冲区，用于数据库会话访问临时表数据，系统默认值为8M。可以在单独的session中对该参数进行设置，尤其是需要访问比较大的临时表时，将会有显著的性能提升。 work_mem 可以称之为工作内存或者操作内存。其负责内部的sort和hash操作，合适的work_mem大小能够保证这些操作在内存中进行。定义太小的话，sort或者hash操作将需要与硬盘进行swap，这样会极大的降低系统的性能；太大的话致使在能够在内存中完成的操作数量减少，其他的部分需要与磁盘进行swap操作，增加IO降低性能 。系统提供的默认值是1M，在实际的生产环境中，要对系统监控数据进行分析，作出最好的选择。 大致有两种方式

如何分析及处理 Flink 反压？ 反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为瓶颈，处理速率跟不上上游发送数据的速率，而需要对上游进行限速。由于实时计算应用通常使用消息队列来进行生产端和消费端的解耦，消费端数据源是 pull-based 的，所以反压通常是从某个节点传导至数据源并降低数据源（比如 Kafka consumer）的摄入速率。 关于 Flink 的反压机制，网上已经有不少博客介绍，中文博客推荐这两篇1。简单来说，Flink 拓扑中每个节点（Task）间的数据都以阻塞队列的方式传输，下游来不及消费导致队列被占满后，上游的生产也会被阻塞，最终导致数据源的摄入被阻塞。而本文将着重结合官方的博客[4]分享笔者在实践中分析和处理 Flink 反压的经验。 反压的影响 反压并不会直接影响作业的可用性，它表明作业处于亚健康的状态，有潜在的性能瓶颈并可能导致更大的数据处理延迟。通常来说，对于一些对延迟要求不太高或者数据量比较小的应用来说，反压的影响可能并不明显，然而对于规模比较大的 Flink 作业来说反压可能会导致严重的问题。 这是因为 Flink 的 checkpoint 机制，反压还会影响到两项指标: checkpoint 时长和 state 大小。 前者是因为 checkpoint barrier

tf用 tf.train.Saver类来实现神经网络模型的保存和读取。无论保存还是读取，都首先要创建saver对象。 用saver对象的save方法保存模型 保存的是所有变量 save( sess, save_path, global_step=None,　　 latest_filename=None, meta_graph_suffix='meta', write_meta_graph=True, write_state=True ) 保存模型需要session，初始化变量 用法示例 import tensorflow as tf v1 = tf.Variable(tf.constant(1.0, shape=[1]), name="v1") v2 = tf.Variable(tf.constant(2.0, shape=[1]), name="v2") result = v1 + v2 saver = tf.train.Saver() with tf.Session() as sess: sess.run(tf.global_variables_initializer()) saver.save(sess, "Model/model.ckpt", global_step=3) 输出 1. global_step 放在文件名后面，起个标记作用 2. save方法输出4个文件 　　

转自 http://blog.csdn.net/indexman/article/details/7746948 以下易容翻译自oracle dba官方文档，不足之处还望指出。 管理重做日志文件 学习目标： 1.解释重做日志文件的目的 2.描述重做日志文件的结构 3.学会控制日志切换与检查点 4.多元化管理重做日志文件 5.使用OMF管理重做日志文件 1.概念介绍： 重做日志文件通过记录数据的所有改变情况对系统或介质故障提供恢复机制。 1）重做日志文件以组的形式存在 2）一个oracle数据库至少需要两组,每组至少有一文件 3）在一组里的每一重做日志文件叫做成员 The redo log files are used only for recovery. 2.重做日志文件结构： 1）重做日志文件组 a.一组相同的副本联机重做日志文件被称为一个联机重做日志组。 b.LGWR进程并发的往日志组里所有重做日志文件写入相同信息 2）重做日志文件 a.一个组每个成员用于同一log sequence numbers和相同的大小 b.每次oracle服务器开始写入日志组时分配日志序列号来唯一标识每个重做日志文件 c.当前的日志序列号存储在控制文件和所有数据文件的头部 3.重做日志如何工作？ 1）重做日志以循环的方式使用 2）当一个重做日志文件写满，LGWR进程将移动到下一日志组 a

文章目录 1. Streaming Connectors 预定义的 source 和 sink Boundled connectors Apache Bahir 中的连接器 异步 IO 2. Flink Kafka Connector 2.1 Flink Kafka Consumer 1）反序列化 2）消费起始位置设置 3）topic 和 partition 动态发现 4）commit offset 方式 5）Timestamp Extraction/Watermark 生成 2.2 Flink Kafka Producer 1）Producer 写出时的 Partition 分区 2）Producer 容错 3. Q&A 1. Streaming Connectors Connector 的作用就相当于一个连接器，连接 Flink 计算引擎跟外界存储系统。 目前常用的 Connector 有以下几种： 预定义的 source 和 sink 基于文件的 source 和 sink // 从文本文件中读取数据 env . readTextFile ( path ) ; // 以文本的形式读取该文件中的内容 env . readFile ( fileInputFormat , path ) ; // 将结果已文本格式写出到文件中 DataStream . writeAsText (

本博客内容主要讲解: Flink消费Kafka数据写入MySQL模拟Flink端到端精准一次消费 1. 模拟 kafka数据没1s产生一条,产生60条; 2. Flink 消费Kafka,每10一次检查点; 3. 消费到第15条(前面产生一个检查点,不一定是在消费到第10条,因为第一个10s开始时间不一定是从第一条开始算)设置异常数据,数据不会插入 4. 修正异常数据,重启应用程序,Flink重新消费Kafka,数据全部落入MySQL,没有重复,也没有丢失 Exactly-Once 语义 Exactly-Once 语义指每个数据输入端的事件只能影响最终结果一次.解释机器出现故障,数据既没有重复,也没有丢失 CheckPoint: 一次CheckPoint进行一次快照;容包含以下内容 应用程序的当前状态 输入流位置 在 Flink 1.4.0 之前，Exactly-Once 语义仅限于 Flink 应用程序内部，并没有扩展到 Flink 数据处理完后发送的大多数外部系统。Flink 应用程序与各种数据输出端进行交互，开发人员需要有能力自己维护组件的上下文来保证 Exactly-Once 语义。 模拟 Kafka->Flink->MySQL 端到端 精准一次消费 主要代码 代码1 package com.huonan.twocommit; import lombok.extern

InnoDB存储引擎 mysql 存储引擎（好难用，看 https://www.zybuluo.com/eqyun/note/27850 ） 简介 InnoDB是事务安全的MySQL存储引擎，从MySQL5.5版本开始是默认的表存储引擎，是第一个完整支持 ACID事务 的MySQL存储引擎，其特点是行锁设计、支持MVCC、支持外键、提供一致性锁定读，同时被设计用来最有效地利用以及使用内存和CPU InnoDB存储引擎体系架构 后台线程(多个)->InnoDB存储引擎内存池->物理文件 后台线程 1. Master Thread 核心的后台线程，负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性，包括脏页的刷新、合并插入缓冲(INSERT BUFFER)、 UNDO页的回收等 2. IO Thread 在InnoDB中大量使用了AIO（Async IO）来处理IO 请求，IO Thread主要是负责这些IO请求的回调处理。Io Thread共有4类： write 、 read 、 insert buffer 和 log IO thread 。在InnoDB 1.0.x 版本开始，read thread和write thread分别增加大4个，用 innodb_file_io_threads 和 innodb_write_io_threads 参数来设置，如 可以看到thread

1.什么是 checkpoint checkpoint 是数据库的一个内部事件，检查点激活时会触发数据库写进程 (DBWR) ，将数据缓冲区里的脏数据块写到数据文件中。 其作用有两个方面： 1 ） 保证数据库的一致性 ，这是指将脏数据从数据缓冲区写出到硬盘上，从而保证内存和硬盘上的数据是一致的。 2 ） 缩短实例恢复的时间 ，实例恢复时，要把实例异常关闭前没有写到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会过长，检查点的发生可以减少脏块的数量，从而减少实例恢复的时间。 2.检查点分类 ①完全检查点 full checkpoint ②增量检查点 incremental checkpoint ③局部检查点 partial checkpoint 2-1.完全检查点工作方式： 记下当前的 scn, 将此 scn 之前所有的脏块 一次性 写完，再将该 scn 号同步更新 控制文件 和 数据文件头 。 触发完全检查点的四个操作 ①正常关闭数据库 :shutdown immediate ②手动检查点切换 :alter system checkpoint; ③日志切换 ： alter system switch logfile; ## 滞后触发 dbwr，先记后写 ④数据库热备模式： alter database begin backup; 示例 1 ： 验证以上概念可以做一下

Checkpoint Flink容错机制的核心就是持续创建分布式数据流及其状态的一致快照。Flink的checkpoint是通过分布式快照实现的， 所以在flink中这两个词是一个意思。 checkpoint用来保证任务的错误恢复。任务失败可以从最新的checkpoint恢复。 checkpoint机制需要一个可靠的可以回放数据的数据源（kafka，RabbitMQ，HDFS...）和一个存放state的持久存储（hdfs，S3） 1、checkpointConfig 通过调用StreamExecutionEnvironment.enableCheckpointing(internal,mode) 启用checkpoint 。 internal 默认是 -1，表示checkpoint不开启，mode默认是EXACTLY_ONCE模式。 可设置checkpoint timeout，超过这个时间 checkpoint 没有成功，checkpoint 终止。默认 10分钟。 可设置 chekpoint 失败任务是否任务也失败，默认是true 可设置同时进行的checkpoint数量，默认是1. 2、barrier 将barrier插入到数据流中，作为数据流的一部分和数据一起向下流动。Barrier不会干扰正常数据，数据流严格有序。 一个barrier把数据流分割成两部分

简介 RDD（Resilient Distributed Dataset）叫做弹性分布式数据集，是Spark中最基本的数据抽象，它代表一个不可变、可分区、里面的元素可并行计算的集合。 　　Resilient：弹性，它表示的含义rdd的数据是可以保存在内存中或者是磁盘中。 　　Distributed：它的数据是分布式存储的，后期方便于进行分布式计算。 　　Dataset：它就是一个集合，集合里面可以存放了很多个元素。 RDD的属性 1 A list of partitions 一个分区列表，在这里表示一个rdd中有很多个分区(partitions)，Spark任务的计算以分区为单位，每一个分区就是一个task。读取hdfs上文件产生的RDD分区数跟文件的block个数相等 rdd1=sc.textFile("/words.txt") 2 A function for computing each split Spark中RDD的计算是以分区为单位的，每个RDD都会实现compute函数以达到这个目的。compute函数会对迭代器进行复合，不需要保存每次计算的结果。 3 A list of dependencies on other RDDs 一个RDD会依赖于其他多个RDD,这里就涉RDD之间的依赖关系，RDD的每次转换都会生成新的RDD，Spark任务的容错机制就是根据这个特性而来