XLog

专栏目录 是时候升级java11了-01-jdk11优势和jdk选择 是时候升级java11了-02-升级jdk11踩坑记 是时候升级java11了-03虚拟机Jvm参数设置 是时候升级java11了-04微服务内http2通信之http2 Clear Text（h2c） 是时候升级java11了-05微服务内h2c通信的阻碍和问题解决 前言 紧接前2篇文章，我们今天来聊聊升级 Java11 之后的一写 Jvm 参数变化。Java11 删除掉了 cms 垃圾回收器，如果你升级到了 Java11 但是 Jvm 参数仍然使用 cms 垃圾回收器参数时控制台会报错，甚至会启动失败。 OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. Unrecognized VM option 'ParallelCMSThreads=2' Did you mean 'ParallelGCThreads=<value>'? Error: Could not create the Java Virtual Machine. Error: A fatal exception has

一、什么是System.gc()？ System.gc() 是用Java，C＃和许多其他流行的高级编程语言提供的API。当它被调用时，它将尽最大努力从内存中清除垃圾（即未被引用的对象）。名词解释：GC，Garbage Collection，垃圾回收，下文会经常使用。 二、谁可以调用System.gc()？ System.gc() 可以从应用程序堆栈的各个部分调用： 您自己开发的应用程序可以显式的调用 System.gc() 方法。 System.gc() 也可以由您的第三方库，框架触发。 可以由外部工具（如VisualVM）通过使用JMX触发 如果您的应用程序使用了RMI，RMI会定期调用 System.gc() 。 三、调用System.gc()有什么弊端？ 当 System.gc() 或 Runtime.getRuntime().gc() API被调用时，将触发完整的GC事件。在GC完成之前，整个JVM将冻结（即正在运行的所有服务将被暂停），通常完整的GC需要很长时间才能完成。因此在不合适的时间运行GC，将导致不良的用户体验，甚至是崩溃。 JVM具有复杂的算法，该算法始终在后台运行，进行所有计算以及有关何时触发GC的计算。当您显式调用System.gc()调用时，所有这些计算都将被抛掉。 四、哪些场景适合显式调用System.gc()？ GC操作应该由JVM自行控制

导读： postgres预写式日志的内核实现详解-概述 heap2(RM_HEAP2_ID)是数据库对heap的修改产生的wal记录（heap除去），如下为heap2类型的wal子类型 #define XLOG_HEAP2_REWRITE 0x00 #define XLOG_HEAP2_CLEAN 0x10 #define XLOG_HEAP2_FREEZE_PAGE 0x20 #define XLOG_HEAP2_CLEANUP_INFO 0x30 #define XLOG_HEAP2_VISIBLE 0x40 #define XLOG_HEAP2_MULTI_INSERT 0x50 #define XLOG_HEAP2_LOCK_UPDATED 0x60 #define XLOG_HEAP2_NEW_CID 0x70 XLOG_HEAP2_MULTI_INSERT 这种wal子类型在copy命令向表中插入数据时产生。代码在heap_multi_insert()函数中。redo函数为heap_xlog_multi_insert()。 描述结构体 typedef struct xl_heap_multi_insert { uint8 flags; uint16 ntuples; OffsetNumber offsets[FLEXIBLE_ARRAY_MEMBER]; } xl

导读： postgres预写式日志的内核实现详解-概述 XLOG(RM_XLOG_ID)日志类型记录很杂乱，如下为XLOG类型的wal子类型。 /* XLOG info values for XLOG rmgr */ #define XLOG_CHECKPOINT_SHUTDOWN 0x00 #define XLOG_CHECKPOINT_ONLINE 0x10 #define XLOG_NOOP 0x20 #define XLOG_NEXTOID 0x30 #define XLOG_SWITCH 0x40 #define XLOG_BACKUP_END 0x50 #define XLOG_PARAMETER_CHANGE 0x60 #define XLOG_RESTORE_POINT 0x70 #define XLOG_FPW_CHANGE 0x80 #define XLOG_END_OF_RECOVERY 0x90 #define XLOG_FPI_FOR_HINT 0xA0 #define XLOG_FPI 0xB0 XLOG_CHECKPOINT_SHUTDOWN和XLOG_CHECKPOINT_ONLINE 在数据库关机时会首先执行一次checkpoint，XLOG_CHECKPOINT_SHUTDOWN类型就是记录关机checkpoint

目前PostgreSQL已经出了PG11Beta2版本，细心的朋友可能已经发现，PG9.x及之前版本的xlog做了一些改动，在10以后的版本，xlog改成了wal，官方出于安全性的考虑做出了该改动。 随着这些变化，有一些基于xlog的监控也需要随之修改，比如对replication slot size的监控。 在9.x版本里面可以通过以下语句进行监控： SELECT pg_xlog_location_diff(pg_current_xlog_location(), restart_lsn) FROM pg_replication_slots WHERE slot_name = 'SLOT NAME'; 在10.x以后的版本里，location修改为lsn，xlog修改为wal，所以语句也随之修改为： SELECT pg_wal_lsn_diff(pg_current_wal_insert_lsn(), restart_lsn) FROM pg_replication_slots WHERE slot_name = 'SLOT NAME'; ～～如果感觉对您有用，请打赏支持一下～～ 来源： oschina 链接： https://my.oschina.net/u/592434/blog/1852996