下载文档原格式
电脑内存占用过高的原因及解决方法在我们日常使用电脑的过程中，可能经常会遇到电脑运行缓慢、卡顿的情况，而这往往与电脑内存占用过高有关。
内存作为电脑运行程序的重要硬件支撑，一旦其占用过高，就会严重影响电脑的性能。
接下来，咱们就详细探讨一下电脑内存占用过高的原因以及相应的解决方法。
一、电脑内存占用过高的原因1、软件后台自启过多很多软件在安装时默认设置为开机自启，这些软件在后台默默运行，会占用大量的内存。
特别是一些像即时通讯软件、杀毒软件、下载工具等，即便我们没有主动使用它们，它们也会在后台持续消耗系统资源。
2、同时运行过多程序当我们同时打开多个大型程序，如多个浏览器窗口、多个图像处理软件或者多个游戏等，这些程序会同时占用内存，导致内存资源紧张。
3、浏览器插件过多现在的浏览器功能越来越丰富，但随之而来的是各种各样的插件。
过多的插件不仅会影响浏览器的运行速度，还会增加内存的占用。
4、病毒或恶意软件感染某些病毒和恶意软件会在后台悄悄运行，大量占用系统内存，甚至还可能窃取用户的个人信息。
5、系统更新或补丁安装在系统进行更新或者安装补丁后，可能会出现一些内存占用过高的情况。
这可能是由于新的系统功能或服务在后台运行导致的。
6、大型游戏或图形设计软件像一些 3D 游戏、视频编辑软件和图形设计工具等，它们对内存的需求较大，如果电脑内存本身配置较低，运行这些软件时就容易出现内存占用过高的问题。
7、虚拟内存设置不当虚拟内存是在硬盘上划出一部分空间来充当内存使用。
如果虚拟内存设置得太小，当物理内存不足时，系统无法有效地利用虚拟内存，就会导致内存占用过高。
二、解决电脑内存占用过高的方法1、关闭不必要的自启软件我们可以通过系统的任务管理器或者第三方的系统优化工具，查看并关闭那些不必要的开机自启软件。
对于一些常用软件，如果不需要其开机自启，也可以在软件设置中关闭该功能。
2、合理管理运行的程序养成良好的使用习惯，避免同时打开过多的大型程序。
Mongodb常见错误与解决⽅法⼩结（Mongodb中经常出现的错误）今天在配置MongoDB时发⽣了以下⼏个错误, 已经被我解决了,提供给⼤家.2015-05-12T09:30:26.313+0800 I STORAGE [initandlisten] exception in initAndListen: 28574 Cannot start server. Detected data files in/root/Desktop/mongodb/data created by storage engine 'mmapv1'. The configured storage engine is 'wiredTiger'., terminating2015-05-12T09:30:26.313+0800 I CONTROL [initandlisten] dbexit: rc: 1002015-05-12T09:31:53.043+0800 I CONTROL ***** SERVER RESTARTED *****2015-05-12T09:31:53.049+0800 I STORAGE [initandlisten] exception in initAndListen: 28574 Cannot start server. Detected data files in/root/Desktop/mongodb/data created by storage engine 'mmapv1'. The configured storage engine is 'wiredTiger'., terminating2015-05-12T09:31:53.050+0800 I CONTROL [initandlisten] dbexit: rc: 100补充⼀下：如果存储空间满了的话也会出现 rc:100错误。
解决MongoDB占⽤内存过⼤频繁死机的⽅法详解从MongoDB 3.4开始，默认的WiredTiger内部缓存⼤⼩是以下两者中的较⼤者：
50％（RAM-1 GB），或 256 MB
例如，在总共有4GB RAM的系统上，WiredTiger缓存将使⽤1.5GB RAM（）。
相反，总内存为1.25 GB的系统将为WiredTiger缓存分配256 MB，因为这是总RAM的⼀半以上减去1 GB（）。
// 4GB
0.5 * (4 GB - 1 GB) = 1.5 GB
// 1.25GB
0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB
看完⽂档，我查看了⾃⼰的内存使⽤
$ free -h
# 没启动mongod
total used free
Mem: 3.7G 2.4G 1.3G
# 启动mongod
total used free
Mem: 3.7G 1.8G 364M
直接占满内存了
参考了⼀部分⽹上的⽂章，⼤致的意思就是说，MongoDB占⽤了太多内存，被系统kill掉了，所以出现宕机现象
解决⽅式
添加两个参数
修改配置 mongodb.conf
# 为⾼速缓存分配的最⼤内存量；默认为物理RAM的1/2
# wiredTigerCacheSizeGB <float>
wiredTigerCacheSizeGB=0.5
# 最⼤同时连接数，默认1000000
更多关于MongoDB占⽤内存过⼤的问题解决⽅法请查看下⾯的相关链接。
引言在进行MongoDB集群管理的过程中，经常会遇到集群空间不足的情况。
当这种情况发生时，我们需要采取一些措施来删除数据以释放空间。
本文将深入探讨MongoDB集群空间不足的原因、数据删除的方法以及我个人对这个话题的观点和理解。
一、MongoDB集群空间不足的原因1. 数据量持续增长：随着业务的发展和数据的积累，MongoDB集群中存储的数据量会逐渐增加，导致空间不足的问题。
2. 索引占用空间过大：集群中的各种索引也会占用大量空间，如果索引设计不合理或者存在大量冗余索引，就会加剧空间不足的问题。
3. 慢查询导致数据增长过快：如果集群中存在大量慢查询，可能导致数据增长速度过快，间接导致空间不足的问题。
二、数据删除的方法1. 删除历史数据：对于一些历史数据或者过期数据，可以通过定期清理的方式来删除，释放空间。
2. 压缩数据：对已有的数据进行压缩，可以减小数据占用的空间。
3. 精简索引：对不必要的或者冗余的索引进行删除或者优化，释放空间。
4. 分片存储：将数据按照一定的规则进行分片存储，可以有效减少单个节点的数据量，缓解空间不足的问题。
三、个人观点和理解在面对MongoDB集群空间不足的情况时，我认为需要综合考虑数据删除、索引优化和存储规划等多个方面的因素。
除了及时清理历史数据和优化索引外，还需要考虑集群的整体架构和未来的业务发展规划，以更全面地解决空间不足的问题。
对于数据库管理人员来说，需要保持对数据增长情况的监控，并及时调整存储策略，以避免空间不足给业务带来不必要的影响。
结论通过对MongoDB集群空间不足的原因、数据删除的方法以及个人观点和理解的探讨，我们可以更全面地理解并解决这一问题。
在实际操作中，需要根据具体情况综合考虑数据删除、索引优化和存储规划等多个方面的因素，以有效释放空间并保证集群的可用性和稳定性。
希望本文能对您在MongoDB集群管理中遇到空间不足的问题有所帮助。
扩写新内容：四、综合考虑解决方案针对MongoDB集群空间不足的问题，我们可以采取综合的解决方案来应对。
mongodb group 耗时过长优化方法（实用版）目录1.MongoDB group 耗时过长的问题2.优化方法2.1 增加内存2.2 优化聚合查询2.3 使用分页2.4 允许磁盘存储2.5 调整集合大小2.6 优化索引正文一、MongoDB group 耗时过长的问题在使用 MongoDB 进行 group 操作时，可能会遇到耗时过长的问题。
尤其是在处理大量数据时，可能会导致整个系统性能下降，甚至影响到其他任务的执行。
这种情况下，我们需要对 MongoDB group 进行优化。
二、优化方法1.增加内存增加内存是解决 MongoDB group 耗时过长问题的最直接方法。
通过增加内存，可以让 MongoDB 在 group 操作时能够一次性加载更多的数据，从而减少磁盘 I/O 操作，提高运行效率。
在实际操作中，我们可以根据服务器的硬件配置和数据量，适当增加内存大小。
2.优化聚合查询在进行 group 操作时，我们可以通过优化聚合查询来提高效率。
具体方法包括：- 尽量减少 $match 和 $project 等聚合阶段的使用，尤其是复杂的条件和表达式。
- 避免在聚合查询中使用 $lookup 等耗时较长的操作。
- 尽量使用 $sort 和 $limit 等聚合阶段对数据进行排序和分页，以减少不必要的数据传输。
3.使用分页在进行 group 操作时，我们可以通过使用分页来降低单次查询的压力。
将大范围的数据分页处理，可以有效地提高 group 操作的效率。
在实际应用中，我们可以根据业务需求和数据量，选择合适的分页大小。
4.允许磁盘存储在进行 group 操作时，我们可以通过设置 allowDiskUse 选项来允许 MongoDB 使用磁盘存储中间结果。
这样可以有效地避免因内存不足而导致的耗时问题。
在使用磁盘存储时，需要注意磁盘空间的充足程度，以避免因磁盘空间不足而导致的操作失败。
5.调整集合大小在实际应用中，我们可以通过调整集合大小来降低 group 操作的复杂度。
mongodb_exporter 报警规则MongoDB Exporter 是一个用于监控MongoDB 数据库性能的开源工具。
它可以帮助你收集和报告MongoDB 数据库的各种指标，如CPU 使用率、内存使用情况、磁盘I/O 等。
以下是MongoDB Exporter 的一些常见报警规则：1、CPU 使用率报警：当CPU 使用率持续高于80% 时触发报警。
当CPU 使用率持续高于90% 时触发严重报警。
2、内存使用率报警：当内存使用率持续高于70% 时触发报警。
当内存使用率持续高于80% 时触发严重报警。
3、磁盘I/O 报警：当磁盘I/O 等待时间持续高于20% 时触发报警。
当磁盘I/O 等待时间持续高于30% 时触发严重报警。
4、数据库连接数异常报警：当数据库连接数持续高于1000 时触发报警。
当数据库连接数持续高于2000 时触发严重报警。
5、MongoDB 复制延迟报警：当MongoDB 复制延迟时间持续大于100ms 时触发报警。
当MongoDB 复制延迟时间持续大于200ms 时触发严重报警。
6、MongoDB 分片槽位不足报警：当MongoDB 分片槽位使用率持续高于90% 时触发报警。
当MongoDB 分片槽位使用率持续高于95% 时触发严重报警。
这些报警规则只是一些常见的例子，你可以根据自己的需求和实际情况来定义适合自己的报警规则。
在使用MongoDB Exporter 时，你可以通过配置文件来设置报警规则，并配置相应的通知方式，如邮件、短信、Slack 等，以便及时收到报警通知并采取相应的措施。
linux mysql内存资源过高的解决方法
MySQL是一个开源的关系型数据库管理系统，在Linux系统上广泛使用。
当MySQL占用过高的内存资源时，可能会导致系统性能下降甚至宕机。
下面是解决MySQL内存资源过高问题的几种方法：
1. 优化MySQL配置：通过修改MySQL的配置文件f，可以调整一些参数来减少内存占用。
例如，可以调整innodb_buffer_pool_size参数来限制InnoDB 缓冲池的大小，降低内存消耗。
2. 限制查询结果集：一些查询可能返回大量的数据，消耗大量内存资源。
可以通过使用LIMIT关键字来限制查询结果集的大小，或者通过索引优化查询语句，减少对磁盘的访问。
3. 优化SQL语句：一些复杂的SQL查询可能导致MySQL消耗大量的内存资源。
可以通过优化SQL语句的编写，避免不必要的数据访问和计算，来减少内存占用。
4. 定期清理无用的连接和线程：MySQL会为每个连接和线程分配一定的内存资源。
如果有大量的空闲连接或者线程存在，会浪费内存资源。
可以使用命令SHOW PROCESSLIST来查看当前连接和线程的状态，并通过KILL命令关闭不需要的连接和线程。
5. 升级MySQL版本：新版本的MySQL通常会修复一些内存占用问题，并进行性能优化。
可以考虑升级到最新的稳定版本，以获得更好的性能和内存管理。
需要注意的是，以上方法仅作为参考，实际解决问题时需要根据具体情况进行调整和优化。
在进行任何改动之前，建议先备份数据库以防数据丢失。
同时，监控系统的性能指标也是及时发现和解决MySQL内存问题的重要手段。
mongodb 监控指标阈值MongoDB 是一种非关系型数据库管理系统，其在大数据存储和处理方面具有很高的性能和灵活性。
为了确保 MongoDB 数据库的正常运行，我们需要对其进行监控和管理。
在监控 MongoDB 数据库时，我们可以设置一些指标阈值，以便及时发现并解决潜在的问题。
本文将介绍一些常见的 MongoDB 监控指标阈值，并解释其含义和设置方法。
1. 连接数阈值：连接数指的是当前正在连接到 MongoDB 数据库的客户端数量。
如果连接数过高，可能会导致数据库性能下降。
通常情况下，建议将连接数控制在MongoDB 最大连接数的80%左右。
可以通过命令"db.serverStatus().connections"来查看当前连接数，并通过修改配置文件中的"maxIncomingConnections"参数来调整连接数阈值。
2. 查询响应时间阈值：查询响应时间是指从发送查询请求到接收到查询结果所花费的时间。
如果查询响应时间过长，可能是由于查询语句复杂或索引缺失等原因导致的。
建议将查询响应时间控制在几毫秒到几十毫秒之间。
可以通过使用explain()方法来查看查询计划，并对查询语句和索引进行优化以提高查询性能。
3. 内存利用率阈值：内存利用率指的是 MongoDB 数据库正在使用的内存占可用内存的比例。
如果内存利用率过高，可能会导致数据库需要频繁地从磁盘中读取数据，从而影响数据库的性能。
通常情况下，建议将内存利用率控制在70%到80%之间。
可以通过命令"db.serverStatus().mem"来查看当前内存利用率，并通过修改配置文件中的"cacheSizeGB"参数来调整内存利用率阈值。
4. 磁盘空间利用率阈值：磁盘空间利用率指的是 MongoDB 数据库正在使用的磁盘空间占总磁盘空间的比例。
如果磁盘空间利用率过高，可能会导致数据库无法继续写入数据。
MongoDB数据库占用内存问题
经过近三个月的尝试前三个方案已失败：
一，通过系统自带内存管理功能限制mongo使用内存大小。
结果：无效，经过一段时间（3 天左右）后使用内存依然接近98%。
二， MongoDB 3.x采用WiredTiger存储引擎，性能会比原有的MMAP引擎要好一些，通过设置可以阻止OOM的事情发生。
理论上占用的最大内存等于“设置内存 + 工作集内存”。
其中工作集内存为数据库的索引大小（db.stat().indexSize），当前大约为10G，我们设置的内存为5G，如果一段时间后内存稳定在16G上下，则视为有效。
结果：无效，经过一段时间（和方案一基本一致）后内存突破20G最终也达到98%以上。
三，通过写批处理，定时清理系统内存和MongoDB的内存占用。
结果：经过一段时间（20 天左右）后系统总使用内存也达到96%以上
综上经过分析：系统自带内存限制和mongodb自带内存限制不足以约束mongodb的内存使用量，通过批处理释放内存在一定程度上避免了因为mongodb的大内存使meteor 程序崩溃的问题，但是经过20天的运行后批处理清理内存效果很差，清理后系统显示使用内存依然高达96%。
即前三方案全部失效
建议：
既然软件方面无法限制mongodb的内存使用，可将mongodb单独放在一个服务器上面和应用服务器分离开以避免因mongodb使用的大内存影响meteor等程序的正常使用。
如此方法在网上搜索很多人使用过，刚刚也和钱龙确认过可行性。
mongodb out of memory解决方法如何解决MongoDB 内存溢出问题1. 引言在使用MongoDB 数据库时，有时候会出现内存不足的情况。
这种情况往往会导致服务器的性能下降甚至崩溃。
为了解决MongoDB 内存溢出的问题，我们需要采取一些措施。
2. 分析问题在解决问题之前，我们首先需要了解出现内存溢出的原因。
MongoDB 内存溢出的原因往往与以下几个方面有关：- 数据过大：如果数据集过大，超过了服务器内存的承载能力，就很容易出现内存溢出的情况。
- 查询性能低下：一些复杂的查询可能会消耗大量的内存，在查询时没有进行性能优化可能导致内存溢出。
- 索引问题：索引可以提高查询性能，但如果索引过多或者索引没有正确使用，也会导致内存溢出。
- 内存配置不当：如果MongoDB 的内存配置过小，无法满足实际需要，也会造成内存溢出。
基于以上原因，我们可以采取以下措施来解决MongoDB 内存溢出问题。
3. 数据分片和分片负载均衡如果数据集过大超过了服务器的内存承载能力，我们可以考虑进行数据分片。
数据分片是将数据切分成多个较小的片段，分布在不同的服务器上。
这样可以将数据负载均衡地分布在多台服务器上，避免单台服务器出现内存溢出的问题。
MongoDB 提供了分片功能，我们可以根据业务需求进行数据分片，并且可以通过数据均衡功能将数据自动迁移到不同的服务器上，以达到负载均衡的效果。
4. 查询性能优化一些复杂的查询可能会消耗大量的内存，我们可以通过对查询进行优化来减少内存的使用。
以下是一些建议：- 尽量使用索引：索引可以大大提高查询性能，减少内存的消耗。
在设计数据模型时，需要根据实际情况选择适当的索引字段，并且确保索引被正确使用。
- 细化查询条件：尽量减少查询返回的数据量，在查询时使用合适的条件来过滤无关数据，避免查询大量不必要的数据。
- 分页查询：对于大量数据，可以使用分页查询来逐步获取数据，减少一次性加载大量数据导致内存溢出的风险。
mongodb 对内存的严重占用以及解决方法刚开始使用mongodb的时候，不太注意mongodb的内存使用，但通过查资料发现mongodb对内存的占用是巨大的，在本地测试服务器中，8G的内存居然被占用了45%。
汗呀。
本文就来剖析一下mongodb对内存的具体使用方法，以及生产环境针对mongodb占大量内存的问题的解决。
先看一个MongoDB服务器的top命令结果shell> top -p $(pidof mongod)Mem: 32872124k total, 30065320k used, 2806804k free, 245020k buffers Swap: 2097144k total, 100k used, 2097044k free, 26482048k cachedVIRT RES SHR %MEM1892g 21g 21g 69.6或者先top后，然后shift+m 把当前进场按占用内存的多少排序。
看看你的mongodb 能占用多少内存。
先了解一下linux对内存的管理方式：在Linux里（别的系统也差不多），内存有物理内存和虚拟内存之说，物理内存是什么自然无需解释，虚拟内存实际是物理内存的抽象，多数情况下，出于方便性的考虑，程序访问的都是虚拟内存地址，然后操作系统会把它翻译成物理内存地址。
很多人会把虚拟内存和Swap混为一谈，实际上Swap只是虚拟内存引申出的一种技术而已：操作系统一旦物理内存不足，为了腾出内存空间存放新内容，就会把当前物理内存中的内容放到交换分区里，稍后用到的时候再取回来，需要注意的是，Swap的使用可能会带来性能问题，偶尔为之无需紧张，糟糕的是物理内存和交换分区频繁的发生数据交换，这被称之为Swap颠簸，一旦发生这种情况，先要明确是什么原因造成的，如果是内存不足就好办了，加内存就可以解决，不过有的时候即使内存充足也可能会出现这种问题，比如MySQL 就有可能出现这样的情况，解决方法是限制使用Swap：shell> sysctl -w vm.swappiness=0查看内存情况最常用的是free命令：shell> free -mtotal used free shared buffers cached Mem: 32101 29377 2723 0 239 25880-/+ buffers/cache: 3258 28842Swap: 2047 0 2047新手看到used一栏数值偏大，free一栏数值偏小，往往会认为内存要用光了。
其实并非如此，之所以这样是因为每当我们操作文件的时候，Linux都会尽可能的把文件缓存到内存里，这样下次访问的时候，就可以直接从内存中取结果，所以cached一栏的数值非常的大，不过不用担心，这部分内存是可回收的，操作系统会按照LRU算法淘汰冷数据。
除了cached，还有一个buffers，它和cached类似，也是可回收的，不过它的侧重点在于缓解不同设备的操作速度不一致造成的阻塞，这里就不多做解释了。
知道了原理，我们就可以推算出系统可用的内存是free + buffers + cached：shell> echo "2723 + 239 + 25880" | bc -l28842至于系统实际使用的内存是used – buffers – cached：shell> echo "29377 - 239 - 25880" | bc -l3258除了free命令，还可以使用sar命令：shell> sar -rkbmemfree kbmemused %memused kbbuffers kbcached3224392 29647732 90.19 246116 260701603116324 29755800 90.52 245992 261573722959520 29912604 91.00 245556 263163962792248 30079876 91.51 245680 264856722718260 30153864 91.73 245684 26563540shell> sar -Wpswpin/s pswpout/s0.00 0.000.00 0.000.00 0.000.00 0.000.00 0.00希望你没有被%memused吓到，如果不幸言中，请参考free命令的解释。
接着咱们分析一下mongodb是怎么使用内存的：目前，MongoDB使用的是内存映射存储引擎，它会把磁盘IO操作转换成内存操作，如果是读操作，内存中的数据起到缓存的作用，如果是写操作，内存还可以把随机的写操作转换成顺序的写操作，总之可以大幅度提升性能。
MongoDB并不干涉内存管理工作，而是把这些工作留给操作系统的虚拟缓存管理器去处理，这样的好处是简化了MongoDB的工作，但坏处是你没有方法很方便的控制MongoDB占多大内存，事实上MongoDB会占用所有能用的内存，所以最好不要把别的服务和MongoDB放一起。
有时候，即便MongoDB使用的是64位操作系统，也可能会遭遇臭名昭著的OOM问题，出现这种情况，多半是因为限制了虚拟内存的大小所致，可以这样查看当前值：shell> ulimit -a | grep 'virtual'多数操作系统缺省都是把它设置成unlimited的，如果你的操作系统不是，可以这样修改：shell> ulimit -v unlimited不过要注意的是，ulimit的使用是有上下文的，最好放在MongoDB的启动脚本里。
有时候，出于某些原因，你可能想释放掉MongoDB占用的内存，不过前面说了，内存管理工作是由虚拟内存管理器控制的，所以通常你只能通过重启服务来释放内存，你一定不齿于这样的方法，幸好可以使用MongoDB内置的closeAllDatabases命令达到目的：mongo> use adminmongo> db.runCommand({closeAllDatabases:1})另外，通过调整内核参数drop_caches也可以释放缓存：shell> sysctl -w vm.drop_caches=1平时可以通过mongo命令行来监控MongoDB的内存使用情况，如下所示：mongo> db.serverStatus().mem:{"resident" : 22346,"virtual" : 1938524,"mapped" : 962283}还可以通过mongostat命令来监控MongoDB的内存使用情况，如下所示：shell> mongostatmapped vsize res faults940g 1893g 21.9g 0940g 1893g 21.9g 0940g 1893g 21.9g 0940g 1893g 21.9g 0940g 1893g 21.9g 0其中内存相关字段的含义是：mapped：映射到内存的数据大小visze：占用的虚拟内存大小res：实际使用的内存大小注：如果操作不能再内存中完成，结果faults列的数值不会是0，视大小可能有性能问题。
在上面的结果中，vsize是mapped的两倍，而mapped等于数据文件的大小，所以说vsize 是数据文件的两倍，之所以会这样，是因为本例中，MongoDB开启了journal，需要在内存里多映射一次数据文件，如果关闭journal，则vsize和mapped大致相当。
如果想验证这一点，可以在开启或关闭journal后，通过pmap命令来观察文件映射情况：shell> pmap $(pidof mongod)到底MongoDB配备多大内存合适？宽泛点来说，多多益善，如果要确切点来说，这实际取决于你的数据及索引的大小，内存如果能够装下全部数据加索引是最佳情况，不过很多时候，数据都会比内存大，比如本文说涉及的MongoDB实例：mongo> db.stats(){"dataSize" : 1004862191980,"indexSize" : 1335929664}本例中索引只有1G多，内存完全能装下，而数据文件则达到了1T，估计很难找到这么大内存，此时保证内存能装下热数据即可，至于热数据有多少，这就是个比例问题了，取决于具体的应用。
如此一来内存大小就明确了：内存> 索引+ 热数据。
根据以上的分析我们可以得出几点结论：1.mongodb 直接用操作系统的内存管理器来管理内存。
而操作系统采用的是LRU算法淘汰冷数据。
2.mongodb可以用重启服务、调整内核参数以及mongodb内部的语法去清理mongodb对内存的缓存。
可能存在的问题是：这几种清理方式都是全部清理，这样的话mongodb的内存缓存就失效了。
3.mongodb 对内存的使用是可以被监控的，在生产环境中要定时的去监控这些数据。
4.mongodb 对内存这种占用方式使其尽量的和其他占用内存的业务分开部署，例如memcahe，sphinx，mysql等。
5.操作系统中的交换分区swap 如果操作频繁的话，会严重降低系统效率。
要解决可以禁用交换分区，以及增加内存以及做分布式。
6. 生产环境中mongodb所在的主机应该尽量的大内存。
作者：洪荒听雨，qq：376118028擅长lamp开发，搜索技术，缓存技术等。
欢迎转载，转载请注明作者。
