博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
postgresql 性能问题诊断总结
阅读量:5957 次
发布时间:2019-06-19

本文共 4641 字,大约阅读时间需要 15 分钟。

--如果系统出现访问缓慢,首先可以通过zabbix查看系统中的数据库连接数,cpu使用率,内存使用率,swap使用率,以及系统io吞吐是不是有明显的抖动--如果数据库连接数突增,可能是系统访问量突然增大,更有可能是数据库执行一个或多个sql,造成资源争用,数据库处理速度跟不上向数据库发送请求的速度--如果cpu空增,内存变动不大,可能是数据库在进行大量的计算,比如sql的聚合操作--如果内存使用率增大,swap使用率增大,并伴随系统中io突增,可能是大表的连接,大表的count,内存中放不少数据,系统不得不进行内存与磁盘的转换(io的read),如果io的write很高,可能是再大表创建索引--使用dstat进行实时分析dstat -cdmgnsyr --lock --ipc --top-cpu --top-io --top-mem --proc-count--将文件从磁盘的src位置拷贝到磁盘的dst位置。文件会从src先读取进入到内核空间,然后再读取到用户空间,然后拷贝数据到用户空间的buf上,再通过用户空间,内核空间,数据才到磁盘的dst上。--cpu消耗在kernel space的时候就是sy(系统态使用的cpu百分比),cpu消耗在user space的时候就是us(用户态使用的cpu百分比)。--硬中断 hi,cpu在执行程序的时候,突然外设硬件(比如硬盘出现问题了)机器需要立刻通知cpu进行现场保存工作。这个时候会cpu会出现上下文切换。--就是cpu会有一部分时间会被硬中断占用了,这个时间就是hi。相类似,si是软中断的cpu占用时间,软中断是由软件的指令方式触发的--ni每个linux进程都有个优先级,优先级高的进程有优先执行的权利,这个叫做pri。进程除了优先级外,还有个优先级的修正值。--即比如你原先的优先级是20,然后修正值为-2,那么你最后的进程优先级为18。这个修正值就叫做进程的nice值--如下图所示,usr比率较高,说明系统在执行用户的sql查询,write也比较高,说明有大量并发的写(可能是dml,也有可能是在写临时文件),--read几乎为0,且free内丰较大,说明系统内存充足,数据已缓存至内存中,故不可能为临时文件写而为dml写----total-cpu-usage---- -dsk/total- ------memory-usage----- ---paging-- -net/total- ----swap--- ---system-- --io/total- ---file-locks-- --sysv-ipc- -most-expensive- ----most-expensive---- --most-expensive- procusr sys idl wai hiq siq| read  writ| used  buff  cach  free|  in   out | recv  send| used  free| int   csw | read  writ|pos lck rea wri|msg sem shm|  cpu process   |     i/o process      |  memory process |tota 95   3   2   0   0   0|   0    40k|3809M  184M 23.5G 43.4G|   0     0 |1519k   13k|   0    32G|  28k   37k|   0  6.00 |5.0 3.0   0 8.0|  0  78   3|postgres: pos0.8|postgres   1005M  344k|postgres: ch2065M| 509 96   2   2   0   0   0|   0    40k|3800M  184M 23.5G 43.4G|   0     0 |1834k   13k|   0    32G|  29k   33k|   0  8.00 |5.0 3.0   0 8.0|  0  78   3|postgres: pos0.7|postgres    456M  171k|postgres: ch2065M| 508 96   2   1   0   0   0|   0    64k|3777M  184M 23.5G 43.4G|   0     0 |2329k   13k|   0    32G|  27k   30k|   0  13.0 |5.0 3.0   0 8.0|  0  78   3|postgres: pos0.8|postgres   1964M  684k|postgres: ch2065M| 504 95   3   2   0   0   0|   0    48k|3746M  184M 23.5G 43.4G|   0     0 |1595k   14k|   0    32G|  28k   32k|   0  12.0 |5.0 3.0   0 8.0|  0  78   3|postgres: pos0.7|postgres   2235M  861k|postgres: ch2065M| 498--如下图所示,sys比率较高,说明系统繁忙,write也比较高,说明有并发的写(可能是dml,也有可能是在写临时文件),--read也很高,且memory中free内存较少,cache 也较少 说明内存不足,paging,swap 很大,说明由于内存不足,造成数据页的换入与换出, 故此可能存在大量的磁盘文件写----total-cpu-usage---- -dsk/total- ------memory-usage----- ---paging-- -net/total- ----swap--- ---system-- --io/total- ---file-locks-- --sysv-ipc- -most-expensive- ----most-expensive---- --most-expensive-usr sys idl wai hiq siq| read  writ| used  buff  cach  free|  in   out | recv  send| used  free| int   csw | read  writ|pos lck rea wri|msg sem shm|  cpu process   |     i/o process      |  memory process  20  79   0   0   0   1|  28M  876M|5793M 29.4M 1949M  101M|  21M   13M|  45k   71k|1105M 2927M| 135k   50k|1202  44.1k|3.0   0   0 3.0|  0  68   1|flush-8:32    13|postgres: p   0  5200k|postgres: po1016M missed 30 ticks 30  68   0   0   0   1|  11M  371M|5807M 29.8M 1934M  102M|8816k    0 |  25k   31k|1102M 2930M|  44k   19k| 527  13.3k|3.0   0   0 3.0|  0  68   1|postgres: pos5.8|postgres: p   0  5720k|postgres: po1017M missed 9 ticks 17  82   0   0   0   1|  17M  719M|5802M 30.4M 1940M  101M|  12M   31M|  38k   15k|1128M 2904M| 133k   43k| 747  46.3k|3.0   0   0 3.0|  0  68   1|postgres: pos 32|postgres: p   0  6480k|postgres: po 960M missed 30 ticks--如果usr所占比率较高,说明系统中有大量的数据库进程在运行,且一直在运行,没有等待--如果sys所占比率较高,说明系统现在繁忙,可能有大量的数据库进程在等待cpu进行内存与磁盘文件的读入与读出,可查看paging和swap应该比率较高--如果read write比率较高,说明系统中有大量的数据库进程在运行,其可能在执行排序操作,由于内存不足,需要写到临时磁盘文件上,也有可能数据库并发量增大有大量的dml操作--如果cache 和 free 之后很少,说明内存不足,不得不使用swap空间--查看数据库临时表空间的大小,如果其在一直增大或者有上G的数据,说明数据库已经不能在内存中完成sql的排序或hash,不得不把中间结果写到硬盘中 du -sh %PGDATA/base/pgsql_tmp/ --查看数据库临时表空间位置--temp_tablespaces是表空间名称的列表,当列表中有一个以上名称时, PostgreSQL 每次临时对象被创建时选择一个列表中的随机数;--除了在一个事务中之外,先后创建临时对象放置在列表连续的表空间中。 --如果列表中选定的元素是一个空字符串, PostgreSQL 会自动使用当前数据库的缺省表空间 select * from pg_settings where name like '%tablespace%';--查看数据库中缓存数据的大小,正常情况下每个表的缓存大小应该是不变的,如果某几个表突然增大,可能它们被突然访问引起的,如果它们的来回变换大小,说明数据库内存已不足,内存与磁盘文件之间不得不进行交换SELECT c.relname,         pg_size_pretty(count(*) * 8192) AS buffered,         round(100.0 * count(*) /     (SELECT setting    FROM pg_settings    WHERE name='shared_buffers')::integer,1) AS buffers_percent, round(100.0 * count(*) * 8192 / pg_relation_size(c.oid),1) AS percent_of_relationFROM pg_class cINNER JOIN pg_buffercache b    ON b.relfilenode = c.relfilenodeINNER JOIN pg_database d    ON (b.reldatabase = d.oid        AND d.datname = current_database())GROUP BY  c.oid,c.relnameORDER BY  count(*)  DESC LIMIT 30;

转载地址:http://wxrxx.baihongyu.com/

你可能感兴趣的文章
RapidIOIP核的验证方法研究_王玉欢
查看>>
崩溃日志的实例
查看>>
base64是啥原理
查看>>
实战 Windows Server 2012 群集共享卷
查看>>
CSS 元素超出部分滚动, 并隐藏滚动条
查看>>
React中那些纠结你的地方(一)
查看>>
Docker入门安装教程
查看>>
PhoneGap极光推送 cordova消息推送
查看>>
Subarray Sum Equals K
查看>>
preventDefault, stopPropagation, stopImmediatePropagation 三者的区别
查看>>
超级账本HyperLedger初体验
查看>>
完美解决html中select的option不能隐藏的问题。
查看>>
推荐5大开源工具,用于开发Kubernetes项目
查看>>
制定2015年的移动开发策略
查看>>
JPA 2.2改进了易用性
查看>>
从蚂蚁金服实践入手,带你深入了解 Service Mesh
查看>>
24周年,“常青树”Delphi发布新版本10.3.1
查看>>
7. 从数据库获取数据- 从零开始学Laravel
查看>>
阿里百川码力APP监控 来了!
查看>>
使用dotenv管理环境变量
查看>>