大佬教程收集整理的这篇文章主要介绍了linux – Postmaster使用过多的CPU和磁盘写入，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
我看到过多的cpu使用率和来自postmaster任务的大量磁盘写入.即使我的应用程序几乎什么都没做(每minutE插入10次),也会发生这种情况.然而,有合理数量的连接打开.
我一直试图确定我的应用程序中是什么导致了这一点.我很喜欢postgresql,到目前为止还没到任何地方.我在配置文件中打开了一些日志记录选项,并查看了pg_stat_activity表中的连接,但它们都是空闲的.然而,每个连接消耗约50％的cpu,并且正在向磁盘写入~15M / s(什么都不读).
我基本上使用股票POSTGResql.conf只需很少的调整.我很感激任何建议或指示我可以做些什么来追踪这一点.
以下是top / iotop向我展示的示例：
cpu(s): 18.9%us,14.4%sy,0.0%ni,53.4%id,11.8%wa,0.0%hi,1.5%si,0.0%st Mem: 32865916k @R_413_10586@l,7263720k used,25602196k free,575608k buffers Swap: 16777208k @R_413_10586@l,0k used,16777208k free,4464212k cached PID USER PR NI VIRT RES SHR S %cpu %MEM TIME+ COMMAND 17057 POSTGRes 20 0 236m 33m 13m R 45.0 0.1 73:48.78 postmaster 17188 POSTGRes 20 0 219m 15m 11m R 42.3 0.0 61:45.57 postmaster 17963 POSTGRes 20 0 219m 16m 11m R 42.3 0.1 27:15.01 postmaster 17084 POSTGRes 20 0 219m 15m 11m S 41.7 0.0 63:13.64 postmaster 17964 POSTGRes 20 0 219m 17m 12m R 41.7 0.1 27:23.28 postmaster 18688 POSTGRes 20 0 219m 15m 11m R 41.3 0.0 63:46.81 postmaster 17088 POSTGRes 20 0 226m 24m 12m R 41.0 0.1 64:39.63 postmaster 24767 POSTGRes 20 0 219m 17m 12m R 41.0 0.1 24:39.24 postmaster 18660 POSTGRes 20 0 219m 14m 9.9m S 40.7 0.0 60:51.52 postmaster 18664 POSTGRes 20 0 218m 15m 11m S 40.7 0.0 61:39.61 postmaster 17962 POSTGRes 20 0 222m 19m 11m S 40.3 0.1 11:48.79 postmaster 18671 POSTGRes 20 0 219m 14m 9m S 39.4 0.0 60:53.21 postmaster 26168 POSTGRes 20 0 219m 15m 10m S 38.4 0.0 59:04.55 postmaster @R_413_10586@l DISK READ: 0.00 B/s | @R_413_10586@l DISK WRITE: 195.97 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 17962 be/4 POSTGRes 0.00 B/s 14.83 M/s 0.00 % 0.25 % POSTGRes: aggw aggw [local] idle 17084 be/4 POSTGRes 0.00 B/s 15.53 M/s 0.00 % 0.24 % POSTGRes: aggw aggw [local] idle 17963 be/4 POSTGRes 0.00 B/s 15.00 M/s 0.00 % 0.24 % POSTGRes: aggw aggw [local] idle 17188 be/4 POSTGRes 0.00 B/s 14.80 M/s 0.00 % 0.24 % POSTGRes: aggw aggw [local] idle 17964 be/4 POSTGRes 0.00 B/s 15.50 M/s 0.00 % 0.24 % POSTGRes: aggw aggw [local] idle 18664 be/4 POSTGRes 0.00 B/s 15.13 M/s 0.00 % 0.23 % POSTGRes: aggw aggw [local] idle 17088 be/4 POSTGRes 0.00 B/s 14.71 M/s 0.00 % 0.13 % POSTGRes: aggw aggw [local] idle 18688 be/4 POSTGRes 0.00 B/s 14.72 M/s 0.00 % 0.00 % POSTGRes: aggw aggw [local] idle 24767 be/4 POSTGRes 0.00 B/s 14.93 M/s 0.00 % 0.00 % POSTGRes: aggw aggw [local] idle 18671 be/4 POSTGRes 0.00 B/s 16.14 M/s 0.00 % 0.00 % POSTGRes: aggw aggw [local] idle 17057 be/4 POSTGRes 0.00 B/s 13.58 M/s 0.00 % 0.00 % POSTGRes: aggw aggw [local] idle 26168 be/4 POSTGRes 0.00 B/s 15.50 M/s 0.00 % 0.00 % POSTGRes: aggw aggw [local] idle 18660 be/4 POSTGRes 0.00 B/s 15.85 M/s 0.00 % 0.00 % POSTGRes: aggw aggw [local] idle
更新：许多文件写入似乎是$pg_DATA / base /目录中的一些临时(？)文件.这里的文件结构的My understanding是每个表基本上存储为名称为表的OID的文件.但是,有大量名为tnn_nnnnnnn的文件,并且这些文件似乎不断被写入(可能被写入).这些文件是为了什么？有大约4700个文件,大小都是8K：
-rw-------. 1 POSTGRes POSTGRes 8192 Jul 3 23:08 t12_1430975 -rw-------. 1 POSTGRes POSTGRes 8192 Jul 3 23:08 t16_1432736 -rw-------. 1 POSTGRes POSTGRes 8192 Jul 3 23:08 t28_1439066 -rw-------. 1 POSTGRes POSTGRes 8192 Jul 3 23:08 t24_1436243 -rw-------. 1 POSTGRes POSTGRes 8192 Jul 3 23:08 t24_1436210 -rw-------. 1 POSTGRes POSTGRes 8192 Jul 3 23:08 t19_1393372 -rw-------. 1 POSTGRes POSTGRes 8192 Jul 3 23:08 t28_1439051 -rw-------. 1 POSTGRes POSTGRes 8192 Jul 3 23:08 t8_1430334
更新：
在postmaster进程上运行strace基本上显示了很多文件I / O的东西：
open("base/16388/t24_1435947_fsm",O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947_vm",O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947",O_RDWR) = 9
lseek(9,SEEK_END) = 8192
ftruncate(9,0) = 0
lseek(9,SEEK_END) = 0
open("base/16388/t24_1435941",O_RDWR) = 18
lseek(18,SEEK_END) = 0
write(9,"\0\0\0\0\0\0\0\0\1\0\0\0000\0\360\37\360\37\4 \0\0\0\0b1\5\0\2\0\0\0"...,8192) = 8192
lseek(18,SEEK_END) = 0
close(9) = 0
open("base/16388/t24_1435947",SEEK_END) = 8192
close(18) = 0
close(9) = 0
open("base/16388/t24_1435944_fsm",O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944_vm",O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944",SEEK_END) = 0
close(9) = 0
更新：
所以这个问题似乎与临时表有关.我们更改了设置,因此临时表是“常规”表,所有磁盘活动都消失了,性能又回到了我预期的状态.现在,这个变化只是一个快速而肮脏的测试：如果我们真的要改变使用常规表,我们就会遇到并发和清理问题.临时表是真的那么邪恶,还是我们滥用它们？
更新：
更多背景.我正在使用内部开发的statement based replication middleware.它已经相当成熟,并且已经在许多项目中使用了很多年,但使用的是MysqL.我们在过去的一两年里一直在使用POSTGResql.我们基本上使用临时表作为复制机制的一部分.无论何时建立新连接,我们都会为数据库中的每个表创建一个临时表.使用10-20(长寿命)连接和~50个表,这可能相当于许多临时表.所有临时表都创建于：
CREATE TEMPORARY TABLE... ON COMMIT deletE ROWS;
临时表的语义非常适合我们的复制方案,并简化了我们用于MysqL的许多代码,但看起来实现也不公平.从我所做的一些研究中,我不认为临时表真正意味着我们使用它们的功能.
cpu(s): 18.9%us,0.0%st Mem: 32865916k @R_413_10586@l,575608k buffers Swap: 16777208k @R_413_10586@l,4464212k cached
在您的服务器上超过32GB,~25GB是免费的,不包括~575MB的缓冲区.
shared_buffers = 32MB # min 128kB #temp_buffers = 8MB # min 800kB #max_prepared_transactions = 0 # zero disables the feature ... #work_mem = 1MB # min 64kB #maintenance_work_mem = 16MB # min 1MB #max_stack_depth = 2MB
我假设这是一个专用数据库.如果是这样,请将其更改为以下参数并重新加载/重新启动,
shared_buffers = 16GB # min 128kB temp_buffers = 128MB # min 800kB #max_prepared_transactions = 0 # zero disables the feature ... work_mem = 8MB # min 64kB maintenance_work_mem = 64MB # min 1MB max_stack_depth = 4MB
请告诉我这会如何改变您的表现,并可以根据需要进一步调整.
关于未记录的表,如果临时表包含临时的临时数据,并且正如您所提到的那样,是在会话中创建的,最好使用未记录的表.
如果可以接受,您可以在会话后截断表.
更多信息在这里 – http://michael.otacoo.com/postgresql-2/unlogged-table-performance-in-postgresql-9-1/
以上是大佬教程为你收集整理的linux – Postmaster使用过多的CPU和磁盘写入全部内容，希望文章能够帮你解决linux – Postmaster使用过多的CPU和磁盘写入所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。