mySQL占用虚拟内存达8百多兆问题解决思路

为了装mysql环境测试,装上后发现启动后mysql占用了很大的虚拟内存,达8百多兆。网上搜索了一下,得到高人指点my.ini。再也没见再详细的了..只好打开my.ini逐行的啃,虽然英文差了点,不过多少M还是看得明的^-^

更改后如下
innodb_buffer_pool_size=576M ->256M InnoDB引擎缓冲区占了大头,首要就是拿它开刀
query_cache_size=100M ->16M 查询缓存
tmp_table_size=102M ->64M 临时表大小
key_buffer_size=256m ->32M

重启mysql服务后,虚拟内存降到200以下
另外mysql安装目录下有几个文件:my-huge.ini 、my-large.ini、my-medium.ini...这几个是根据内存大小作的建议配置,新手在设置的时候也可以参考一下。
2G内存的MYSQL数据库服务器 my.ini优化 (my.ini)
2G内存,针对站少,优质型的设置,试验特:
table_cache=1024 物理内存越大,设置就越大.默认为2402,调到512-1024最佳
innodb_additional_mem_pool_size=8M 默认为2M
innodb_flush_log_at_trx_commit=0 等到innodb_log_buffer_size列队满后再统一储存,默认为1
innodb_log_buffer_size=4M 默认为1M
innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,默认为8
key_buffer_size=256M 默认为218 调到128最佳
tmp_table_size=64M 默认为16M 调到64-256最挂
read_buffer_size=4M 默认为64K
read_rnd_buffer_size=16M 默认为256K
sort_buffer_size=32M 默认为256K
max_connections=1024 默认为1210

试验一
table_cache=512或1024
innodb_additional_mem_pool_size=2M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=1M
innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,默认为8
key_buffer_size=128M
tmp_table_size=128M
read_buffer_size=64K或128K
read_rnd_buffer_size=256K
sort_buffer_size=512K
max_connections=1024

试验二
table_cache=512或1024
innodb_additional_mem_pool_size=8M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=4M
innodb_thread_concurrency=8
key_buffer_size=128M
tmp_table_size=128M
read_buffer_size=4M
read_rnd_buffer_size=16M
sort_buffer_size=32M
max_connections=1024

一般
table_cache=512
innodb_additional_mem_pool_size=8M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=4M
innodb_thread_concurrency=8
key_buffer_size=128M
tmp_table_size=128M
read_buffer_size=4M
read_rnd_buffer_size=16M
sort_buffer_size=32M
max_connections=1024

经过测试.没有特殊情况,最好还是用默认的.
2G内存,针对站多,抗压型的设置,最佳:
table_cache=1024 物理内存越大,设置就越大.默认为2402,调到512-1024最佳
innodb_additional_mem_pool_size=4M 默认为2M
innodb_flush_log_at_trx_commit=1
(设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1)
innodb_log_buffer_size=2M 默认为1M
innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,建议用默认一般为8
key_buffer_size=256M 默认为218 调到128最佳
tmp_table_size=64M 默认为16M 调到64-256最挂
read_buffer_size=4M 默认为64K
read_rnd_buffer_size=16M 默认为256K
sort_buffer_size=32M 默认为256K
max_connections=1024 默认为1210
thread_cache_size=120 默认为60
query_cache_size=64M

优化mysql数据库性能的十个参数
(1)、max_connections:
允许的同时客户的数量。增加该值增加 mysqld 要求的文件描述符的数量。这个数字应该增加,否则,你将经常看到 too many connections 错误。 默认数值是100,我把它改为1024 。
(2)、record_buffer:
每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,你可能想要增加该值。默认数值是131072(128k),我把它改为16773120 (16m)
(3)、key_buffer_size:
索引块是缓冲的并且被所有的线程共享。key_buffer_size是用于索引块的缓冲区大小,增加它可得到更好处理的索引(对所有读和多重写),到你能负担得起那样多。如果你使它太大,系统将开始换页并且真的变慢了。默认数值是8388600(8m),我的mysql主机有2gb内存,所以我把它改为 402649088(400mb)。
4)、back_log:
要求 mysql 能有的连接数量。当主要mysql线程在一个很短时间内得到非常多的连接请求,这就起作用,然后主线程花些时间(尽管很短)检查连接并且启动一个新线程。
back_log 值指出在mysql暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接,你需要增加它,换句话说,这值对到来的tcp/ip连接的侦听队列的大小。你的操作系统在这个队列大小上有它自己的限制。试图设定back_log高于你的操作系统的限制将是无效的。
当你观察你的主机进程列表,发现大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | null | connect | null | login | null 的待连接进程时,就要加大 back_log 的值了。默认数值是50,我把它改为500。
(5)、interactive_timeout:
服务器在关闭它前在一个交互连接上等待行动的秒数。一个交互的客户被定义为对 mysql_real_connect()使用 client_interactive 选项的客户。 默认数值是28800,我把它改为7200。
(6)、sort_buffer:
每个需要进行排序的线程分配该大小的一个缓冲区。增加这值加速order by或group by操作。默认数值是2097144(2m),我把它改为 16777208 (16m)。
(7)、table_cache:
为所有线程打开表的数量。增加该值能增加mysqld要求的文件描述符的数量。mysql对每个唯一打开的表需要2个文件描述符。默认数值是64,我把它改为512。
(8)、thread_cache_size:
可以复用的保存在中的线程的数量。如果有,新的线程从缓存中取得,当断开连接的时候如果有空间,客户的线置在缓存中。如果有很多新的线程,为了提高性能可以这个变量值。通过比较 connections 和 threads_created 状态的变量,可以看到这个变量的作用。我把它设置为 80。
(9)mysql的搜索功能
用mysql进行搜索,目的是能不分大小写,又能用中文进行搜索
只需起动mysqld时指定 --default-character-set=gb2312
(10)、wait_timeout:
服务器在关闭它之前在一个连接上等待行动的秒数。 默认数值是28800,我把它改为7200。

:参数的调整可以通过修改 /etc/my.cnf 文件并重启 mysql 实现。这是一个比较谨慎的工作,上面的结果也仅仅是我的一些看法,你可以根据你自己主机的硬件情况(特别是内存大小)进一步修改。

(0)

相关推荐

  • 浅析MySQL内存的使用说明(全局缓存+线程缓存)

    首先我们来看一个公式,MySQL中内存分为全局内存和线程内存两大部分(其实并不全部,只是影响比较大的 部分): 复制代码 代码如下: per_thread_buffers=(read_buffer_size+read_rnd_buffer_size+sort_buffer_size+thread_stack+join_buffer_size+binlog_cache_size+tmp_table_size)*max_connectionsglobal_buffers=innodb_buffer_

  • MySQL内存表的特性与使用介绍

    内存表,就是放在内存中的表,所使用内存的大小可通过My.cnf中的max_heap_table_size指定,如max_heap_table_size=1024M,内存表与临时表并不相同,临时表也是存放在内存中,临时表最大所需内存需要通过tmp_table_size = 128M设定.当数据超过临时表的最大值设定时,自动转为磁盘表,此时因需要进行IO操作,性能会大大下降,而内存表不会,内存表满后,会提示数据满错误. 临时表和内存表都可以人工创建,但临时表更多的作用是系统自己创建后,组织数据以提升

  • 解析mysql 缓存如何使用内存

    先说明2点开启缓存也会带来开销,主要表现在一下方面读取在查询开始之前必须要检查缓存如果查询是缓存的,但是不在结果集中,那么产生结果后保存数据会带来一定的开销向缓存写如数据也会带来开销 有的情况查询缓存不会被缓存,即使你使用 SQL_CACHE也不能缓存主要一下几个引用了用户自定义函数引用了用户自定义变量以用了存续过程查询中包含一些实时的系统函数,比如now引用了临时表 虽然上面说到缓存会带来一些开销但是缓存对mysql  还是很重要带来的好处比坏处多 下面讲一下mysql缓存如何使用内存查询缓存

  • mysql 数据库中my.ini的优化 2G内存针对站多 抗压型的设置

    物理内存越大,设置就越大.默认为2402,调到512-1024最佳 innodb_additional_mem_pool_size=4M 默认为2M innodb_flush_log_at_trx_commit=1 (设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1) innodb_log_buffer_size=2M 默认为1M innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,建议用默认一般为8 key_buff

  • Nginx 0.7.x + PHP 5.2.6(FastCGI)+ MySQL 5.1 在128M小内存VPS服务器上的配置优化第1/2页

    对其用户和应用程序来讲,每一个VPS平台的运行和管理都与一台独立主机完全相同,因为每一个VPS均可独立进行重启并拥有自己的root访问权限.用户.IP地址.内存.过程.文件.应用程序.系统函数库以及配置文件.VPS服务器最重要的指标就是内存大小,多个VPS服务器可以共享一颗CPU,但不能共享同一块内存.内存越大,价格越贵. 下面,以我的博客所在的VPS为例,介绍在128M内存下对 Nginx 0.7.x + PHP 5.2.6(FastCGI)+ MySQL 5.1 的优化. 至于 Nginx

  • PHP查询MySQL大量数据的时候内存占用分析

    昨天, 有同事在PHP讨论群里提到, 他做的一个项目由于MySQL查询返回的结果太多(达10万条), 从而导致PHP内存不够用. 所以, 他问, 在执行下面的代码遍历返回的MySQL结果之前, 数据是否已经在内存中了? - 复制代码 代码如下: while ($row = mysql_fetch_assoc($result)) { // ... } 当然, 这种问题有许多优化的方法. 不过, 就这个问题来讲, 我首先想到, MySQL是经典的C/S(Client/Server, 客户端/服务器)

  • 用mysql内存表来代替php session的类

    复制代码 代码如下: <?php /** @Usage: use some other storage method(mysql or memcache) instead of php sessoin @author:lein @Version:1.0 */ session_start(); if(!isset($_SESSION['test'])){ $_SESSION['test']="123_lein_".date("Y-m-d H:i:s"); } c

  • mySQL占用虚拟内存达8百多兆问题解决思路

    为了装mysql环境测试,装上后发现启动后mysql占用了很大的虚拟内存,达8百多兆.网上搜索了一下,得到高人指点my.ini.再也没见再详细的了..只好打开my.ini逐行的啃,虽然英文差了点,不过多少M还是看得明的^-^ 更改后如下: innodb_buffer_pool_size=576M ->256M InnoDB引擎缓冲区占了大头,首要就是拿它开刀 query_cache_size=100M ->16M 查询缓存 tmp_table_size=102M ->64M 临时表大小

  • MySQL占用内存较大与CPU过高测试与解决办法

    更改后如下: innodb_buffer_pool_size=576M ->256M InnoDB引擎缓冲区占了大头,首要就是拿它开刀 query_cache_size=100M ->16M 查询缓存 tmp_table_size=102M ->64M 临时表大小 key_buffer_size=256m ->32M 重启mysql服务后,虚拟内存降到200以下. 另外mysql安装目录下有几个文件:my-huge.ini .my-large.ini.my-medium.ini..

  • mysql占用CPU过高的解决办法(添加索引)

    下面是MYSQL占用CPU高处理的一个例子,希望对遇到类似问题的朋友们有点启发.一般来说MYQL占用CPU高,多半是数据库查询代码问题,查询数据库过多.所以一方面要精简代码,另一方面最好对频繁使用的代码设置索引. 今天早上起来 机器报警 一查负载一直都在4以上 top了一下 发现 mysql 稳居 第一 而且相当稳定 我擦 重启一下mysql不行 mysql> show processlist;一下 发现xxx网站有两条 查询语句 一直 在列,我擦 该站 也就30多万条记录 量也不大 不可能是机

  • Mysql占用过高CPU时的优化手段(必看)

    Mysql占用CPU过高的时候,该从哪些方面下手进行优化? 占用CPU过高,可以做如下考虑: 1)一般来讲,排除高并发的因素,还是要找到导致你CPU过高的哪几条在执行的SQL,show processlist语句,查找负荷最重的SQL语句,优化该SQL,比如适当建立某字段的索引: 2)打开慢查询日志,将那些执行时间过长且占用资源过多的SQL拿来进行explain分析,导致CPU过高,多数是GroupBy.OrderBy排序问题所导致,然后慢慢进行优化改进.比如优化insert语句.优化group

  • MySQL占用内存过大解决方案图文详解

    目录 前言 解决方案 1. 找到配置文件 2. 修改配置文件 3. 重启MySQL 后记 前言 对于部分小资玩家来说,服务器数量和内存往往是很有限的,像我个人的服务器配置就是2核4G5M. 4G内存对于Java玩家来说,真的不大,开几个中间件+自己的微服务真的还蛮挤的,然后又摊上MySQL这个大冤种.我本机上的MySQL仅仅只占几M内存(虽然我不怎么用,但是本机MySQL确实是开着的): 而服务器的则要占400M,怎么说其实没什么吞吐量,纯粹是自己玩一玩,这内存占用属实有点吃不消啊... 解决方

  • MySQL 表空间碎片的概念及相关问题解决

    背景 经常使用 MySQL 的话,会发现 MySQL 数据文件的磁盘空间一般会不停的增长,而且有时候删了数据或者插入一批数据的时候,磁盘空间有时候还会毫无变化.引发这个其妙现象的就是 MySQL 的表空间碎片. 什么是表空间碎片? 表空间碎片指的是表空间中存在碎片,形象一点来比喻的话,就像是一张 A4 纸,"表空间碎片"就像是把这张 A4 纸撕碎,再重新拼起来,各个碎片之间都会有一些缝隙存在,这些缝隙就是"表空间碎片".重新拼起来的碎片实际上会比完整的 A4 纸大上

  • MySQL删除和插入数据很慢的问题解决

    公司开发人员在测试环境中执行一条 insert 语句时,需要花费 10 几秒才可以执行成功.查看测试环境数据库性能.数据量.死锁等信息,均为发现异常.最后通过修改日志写入方式解决此问题. 1. 修改办法 修改/etc/my.cnf文件,将 innodb_flush_log_at_trx_commit = 1改为0, 但这样就要承担数据库Crash后,1秒内未存储到数据库数据丢失可能的风险.MySQL文档中对该参数的描述如下: If the value of innodb_flush_log_at

  • MySQL中CONCAT()函数拼接出现NULL的问题解决

    项目中查询用到了concat()拼接函数,在此查询中出现了拼接的字段为null的情况,拼接结果为null在应用层报了空指针异常. SELECT CONCAT('1,',NULL,'2') result; SELECT CONCAT('1,','','2') result; 通过实践证明CONCAT()函数拼接时如果拼接的参数中有NULL时,结果为NULL. 使用以下方式来解决 方法一:使用IFNULL函数如果是NULL将其置为''空字符串. SELECT CONCAT('1,',IFNULL(N

  • MySQL Threads_running飙升与慢查询的相关问题解决

    背景 年前本应该是回顾一年工作和收尾的阶段,奈何各种促销,活动都等着春节,因此也遇到了不少的问题,回顾了一下最近遇到的问题,发现有好几个问题比较类似,正好整理一下,作为年前收尾的案例吧.表现上都是数据库假死,无响应,发生的场景有较高的业务压力到来时,也有业务正常运行的时候,突然就出现问题了. 问题描述 由于腾讯云数据库 MySQL 本身是有故障检测和高可用机制的,这几例问题发生的时候,从用户反馈的问题出现的时间点到实际介入排查的时候已经有好几分钟了,但是并没有触发高可用切换,说明这个问题可能并不

  • mysql启动的error 2003和1067错误问题解决方法

    mysql安装好经常发现无法正常启动碰到最多的是error 2003的错误,以下为解决方法: mysqld -nt -remove mysqld -nt -install 重新启动mysql net start mysql 可能还会遇到服务1067错误的问题,原因大致有两个: (1)my.ini的basedir和datadir目录配置有问题,可如下面的例子修改: basedir=d:/MySQL5.0/#mysql安装位置 datadir=d:/MySQL5.0/data#数据存放位置 不过,一

随机推荐