性能调优

1.1.1.  调优原因

应用服务器: 暂时无瓶颈

mysql服务器

db出现严重的IO瓶颈,

调优前外部表现:

1.1.2.  分析过程

系统调优由易到难的先后顺序如下:

1.        硬件问题

2.        网络问题

3.        应用服务器、数据库等配置问题

4.        源代码、数据库脚本问题

5.        系统构架问题

通过后他命令vmstat  2

1 系统级IO监控

%util        代表磁盘繁忙程度。100% 表示磁盘繁忙, 0%表示磁盘空闲。但是注意,磁盘繁忙不代表磁盘(带宽)利用率高

argrq-sz    提交给驱动层的IO请求大小,一般不小于4K,不大于max(readahead_kb, max_sectors_kb)

可用于判断当前的IO模式,一般情况下,尤其是磁盘繁忙时, 越大代表顺序,越小代表随机

svctm        一次IO请求的服务时间,对于单块盘,完全随机读时,基本在7ms左右,既寻道+旋转延迟时间

注: 各统计量之间关系

=======================================

%util = ( r/s  +  w/s) * svctm / 1000                        # 队列长度 =  到达率    *  平均服务时间

avgrq-sz = ( rMB/s + wMB/s) * 2048 / (r/s  + w/s)    # 2048 为 1M / 512

=======================================

总结:

iostat 统计的是通用块层经过合并(rrqm/s, wrqm/s)后,直接向设备提交的IO数据,可以反映系统整体的IO状况,但是有以下2个缺点:

1  距离业务层比较遥远,跟代码中的write,read不对应(由于系统预读 + pagecache + IO调度算法等因素, 也很难对应)

2  是系统级,没办法精确到进程,比如只能告诉你现在磁盘很忙,但是没办法告诉你是谁在忙,在忙什么?

分析结果:

2 进程级IO监控

iotop 和 pidstat (仅rhel6u系列)

iotop    顾名思义, io版的top

pidstat 顾名思义, 统计进程(pid)的stat,进程的stat自然包括进程的IO状况

这两个命令,都可以按进程统计IO状况,因此可以回答你以下二个问题

当前系统哪些进程在占用IO,百分比是多少?

占用IO的进程是在读?还是在写?读写量是多少?

pidstat -u -r -d -t 1

3 业务级IO监控

    ioprofile

    ioprofile 命令本质上是 lsof + strace, 具体下载可见 http://code.google.com/p/maatkit/

    ioprofile 可以回答你以下三个问题:

    1  当前进程某时间内,在业务层面读写了哪些文件(read, write)?

    2  读写次数是多少?(read, write的调用次数)

    3  读写数据量多少?(read, write的byte数)

4 文件级IO监控

    文件级IO监控可以配合/补充"业务级和进程级"IO分析

      文件级IO分析,主要针对单个文件, 回答当前哪些进程正在对某个文件进行读写操作.

      1 lsof  或者  ls /proc/pid/fd

      2 inodewatch.stp

lsof  告诉你 当前文件由哪些进程打开

1.1.3.  调优过程

1.db调优,针对目前MariaDB的参数修改调整,通过压测调整 (2天)

修改前文件空

参数修改:

[root@host-172-19-1-27 my.cnf.d]# vim /etc/my.cnf.d/server.cnf

[server]

[mysqld]

slow_query_log = on      //慢sql开关打开

long_query_time = 1      //设定确认慢sql阈值

slow_query_log_file=/tmp/slow.log.last      //导出慢sql路径

log_slow_verbosity=query_plan

symbolic-links=0

character_set_server=utf8

skip-name-resolve

back_log = 1500

max_connections = 2000

max_connect_errors = 6000

table_open_cache = 8000

max_allowed_packet = 1024M

binlog_cache_size = 1M

max_heap_table_size = 256M

tmp_table_size = 256M

innodb_checksums=0

innodb_use_native_aio=1

read_buffer_size = 8M

read_rnd_buffer_size = 8M

sort_buffer_size = 8M

join_buffer_size = 8M

key_buffer_size = 256M

thread_cache_size = 8

query_cache_size = 128M

query_cache_limit = 32M

ft_min_word_len = 4

log_bin = mysql-bin

relay-log=relay-log-bin

server-id=1

log-slave-updates=true

sync-master-info=1

binlog-checksum=CRC32

master-verify-checksum=1

slave-sql-verify-checksum=1

report-port=3306

report-host=10.214.129.187

binlog_format = ROW

expire_logs_days = 7

log_error = mysql-error.log

skip-external-locking

default_storage_engine = InnoDB

innodb_flush_method=O_DIRECT

innodb_file_per_table = 1

innodb_open_files = 4000

innodb_buffer_pool_size = 12288M

innodb_thread_concurrency = 0

innodb_flush_log_at_trx_commit = 0

innodb_log_buffer_size = 64M

innodb_log_file_size = 1024M

innodb_log_files_in_group = 3

innodb_max_dirty_pages_pct = 90

innodb_lock_wait_timeout = 120

innodb_read_io_threads = 4

innodb_write_io_threads = 4

innodb_doublewrite=0

innodb_support_xa=0

bulk_insert_buffer_size = 64M

myisam_sort_buffer_size = 8M

myisam_max_sort_file_size = 1G

myisam_repair_threads = 1

interactive_timeout = 2880000

wait_timeout = 2880000

collation-server=utf8_general_ci

[galera]

[embedded]

[mariadb]

[mariadb-10.1]

//后面为原始值

#skip-external-locking

#key_buffer_size = 256M

#max_allowed_packet = 1M

#table_open_cache = 256

#sort_buffer_size = 1M

#read_buffer_size = 1M

#read_rnd_buffer_size = 4M

#myisam_sort_buffer_size = 64M

#thread_cache_size = 8

#query_cache_size= 16M

#log-bin=mysql-bin

#server-id=1

#binlog-format=ROW

#character-set-server=utf8

#collation-server=utf8_general_c

2.容器调优,针对目前tomcat的参数调整,通过压测调整  (2天)

 

   

protocol="org.apache.coyote.http11.Http11NioProtocol"

connectionTimeout="20000"  //

redirectPort="9443"

2              maxThreads="4000"      //调整线程的数目

minSpareThreads="4000"

maxSpareThreads="4500"

acceptCount="4100"

1              enableLookups="false"    //停用DNS 查询

debug="0"

/>

   

   

3.      //--配置引擎--

3.OS调优,确定os 相关性能参数调整(TCP limit ,文件页大小) (1天)

4.硬件方面,根据具体情况调查online硬件参数,cpu多核亲和性,IO硬件参数。 (1天)

app:

cpu: Intel Core Processor (Haswell, no TSX)  8core

memory: 16g

disk: 65g

db:

cpu: Intel Core Processor (Haswell, no TSX) 8core

memory: 16g

disk: 65g

5.日志配置对系统性能影响 (0.5天)

1.1.4.  调优结果

                     

 

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,033评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,725评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,473评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,846评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,848评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,691评论 1 282
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,053评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,700评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,856评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,676评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,787评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,430评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,034评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,990评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,218评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,174评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,526评论 2 343

推荐阅读更多精彩内容