本次开放测试卡建号问题分析——MySQL配置优化方法

作者: NickYang 分类: 心情随笔,程序开发 发布时间: 2011-08-21 17:51

本次的开放测试依然在进行中,昨天关于卡建号的问题大家讨论了一下解决办法,对逻辑方面也检查了一下,不过逻辑方面很久都没人改过了,如果出问题应该两个项目都出问题,结果另外一个从来不卡的,所以应该不是逻辑上的问题,结果去检查MySQL的配置,才发现了原因。

是MySQL中打Log过于频繁导致的原因,原来的配置是 innodb_flush_log_at_trx_commit = 1,有一条处理就等待写LLog到磁盘,写入磁盘想对耗时比价多,所以非常卡,本次测试参数是1的测试结果是60-90毫秒,修改成2之后,使用客户端创建一个角色的时间是0 ms,用机器人创建1000个角色压力测试的结果是13ms,这个结果还可以接受,1分钟3000多账号,完全可以理解。前面运维测试的时间是200ms一个,所以呢,又被玩家骂了一顿啊,悲惨的命运。

简单搜了一下MySQL优化的配置给大家分享下:

my.ini配置建议:

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=32M

以下是另一个的my.ini配置建议:

port=3306
default-character-set=latin1
default-storage-engine=INNODB
sql-mode=”STRICT_TRANS_TABLES,NO_AUTO_Create_USER,NO_ENGINE_SUBSTITUTION”

max_connections=120
query_cache_size=32M

#缓存数据表数量,设置这个参数可以参见系统状态中的 open_tables(表示当前打开的数据表总数) 和 opened_tables(表示所有打开的数据表总数)
table_cache=256

#临时表的大小
tmp_table_size=12M

#缓存可重用的线程数
thread_cache_size = 64

myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
myisam_sort_buffer_size=64M

#这对MyISAM表来说非常重要。如果只是使用MyISAM表,可以把它设置为可用内存的 30-40%。合理的值取决于索引大小、数据量以及负载 — #记住,MyISAM表会使用操作系统的缓存来缓存数据,因此需要留出部分内存给它们,很多情况下数据比索引大多了。
key_buffer_size=128M

read_buffer_size=1M
read_rnd_buffer_size=512K
sort_buffer_size=1M

#这对innodb表来说非常重要
innodb_buffer_pool_size = 256M

#这取决于你需要的回复速度.128M这个数值是适当的恢复时间和良好性能之间的一个好的平衡.
innodb_log_file_size = 128M

#大多数情况4M足够,除非正将很大的blob数据导入到Innodb中可以增加一点.
innodb_log_buffer_size=4M

#这个值取决于你的程序,可能高或者低.8是代表起始值.
innodb_thread_concurrency=8

innodb_additional_mem_pool_size=100M

#如果你不是很关心ACID,可以容许在系统完全crash的情况下丢失最后一两秒的事务,那么可以设置这个值.它可以极大的提高”短”的写事务的效率.
innodb_flush_log_at_trx_commit=2
注意:
很多情况需要具体情况具体分析
1>如果Key_reads太大,则应该把my.cnf中Key_buffer_size变大,保持Key_reads/Key_read_requests至少1/100以上,越小越好。
2>如果Qcache_lowmem_prunes很大,就要增加Query_cache_size的值

晚上听到一个很悲剧的消息,我们小组长和头因为运维发了一个带%的公告,导致服务器宕机,被扣钱了,没有做特殊字符检测,同时忘记告诉运维了,这个本来应该是运维平台发消息过来,在发之前应该就屏蔽掉的,结果两边都没有做检查,就出现悲剧的事情了。下次还是小心一些微妙,仔细认真的态度做任何事情总是没错的。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

2条评论
  • rangerlee

    2011 年 8 月 23 日 18:20

    难道么有DBA么,开发人员也挺悲剧吖

    畅言 火狐浏览器 Windows Server 2003
    1. eliteYang

      2011 年 8 月 23 日 19:48

      DBA估计换过人,导致这么杯具,上次出这个问题,DBA想了N久才想出来可能是这个问题

      神话 Chrome浏览器 Windows XP

发表评论

电子邮件地址不会被公开。 必填项已用*标注