希望这期不要掉粉，因为在说SQL SERVER 但实际上这期如果你放到所有的数据库上去看，也是有营养的，虽然放到了一般不会发文的周六，也没想有多少观众，就当自己对某些东西的回顾和反思。
每种数据库本身都有自身的特性,同时面临的业务不同,也会导致每种数据库需要进行调节,来满足某种业务的需求.
当看到上面的这幅图，我想你的心情一定是不怎么美好，当然如果你设置了 SWAP 倒是很难看到这幅图，但估计也不会好受多少，投诉你数据库系统缓慢的唾沫或许可以给你建一个游泳池了。
Redis的内存优化主要包括配置合理的内存上限、选择合适的回收策略以及使用内存优化工具。
爱可生 DBA 团队成员，负责项目日常问题处理及公司平台问题排查。热爱 IT，喜欢在互联网里畅游，擅长摄影、厨艺，不会厨艺的 DBA 不是好司机，didi~
今天写这篇文章的灵感，来自之前一位好友投稿的面试题：redis 的过期策略有哪些？内存淘汰机制有哪些？我将工作中遇到的问题分析，整理成一篇文章提供大家学习，希望对大家有所帮助。
但凡初次接触MongoDB的人，无不惊讶于它对内存的贪得无厌，至于个中缘由，我先讲讲Linux是如何管理内存的，再说说MongoDB是如何使用内存的，答案自然就清楚了。
大部分情况下，会杀掉导致OOM的进程，然后系统恢复。通常我们会添加对内存的监控报警，例如：当memory或swap使用超过90%时，触发报警通知，需要及时介入排查。
之前只运行 NGINX 和 FBG 棋盘游戏很稳定。接着使用 配置中心+注册中心+接口网关 取代了 NGINX，也没有出现问题。后来再加上 UAA 认证授权中心，就总是出问题。启动 UAA 之后，接口网关就挂了；再启动接口网关，UAA 就挂了，不知道什么原因。
什么是ELK STACK： ELK Stack是Elasticserach、Logstash、Kibana三种工具组合而成的一个栈。ELK可以将我们的系统日志、访问日志、运行日志、错误日志等进行统一收集、存储分析和搜索以及图形展现。相比传统的CTRL+F或者数据库语句来进行数据查询，ELK支持分布式搜搜，数据量可达PB级别，检索速度更快速，接近实时处理，并且更智能，可以去掉一些没有特殊含义的词汇，比如“这，的，是”，还可以进行搜索补全与搜索纠错（想想在百度搜索的情景） LogStash： 负责日志的收集，并且可以输出到指定位置，如Redis、kafka、以及最主要的ElasticSearch中，通常会在所有需要收集日志的服务器上安装Logstash，然后由Logstash agent端发送到Logstash的Server端 ElasticSearch： 使用JAVA开发、基于Lucene搜索引擎库的全文搜索工具，通过RESTful API（一种接口设计规范，让接口更易懂）隐藏了Lucene原本的复杂性。实现了日志数据的分布式、实时分析，并且可以进行搜索补全与纠错等功能，是ELK最核心的组件。相比MySQL库和表的概念，在ES中把库叫做索引。 Kibana： 负责数据的展示与统计，是一个图形化的管理系统 ElasticSearch概念与工作流程介： 索引（index）：文档的容器，是属性类似的文档集合，类似MySQL中的库或者表的概念，强烈建议同一类的数据放一个索引里 分片（shared）：Elasticsearch默认将创建的索引分为5个shard（也可以自定义），每一个shard都是一个独立完整的索引，然后分布在不同的节点上 节点：站在用户角度来看并没有主节点概念，每个节点对用户来说都是一样的，都会响应请求，但是对于集群来说，会有一个主节点用于管理节点状态以及决定shard分布方式，还会周期性检查其他节点是否可用并进行修复。各节点是通过集群名称来判断是否属于同一节点。 在Elasticsearch中将文档归属于一种类型type，而这些类型存在于索引index中。用MySQL来举例看看他们的对应关系： Database->Table->Row->Column Indice->Type->Document->Field 安装Elasticsearch： 1、ElasticSearch默认工作在集群模式下，扩展性很强，并且支持自动发现。所以在实验环境中需要至少2台服务器来搭建，但是为了防止脑裂，建立使用基数台服务器。在部署ElasticSearch前需要先部署JAVA环境，所以第一步是安装JDK，这里偷懒使用yum安装了openjdk，生产环境还是建议用JDK的源码包（暂时不支持JDK 9）。 yum install java-1.8.0-openjdk.x86_64 2、下载ElasticSearch，官网地址是www.elastic.co（不是com），其每个Products下都有专门的文档用于参考。 下载tar包解压，然后进入config目录，该目录下除了有一个主配置文件elasticsearch.yml需要配置外，还有一个jvm.options文件用于JVM的调优 tar zxf elasticsearch-6.3.tar.gz cd elasticsearch-6.3/config jvm.options文件主要是JVM优化相关，关于垃圾回收这块使用默认配置就可以了，我们要调整的就是最大内存和最小内存的设置。通常设置为一样大小，具体的值可以设置为系统最大内存的一半或三分之二 -Xms1g #程序启动时占用内存的大小 -Xmx1g #程序启动后最大可占用内存的大小 3、修改ElasticSearch的配置，编辑elasticsearch.yml cluster.name: my-application #集群名称，相同集群名称的节点会自动加入到该集群 node.name: r1 #节点名称，两个节点不能重复 path.data: /path/to/data #指定数据存储目录 path.logs: /path/to/logs #指定日志存储目录
早上6点，我不得不开始处理“叫醒”我的一些问题。因为当这些问题发生的时候，我的手机铃声响了。昏睡中的我非常不情愿地拿起了手机，检查我是否疯狂到将叫醒闹钟设在了早上5点。原来是监控系统发现一个Plumbr服务死掉了。
看着老徐的窘态，阿珍笑出来了声。老徐起身刚要走，阿珍一把拽住老徐，说：“跟你开玩笑呢，问你个正事，我一直分不清Java的强引用、软引用、弱引用、虚引用，给我讲讲呗。” 老徐立刻自信满满地坐下，说：“那你可问对人了，我对这方面颇有研究。这四种引用级别由高到低依次是：强引用、软引用、弱引用、虚引用。”
熟悉 Elastic Stack 的小伙伴对上面的图会感觉并不新鲜，对其中的技术栈也如数家珍，如下图一把梭走起：
这段时间服务器被大量攻击,有sql注入,有暴力破密码,有利用image漏洞的,最严重的导致访问我网站会被重定向,忍无可忍,彻底重做整个站点.本次完成将apache改为nginx,做了各种优化还有服务器迁移的事情,比较复杂.
mysql缓存机制就是缓存sql 文本及缓存结果，用KV形式保存再服务器内存中，如果运行相同的sql,服务器直接从缓存中去获取结果，不需要在再去解析、优化、执行sql。 如果这个表修改了，那么使用这个表中的所有缓存将不再有效，查询缓存值得相关条目将被清空。表中得任何改变是值表中任何数据或者是结构的改变，包括insert,update,delete,truncate,alter table,drop table或者是drop database 包括那些映射到改变了的表的使用merge表的查询，显然，者对于频繁更新的表，查询缓存不合适，对于一些不变的数据且有大量相同sql查询的表，查询缓存会节省很大的性能。
案例是一个泰国网站的生产环境（请脑补一句“萨瓦迪卡”，为了叙述方便，下文中均以"萨瓦迪卡"指代这个网站。）“萨瓦迪卡”是一个 采用 Wordpress + MySQL搭建的应用。这个遗留系统已经工作了五年。客户已经把在其它 VPS 上平移到 AWS 上。平移（lift and shift）是说原样复制，而迁移（migration）还要进行改造。而客户唯一发挥 AWS 优势的一点就是用了一个配置很高的 EC2 虚拟机 —— m4.4xlarge。这样一台配置的虚拟机有 16 个虚拟 CPU，64 GiB 的内存，以及 2000 Mbps 的网络带宽，最高 3000 IOPS 的 200GiB 的块存储设备（也就是硬盘）。
在讲解sparkStreaming优化方法之前先看几个sparkStreaming的监控指标：
新的内存模型是在这个Jira提出的，JIRA-10000，对应的设计文档在这：unified-memory-management。
比如进程的代码段、映射的文件都是file-backed，而进程的堆、栈都是不与文件相对应的、就属于匿名页。
Reids 所有的数据都是存储在内存中的，在某些情况下需要对占用的内存空间进行回收。内存回收主要分为两类，一类是 key 过期，一类是内存使用达到上限（max_memory）
我们知道，UMLK 的目的是回收内存，其通过判处一些屌丝进程（低优先级占用大内存）的死刑（Kill）来回收内存，典型的丢兵保帅策略。然而，如果kill的进程的memory回收太慢，可能就达不到目的。反而到需要使用这些被kill的进程时，需要重新load 相关的资源，从而使系统变慢。所以，回收内存的效率就至关重要。
福哥答案2021-02-01： 以下情况可能导致写操作丢失： 1、过期 key 被清理。 2、最大内存不足，导致 Redis 自动清理部分 key 以节省空间。 3、主库故障后自动重启，从库自动同步。 4、单独的主备方案，网络不稳定触发哨兵的自动切换主从节点，切换期间会有数据丢失。 *** 评论
如果不设置最大内存大小或者设置最大内存大小为0，在64位操作系统不限制内存大小，在32位操作系统下最多3g
Presto因其优秀的查询速度被我们所熟知，它本身基于MPP架构，可以快速的对Hive数据进行查询，同时支持扩展Connector，目前对Mysql、MongoDB、Cassandra、Hive等等一系列的数据库都提供了Connector进行支持。是我们常用的SQL on Hadoop的解决方案。那么我们今天就来看一下，当我们选择Presto作为我们的查询引擎之后，我们需要考虑的问题。
本文根据网上提供的一些技术方案加上自己实际开发中遇到的情况小结。 众所周知，每个Android应用程序在运行时都有一定的内存限制，限制大小一般为16MB或24MB（视手机而定）。一般我们可以通过获取当前线程的可运行内存来判断，比如系统分给当前运行内存只有16M，而你的图片就有16M，这肯定会oom的。 相关知识介绍 1.颜色模型 常见的颜色模型有RGB、YUV、CMYK等，在大多数图像API中采用的都是RGB模型，Android也是如此；另外，在Android中还有包含透明度Alpha
在回答词问题之前，首先需要回答另一个问题，就是如何设置 Redis 中数据的过期时间？
一旦内存使用达到上限，Redis会根据选定的回收策略（参见：maxmemmory-policy）删除key
1)、关于定期删除, Redis默认会每隔100ms就随机选取一些已经过期了的key，检查其是否过期，如果已经过期就删除。
前阵子处理这样一个案例，某客户的实例 mysqld 进程内存经常持续增加导致最终被 OOM killer。作为 DBA 肯定想知道有哪些原因可能会导致 OOM（内存溢出）。
从字面意思看了一下是因为slave_pending_jobs_size_max默认值为16777216（16MB），但是slave接收到的slave_pending_jobs_size_max为17085453（17M）；
redis 中可以使用 expire 命令设置一个键的生存时间,到期后 redis 会自动删除他
在使用Redis时，数据存储在内存中。当内存被占满后，就需要考虑清理一些数据，以便为新的数据腾出空间。因此，需要确定哪些数据应该被淘汰。本文将讨论数据淘汰策略。
redis是nosql(也是个巨大的map) 单线程，但是可处理1秒10w的并发（数据都在内存中）
我一台1核1G内存的VPS，最近总是出现CPU满载的情况，重启后恢复正常，过几个小时后又会满载，导致在上面运行的一些自动任务执行失败。
Java的软引用（Soft Reference）是一种引用类型，它在内存管理中起到一种重要的作用。它与其他引用类型（如强引用和弱引用）相比，具有一定的特点和用途。
每种数据库都有自己的管理内存的方法，MYSQL 管理内存（仅仅讨论 INNODB 数据库引擎）的方法大部分都关注在 innodb_buffer_pool_size 这个设置。MYSQL 本身内存管理有这么简单吗？
高并发内存池设计 高并发下传统方式的弊端 在传统C语言中，我们使用malloc、calloc、realloc、free来进行内存的申请分配与释放，函数原型如下。C++中则是new、delete。 void *malloc(size_t size); malloc在内存的动态存储区中分配了一块长度为size字节的连续区域返回该区域的首地址。 void *calloc(size_t nmemb, size_t size); 与malloc相似，参数size为申请地址的单位元素长度，nmem
面试官：Hi，上次我们聊到了Redis作为缓存的数据一致性问题，这次我们继续聊一聊Redis作为缓存的问题之内存消耗问题？
最近忙着把一个项目从MySQL迁移到MongoDB，在导入旧数据的过程中，遇到了些许波折，犯了不少错误，但同时也学到了不少知识，遂记录下来。
如下图所示,我摩恩碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存，这样，后面的请求就去缓存中读取，使得请求能够迅速响应.
1、根据java的内存模型会出现内存溢出的内存有堆内存、方法区内存、虚拟机栈内存、native方法区内存； 2、一般说的OOM基本都是针对堆内存； 3、对于堆内存溢出主的根本原因有两种 （1）app进程内存达到上限 （2）手机可用内存不足，这种情况并不是我们app消耗了很多内存，而是整个手机内存不足 4、而我们需要解决的主要是app的内存达到上限 5、对于app内存达到上限只有两种情况 （1）申请内存的速度超出gc释放内存的速度 （2）内存出现泄漏，gc无法回收泄漏的内存，导致可用内存越来越少 6、对于申请内存速度超出gc释放内存的速度主要有2种情况 （1）往内存中加载超大文件 （2）循环创建大量对象 7、一般申请内存的速度超出gc释放内存基本不会出现，内存泄漏才是出现问题的关键所在 8、内存泄漏常见场景 （1）资源对象没关闭造成的内存泄漏（如： Cursor、File等） （2）全局集合类强引用没清理造成的内存泄漏（特别是 static 修饰的集合） （3）接收器、监听器注册没取消造成的内存泄漏，如广播，eventsbus （4）Activity 的 Context 造成的泄漏，可以使用 ApplicationContext （5）单例中的static成员间接或直接持有了activity的引用 （6）非静态内部类持有父类的引用，如非静态handler持有activity的引用 9、怎么对内存进行优化呢 三个方向 （1）为应用申请更大内存，把manifest上的largdgeheap设置为true （2）减少内存的使用 ①使用优化后的集合对象，比如SpaseArray； ②使用微信的mmkv替代sharedpreference； ③对于经常打log的地方使用StringBuilder来组拼，替代String拼接 ④统一带有缓存的基础库，特别是图片库，如果用了两套不一样的图片加载库就会出现2个图片各自维护一套图片缓存 ⑤给ImageView设置合适尺寸的图片，列表页显示缩略图，查看大图显示原图 ⑥优化业务架构设计，比如省市区数据分批加载，需要加载省就加载省，需要加载市就加载失去，避免一下子加载所有数据 （3）避免内存泄漏 编码规范上： ①资源对象用完一定要关闭，最好加finally ②静态集合对象用完要清理 ③接收器、监听器使用时候注册和取消成对出现 ④context使用注意生命周期，如果是静态类引用直接用ApplicationContext ⑤使用静态内部类 ⑥结合业务场景，设置软引用，弱引用，确保对象可以在合适的时机回收 建设内存监控体系： 线下监控： ①使用ArtHook检测图片尺寸是否超出imageview自身宽高的2倍 ②编码阶段Memery Profile看app的内存使用情况，是否存在内存抖动，内存泄漏，结合Mat分析内存泄漏 线上监控： ①上报app使用期间待机内存、重点模块内存、OOM率 ②上报整体及重点模块的GC次数，GC时间 ③使用LeakCannery自动化内存泄漏分析 10、真的出现低内存，设置一个兜底策略 低内存状态回调，根据不同的内存等级做一些事情，比如在最严重的等级清空所有的bitmap，关掉所有界面，直接强制把app跳转到主界面，相当于app重新启动了一次一样，这样就避免了系统Kill应用进程，与其让系统kill进程还不如浪费一些用户体验，自己主动回收内存
默认情况下，容器是没有资源限制的，它会尽可能地使用宿主机能够分配给它的资源。Docker提供了一种控制分配多少量的内存、CPU或阻塞I/O给一个容器的方式，即通过在docker run或docker create命令时设置运行时配置的标志。
大内存云服务器是专为处理大规模数据和高负载应用而设计的服务器，其主要特点是拥有大容量的随机存储器（RAM）。这种类型的服务器通常用于需要快速、高效地处理大数据集、内存密集型任务和高性能计算的应用。以下是大内存云服务器的一些特点和优势：
Linux下的大页分为两种类型：标准大页（Huge Pages）和透明大页（Transparent Huge Pages）。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/qq_25737169/article/details/77585023
前言：众所周知，cpu，内存，磁盘是一个服务非常重要的三个核心资源，本章将介绍SQL Server 内部的内存结构和内存管理。最后给出内存在腾讯云SQL Server云数据库监控指标中的反应，帮助用户了解SQL Server云数据库的特性。
这个标题很吸引眼球实际上内容也应该很好玩. 问题的产生是最近我们在各个数据库进行数据库安装规范的事情,而在规范后,安装的第一台机器,进行压测就惨遭崩溃.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
