android网站开发实例,国家学历提升官网,手机设计软件app哪个好,郑州seo网站关键词优化监控指标介绍
服务器监控
CPU状态#xff1a;cpu使用率、负载 内存状态#xff1a;应用内存使用率、物理内存使用量 磁盘状态#xff1a;分区大小、使用趋势 IO状态#xff1a;IOPS、MBPS、每秒读写速率、await 网卡状态#xff1a;网络出入流量Bps、pps、丢包率、TCP状…监控指标介绍
服务器监控
CPU状态cpu使用率、负载 内存状态应用内存使用率、物理内存使用量 磁盘状态分区大小、使用趋势 IO状态IOPS、MBPS、每秒读写速率、await 网卡状态网络出入流量Bps、pps、丢包率、TCP状态、网络连接
数据库监控
慢sql 异常死锁 Druid连接池 等待线程数
案例介绍
应用内存飚高
案例1通过数据库一次查询量太大(伴随慢sql), 一次加载到应用内存处理。
修复数据库分页查询处理增加limit
案例2部署应用后观测到应用内存持续上涨是否有风险
Java进程占用内存后即使GC回收了也不会立即降低这是因为Java虚拟机的内存管理机制。
Java虚拟机采用的是分代垃圾回收策略将内存分为年轻代和老年代。年轻代又分为Eden区和两个Survivor区S0、S1。 当Java程序运行时对象会被分配在Eden区中。当Eden区满时会触发一次MinorGC将不再使用的对象回收掉然后存活下来的对象会被移动到Survivor区S0中。 等Eden区再满了就再触发一次Minor GCEden和S0中的存活对象又会被复制送入第二块survivor space S1这个过程非常重要因为这种复制算法保证了S1中来自S0和Eden两部分的存活对象占用连续的内存空间避免了碎片化的发生碎片化带来的风险是极大的严重影响JAVA程序的性能。S0和Eden被清空然后下一轮S0与S1交换角色如此循环往复。如果对象的复制次数达到16次该对象就会被送到老年代中。
在这个过程中如果某个对象在年轻代中存活的时间很长就会被移动到老年代中。而老年代中的对象只有在Full GC时才会被回收。
因此如果Java进程中的对象大部分都在老年代中那么即使进行了多次Minor GC也不会释放掉这些对象占用的内存只有进行Full GC时才能释放。 如果 Full GC 的频率过高就可能会导致系统性能下降因为它会占用大量的 CPU 时间和内存资源。因此需要对 Full GC 的频率进行监控和调优以保证系统的正常运行。 频繁的full gc可能是由于以下原因导致的
内存泄漏如果应用程序存在内存泄漏那么就会导致内存中的对象无法被垃圾回收器清理最终导致内存溢出触发full gc。对象生命周期过长如果应用程序中的对象生命周期过长那么就会导致这些对象长时间占用内存最终导致内存溢出触发full gc。堆内存设置不合理如果堆内存设置过小那么就会导致内存不足触发full gc。如果堆内存设置过大那么就会导致full gc的频率增加因为垃圾回收器需要更长的时间来扫描整个堆内存。大对象如果应用程序中存在大对象那么就会导致内存中的碎片增加最终导致内存不足触发full gc。过多的对象创建如果应用程序中频繁地创建对象那么就会导致内存中的对象数量增加最终导致内存不足触发full gc。
JVM调优: Java虚拟机中有Xmx和Xms参数 分别用于设置Java虚拟机JVM的最大堆内存和初始堆内存大小启动时分配的最小内存。
-Xmx参数用于设置JVM的最大堆内存大小格式为-Xmx[g|G|m|M|k|K]其中表示最大堆内存大小单位可以是GB、MB或KB。 -Xms参数用于设置JVM的初始堆内存大小格式为-Xms[g|G|m|M|k|K]其中表示初始堆内存大小单位可以是GB、MB或KB。
通常情况下Xmx和Xms参数应该设置为相同的值以避免JVM在运行时不断地调整堆内存大小从而影响应用程序的性能。同时应该根据应用程序的内存需求和可用系统资源来合理地设置这两个参数。如果程序一直运行那么Java进程的内存占用量会逐渐增加但不会低于-Xms参数指定的值。因此如果程序需要占用大量内存可以适当增加-Xms参数的值这样可以避免频繁的内存分配和回收提高程序的性能。
案例3应用日志存在了系统内存中看到应用内存偏高
// 查看used内存
# free -g total used free shared buff/cache available
Mem: 16 13 2 0 1 2// 查看java应用的最大堆内存
# ps -ef |grep java |grep Xmx
... -Xmx8192m ...// 查看相差了5G最终发现有日志生成在run目录下
# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 16G 5G 11G 45% /runtmpfs是一种基于内存的文件系统它将一部分系统内存作为文件系统的存储空间可以用来存储临时文件和缓存数据等。 在Linux系统中tmpfs默认挂载在/run目录下因此如果应用程序在/run目录下生成了大量的日志文件那么这些文件的大小就会被计算在tmpfs的使用量中。 由于tmpfs是基于内存的文件系统因此它的使用量也会被计算在系统的内存使用量中从而导致应用程序的内存使用率看起来比实际情况要高。
修改方案 1修改日志路径 2限制日志大小如以下是常见的/etc/systemd/journald.conf配置选项及其示例说明
将journal日志文件存储在特定目录下
Storageauto
SystemMaxUse50M
SystemKeepFree100M
SystemMaxFileSize10M这个示例将journal日志文件存储在默认的/var/log/journal目录下并限制了系统磁盘上journal文件占用空间不超过50MB至少保留100MB的可用空间。同时还限制单个journal文件大小不超过10MB。
cpu飚高
案例1parallelStream导致cpu飙升
修复使用字典树代替parallelStream通过线程池进行管理 另外可以在方法上增加 Transactional(propagation Propagation.NOT_SUPPORTED) 作用是将当前方法设置为不支持事务即当前方法不会参与到任何事务中这种设置通常用于一些只读操作或者不需要事务支持的操作。例如在查询操作中如果使用事务会占用更多的系统资源而且可能会导致锁定表或行影响系统的并发性能。因此将查询操作设置为不支持事务可以提高系统的并发性能和响应速度。
