服务器硬件有没有问题，网络、存储、内存、CPU情况有没有问题。如果有普罗米修斯、zabbix监控，可以直接查看监控，如果没有则需要进入服务器进行定位。
Redis 作为当下最热门的 Key-Value 存储系统，在大大小小的系统中都扮演着重要的角色，不管是 session 存储还是热点数据的缓存，亦或是其他场景，我们都会使用到 Redis。在生产环境我们偶尔会遇到 Redis 服务器内存不够的情况，那对于这种情况 Redis 的内存是如何回收处理的呢？另外对于带有过期时间的 Key Redis 又是如何处理的呢？
墨墨导读：本文出自墨天轮“每日一练”专栏，此专栏已连更84天，欢迎关注https://www.modb.pro/topic/26446(复制到浏览器中打开或者点击“阅读原文”直达)，本文主要描述实例优化中内存的管理。
需求： 📷 解答： 导入相关的pom.xml 然后给配置： 📷 📷 最后在给上api: Properties info = stringRedisTemplate.getRequiredConnectionFactory().getConnection().info("memory"); 可选参数： server：有关Redis服务器的常规信息 clients：客户端连接部分 memory：内存消耗相关信息 persistence：RDB和AOF相关信息 s
其实说到对JVM进行性能调优早已是一个老生常谈的话题，如果你所在的技术团队还暂时达不到淘宝团队那样的高度，无法满足在OpenJDK的基础之上根据自身业务进行针对性的二次开发和定制调优，那么对于你来说，唯一的选择就是尽可能的熟悉JVM的内存布局，以及熟练掌握与GC相关的那些选项配置，否则JVM的基础性能调优不是痴人说梦？
Hypervisor 的概念 Hypervisor 是一种运行在基础物理服务器和操作系统之间的 中间软件 层 , 可允许多个操作系统和应用共享硬件。Hypervisor 不但协调着这些硬件资源的访问，
任何新的业务系统在上线以前都需要去估算服务器配置和 JVM 的内存参数，这个容量与资源规划并不仅仅是系统架构师的随意估算的，需要根据系统所在业务场景去估算，推断出来一个系统运行模型，评估 JVM 性能和 GC 频率等等指标。
Linux服务器配置文档找不到，你还在为查询Linux服务器硬件信息发愁吗？学会这些命令，让你轻松查看Linux服务器的CPU，内存，硬盘，SN序列号等信息，根本就不用去机房。
JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，
用了很久的Tomcat，没怎么看过它的优化，今天抽出时间研究了下，将内容记录下。 首先，是客户端访问tomcat的一个过程，如图所示： 图中间虚线框部分是 Apache基金下的服务器来做静态资源处理
不同的业务，设计也不尽相同，但至少都一些共同的追求，比如性能。 做服务器开发很多年了，有时候被人问到，服务器性能是什么呢？各种服务器间拼得是什么呢？ 简单的回答就是QPS，并发数，但有时候想想也许也不对。 QPS与并发数是针对同样的业务而言的，业务不同，相同的服务器能承受的压力也会不同。 性能，也许可以打个俗点的比方： 服务器就是一艘船，性能就是船的容量，开的速度，行得是否稳当。 该用的用，该省的省。能用内存就别用IO，CPU则能少用就少用，相同的QPS，CPU和内存用的少点的性能就要比用的多点好，同样，Q
如果不设置最大内存大小或者设置最大内存大小为0，在64位操作系统不限制内存大小，在32位操作系统下最多3g
通常， -Xms 和 -Xmx 设置成一样的，避免每次垃圾回收完成后JVM重新分配内存。因为当Heap不够用时，发生内存抖动，影响程序运行稳定性。
> info memory 指标 含义 used_memory 由 Redis 分配器分配的内存总量，包含了redis进程内部的开销和数据占用的内存，以字节（byte）为单位，即当前redis使用内存大小。 used_memory_human 已更直观的单位展示分配的内存总量。 used_memory_rss 向操作系统申请的内存大小，与 top 、 ps等命令的输出一致，即redis使用的物理内存大小。 used_memory_rss_human 已更直观的单位展示向操作系统申请的内存大小。 used_m
通过这一个多月的努力，将FullGC从40次/天优化到近10天才触发一次，而且YoungGC的时间也减少了一半以上，这么大的优化，有必要记录一下中间的调优过程。
导读：本文记录一次线上JVM调优实践，FullGC40次/天到10天一次的优化过程，总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。
Redis在我们日常开发中是经常用到的，Redis也是功能非常强大，可以进行缓存，还会有一些排行榜、点赞、消息队列、购物车等等；当然还有分布式锁Redisson，我们使用肯定少不了集群！小编最近学习到一些内存如果满了Redis是怎么操作呢？肯定像我们JVM一样，有回收或者淘汰的机制！今天小编和大家一起学习一下，小编也是看了阳哥的课，觉得讲的很好，记录一下，希望可以帮助到大家！！
系统性能一直是一个受关注的话题，如何通过最简单的设置来实现最有效的性能调优，如何在有限资源的条件下保证程序的运作，ulimit 是我们在处理这些问题时，经常使用的一种简单手段。ulimit 是一种 linux 系统的内键功能，它具有一套参数集，用于为由它生成的 shell 进程及其子进程的资源使用设置限制。
/proc/279/status是一个Linux内核中的文件，其中包含了当前进程的状态信息。每行的含义如下：
通过ulimit -n命令可以查看Linux系统里打开文件描述符的最大值，一般缺省值是1024，对一台繁忙的服务器来说，这个值偏小，所以有必要重新设置linux系统里打开文件描述符的最大值。那么应该在哪里设置呢？
上周知识星球的同学在阿里云技术面终面的时候被问到这么一个问题：假设一个每天100w次登陆请求的平台，一个服务节点 8G 内存，该如何设置JVM参数？ 觉得回答的不太理想，过来找我复盘。
做java开发以来，有一个问题一直萦绕在脑海，那就是java程序为什么会占用那么多的虚拟内存。之前也没有深究，因为服务器内存够大。但是最近用上了docker容器，每个容器基本上就几个GB的内存，内存占用过大的问题必须得解决了。
在实际的业务场景中，我们往往倾向于认为容器环境与虚拟机一样，可以完全自定义不同参数的虚拟 CPU 和虚拟 Memory 资源。其实，从本质上而言，容器更倾向于一种隔离机制环境，其中一个进程的资源（ CPU、内存、文件系统、网络等）与另一个进程隔离。这种隔离是可能的，因为 Linux 内核中有一个名为 CGroups 的特性。然而，一些从执行环境收集信息的应用程序在 CGroup 存在之前就已经实现了。像大多数常用的命令行 “top”、“free”、“ps” 等诸如此类的工具，甚至 JVM 都没有针对在容器内执行进行优化，毕竟，容器是一个高度受限的 Linux 进程。
当我们将 JVM 生态中的关键要素，例如，垃圾收集器、堆大小和运行时编译器设置默认值时，许多技术人员（开发、运维人员）或许应该意识到在 Linux 容器生态中（诸如，Docker、Rkt、RunC、Lxcfs 等）内所运行的 Java 进程的实际行为与预期不符。当我们在没有任何调优参数（例如，最为简洁的的启动命令行：“ java -jar myapplication .jar”）的情况下执行 Java 应用程序时，JVM 将自行调整某些特定的参数，以在当前执行环境中获得最佳性能表现。
GC 优化的基本原则是：将不同的 GC 参数应用到两个及以上的服务器上然后比较它们的性能，然后将那些被证明可以提高性能或减少 GC 执行时间的参数应用于最终的工作服务器上。
最近一直在做性能压测相关的事情，有公众号的读者朋友咨询有赞的数据库服务器有没有开启huge page，我听说过huge page会对性能有所提升，本文就一探究竟。对过程没有兴趣的可以直接看结论。
在$CATALINA_HOME/conf/server.xml配置文件中的Connetctor节点，和连接数相关的参数配置和优化。
公众号改版后文章乱序推荐，希望你可以点击上方“Java进阶架构师”，点击右上角，将我们设为★“星标”！这样才不会错过每日进阶架构文章呀。
HugePage，就是指的大页内存管理方式。与传统的4kb的普通页管理方式相比，HugePage为管理大内存(8GB以上)更为高效。本文描述了什么是HugePage，以及HugePage的一些特性。
这篇文章其实之前发过，但是最近有位读者跟我反馈，我文章中的实验在 64 位操作系统、2 G 物理内存的场景，申请 8G 内存是没问题的，而他也是这个环境，为什么他就无法申请成功呢？
当我们公司使用tomcat作为web应用服务器的规模越来越大,为保证Tomcat配置安全,防止信息泄露,恶意攻击以及配置的安全规范,特制定此Tomcat安全配置规范.本文章从别处转载并做了补充
腾讯云 Serverless 云函数 SCF 现支持分配 120GB(122,880MB) 大内存环境，可以更加轻松地处理具有更高内存或更密集计算需求的工作负载，如音视频处理、大数据分析、大型文件处理、统计计算以及 AI 推理等多种场景。 01. 功能介绍 在腾讯云 Serverless 云函数资源模型中，可以选择用于函数的内存量，这会分配等比例的 CPU 计算能力和其他资源。意味着在选择新的较大设置时，可以使用更多计算能力。可以指定函数运行时可用的内存大小，最小 64MB ，最大 122,880MB(1
Tomcat的连接数主要受几个参数的影响:1. acceptCount:指定Tomcat接收请求的最大队列数,默认值为100。这是因为Tomcat的连接器(Connector)将接收到的请求放入队列进行处理,当队列满时新请求会被拒绝。将acceptCount的值增加可以加大链接请求队列的大小,接纳更多连接。2. maxConnections:指定最大连接数,默认值为10000。当Tomcat正在处理的连接达到这个值时,新的连接请求会被拒绝。增大这个值可以增加Tomcat的最大连接数。3. maxThreads:指定最大线程数,默认值为200。由于每个连接都需要一个线程来处理,当线程数达到maxThreads时新连接无法被处理,会被拒绝。增大maxThreads值也可以增加最终的连接数。所以,可以通过调整以上3个参数来加大Tomcat的连接数:1. 增大acceptCount值,扩大连接请求队列,避免连接请求被拒绝,如:
以上两类Container可能在任意节点上，它们的位置通常而言是随机的，即ApplicationMaster可能与它管理的任务运行在一个节点上。
但凡初次接触MongoDB的人，无不惊讶于它对内存的贪得无厌，至于个中缘由，我先讲讲Linux是如何管理内存的，再说说MongoDB是如何使用内存的，答案自然就清楚了。
看着面试官真诚的眼神，心中暗想看起来年纪轻轻却提出如此直击灵魂的问题。擦了擦额头上汗，我稍微调整了一下紧张的情绪，对面试官说：
了解Redis的info 要获得Redis的当前情况，使用info命令即可。具体用法：redis-cli -h 127.0.0.1 -p 6379 -a redis_passwd info [参数] 。针对不同的参数就会看到具体的数字，如果没有带参数，那么就会把默认情况写出来，如果带上all参数，那么就会把所有情况都写出来。比如：redis-cli -h 127.0.0.1 -p 6379 -a redis_passwd info server，就会看到redis关于server的一些数据，如下：
作为一个前端工程师，大家日常也会维护一些 Node.js 服务，对于一个服务我们首先要关注的就是它的稳定性，可能大部分同学对服务端的很多概念不会理解的特别深刻，所以在稳定性上面也不知道去关注什么。
大家都清楚Redis内存占用情况：与存储的数据量、配置参数、服务器内存大小等因素有关。在默认情况下，Redis 会使用尽可能多的内存，直到服务器的内存资源被占满。
我们知道，java进程中的线程，是直接映射到服务的线程上，当创建的线程过多时，创建线程会失败，现象如下:
熊军（老熊） 云和恩墨西区总经理 Oracle ACED，ACOUG核心会员 PC Server发展到今天，在性能方面有着长足的进步。64位的CPU在数年前都已经进入到寻常的家用PC之中，更别说是更高端的PC Server；在Intel和AMD两大处理器巨头的努力下，x86 CPU在处理能力上不断提升；同时随着制造工艺的发展，在PC Server上能够安装的内存容量也越来越大，现在随处可见数十G内存的PC Server。正是硬件的发展，使得PC Server的处理能力越来越强大，性能越来越高。而在稳定性
平时我们经常需要监控内存的使用状态，常用的命令有free、vmstat、top、dstat -m等。
根据 CPU 访问内存中地址所需时间和距离我们可以将CPU和内存结构分为SMP（SMP，Symmetric Multi-Processor，也称之为一致内存访问UMA）、NUMA和MPP(Massive Parallel Processing)三种结构。而我们在虚拟化环境中常用的结构包括SMP和NUMA这两种。相对SMP(UMA）来说，NUMA具有更加好的扩展性。NUMA将CPU和相近的内存配对组成节点，在每个NUMA节点里，CPU都有本地内存，访问距离短，性能好。NUMA比SMP具有更好的扩展性，SMP使用共享内存控制器，所有的CPU使用共享内存总线访问内存，如图1所示。在CPU不多的时候，SMP可以很好地工作，但是一旦CPU的数量很大的时候，这些 CPU 既可能造成内存总线的压力，也可能发生CPU之间相互“争夺”对共享内存总线的访问。NUMA采用分组的形式，限制一个NUMA节点里面的CPU数量和内存大小，并使用缓存一致性内部连接总线将各个NUMA节点连接起来，如图2所示。在服务器CPU日益增多和虚拟化普及的时代，NUMA更能适应高密度虚拟化环境的要求。
起因是：前几年我在老家郑州实习面试(那个时候还没有毕业)的时候遇到面试官提问；面试官来于百度总部的工程师6年java开发经验+3年多的PHP开发经验，我在他的面前基本就是弟弟中的弟弟，虽然勉强通过入职了，但是却被运维无情地嘲笑，就因为组长让我上机看下redis的基础情况，我不会，问了运维。一怒之下，我当天晚上就恶补了一波......，到现在都还记着
1.生产者压力测试 [shsxt@hadoop002 kafka]$ bin/kafka-producer-perf-test.sh --topic test --record-size 100 --num-records 100000 --throughput -1 --producer-props bootstrap.servers=hadoop002:9092,hadoop003:9092,hadoop004:9092 100000 records sent, 31486.146096 records/sec (3.00 MB/sec), 1374.63 ms avg latency, 1699.00 ms max latency, 1469 ms 50th, 1666 ms 95th, 1694 ms 99th, 1698 ms 99.9th.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
