2018做网站站长,重庆平台网站建设设计,自己做彩票网站简单吗,营销型网站的案例最近一个客户从 Oracle 迁移到 PostgreSQL 系的国产数据库后#xff0c;CPU一直接近100%#xff0c;但是再仔细分析#xff0c;发现%system CPU占到60%左右#xff0c;当然这是一种不正常的现象。之前我写过《如何在 Linux 上诊断高%Sys CPU》#xff08;https://www.anbo…最近一个客户从 Oracle 迁移到 PostgreSQL 系的国产数据库后CPU一直接近100%但是再仔细分析发现%system CPU占到60%左右当然这是一种不正常的现象。之前我写过《如何在 Linux 上诊断高%Sys CPU》https://www.anbob.com/archives/6730.html使用pidstat确认%sys cpu进程大部分为 PostgreSQL 进程pstack查看发现callPostgreSQL 的线程大部分时间都在调用newfstatat()这不是正常现象并且通常意味着数据库运行中存在频繁的文件状态检查stat操作严重时可能导致性能瓶颈。什么是 newfstatat()ENMOTECHnewfstatat()是 Linux 的系统调用用于检查文件状态类似stat()、lstat()等。PostgreSQL 在以下场景中可能频繁调用newfstatat()判断WAL文件是否存在或过期检查relation文件如表、索引文件目录扫描如pg_tblspc、pg_wal、pg_stat_tmp等检查文件是否存在或大小变化特别是在归档、WAL回放、恢复或重启点期间后台进程如checkpointer、walwriter、autovacuum、archiver可能周期性遍历文件。特别是在WAL写入或checkpoint过程中PostgreSQL 会频繁检查pg_wal目录中的文件状态。频繁调用它通常表示 PostgreSQL 正在不断访问某些文件或目录的元信息.如何分析排查ENMOTECHsys% CPU高存在2种情况常见是系统级配置还有一种是局部会话级。当看到CPU高部分人是想着赶紧优化SQL但是进数据库发现活动用户进程并非多高并发其次一些较差的应用使用DB总有优化不完的TOP SQL。如果没有成本可以让你的DBA或乙方厂家在优化SQL上面折腾或找应用厂家自查但都效果微乎其微。首先应该定位CPU使用类型与触发点。vmstat或top查看sys/user CPU占比明确范围使用pidstat查找进程pstack调用堆栈strace跟踪函数的调用位置perf做系统级负载分析。如本案例分析到是newfsatat()函数能猜到是FS文件系统相关再查看文件系统负载。使用iostat查看负载发现数据盘繁忙近100%根据之前的负载压测基线数据大概可以判断是否达到了硬件磁盘的IOPS或吞吐量上限使用iotop找I/O高的进程。优化调整ENMOTECH通过上面的排查发现是I/O方面问题并且主要进程为checkpoint进程下面可以在系统级做一些调优PostgreSQL 本地文件文件确实较多但inode使用不到10%之前我记录过《Linux最佳实践for Postgresql/openGauss》https://www.anbob.com/archives/6970.html在文件系统级有提到调整文件系统的noatime nodirtime禁用访问时间可以在线调整我们调整完后%SYS CPU有明显降低但是I/O繁忙率依旧比较高。Checkpoint是 PostgreSQL 中重要的后台进程负责将共享缓冲区中的脏页写入磁盘并确保事务日志(WAL)的一致性。优化参数主要有checkpoint_timeout增加此值可减少checkpoint频率max_wal_size控制两次checkpoint之间允许的WAL最大大小min_wal_size WAL文件回收时的最小保留大小应与max_wal_size配合调整checkpoint_completion_target控制在checkpoint_timeout内完成checkpoint的目标比例。监控Checkpoint性能SELECT * FROM pg_stat_bgwriter;SELECT checkpoints_timed, checkpoints_req, 100.0 * checkpoints_req / (checkpoints_timed checkpoints_req) AS req_checkpoint_ratio, buffers_checkpoint, buffers_cleanFROM pg_stat_bgwriter;关注以下指标checkpoints_timed – 定时触发的checkpointcheckpoints_req – 因WAL增长触发的checkpointbuffers_checkpoint – checkpoint写入的缓冲区数量buffers_clean- 后台写入器清理的缓冲区数量req_checkpoint_ratio10%(请求式checkpoint占比低)checkpoint应由超时触发(checkpoints_timed)而非WAL写满触发尤其是30%应该增加WAL优化策略减少checkpoint频率增加checkpoint_timeout和max_wal_size平滑checkpoint I/O提高checkpoint_completion_target平衡恢复时间确保max_wal_size不会导致恢复时间过长监控调整根据pg_stat_bgwriter结果持续优化-- 增加checkpoint间隔(默认5min可增至15-30min)ALTER SYSTEM SET checkpoint_timeout 30min;-- 允许更多WAL积累(默认1GB根据磁盘空间调整)ALTER SYSTEM SET max_wal_size 8GB;-- 使checkpoint写入更分散(默认0.5建议0.7-0.9)ALTER SYSTEM SET checkpoint_completion_target 0.9;查看 WAL 文件统计COUNT(*) AS total_wal_files, SUM(size) / 1024 / 1024 AS total_size_mb, (SELECT setting FROM pg_settings WHERE name max_wal_size) AS max_wal_sizeFROM pg_ls_waldir();检查 WAL 生成速率SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), 0/0) / 1024 / 1024 AS total_wal_mb, (SELECT (sum(blks_hit)sum(blks_read)) FROM pg_stat_database) AS total_io, (SELECT extract(epoch from now() - pg_postmaster_start_time()) / 3600 AS hours_up);优化高 WAL 生成的查询SELECT query, wal_bytes FROM pg_stat_statements ORDER BY wal_bytes DESC LIMIT 10;如果太多WAL文件/频繁checkpoint提高max_wal_size降低checkpoint_timeout提高checkpoint_completion_targetj.我们把max_wal_size从20G调到400G后明显磁盘的使用率降了下来。检查relation文件除了WAL清理外还有可能是检查relation文件是否存在时触发newfsatat下面测试-- session 1select pg_backend_pid();-- session 2 strace -p xxx -o s2.o-- session 1select big query....创建了一个大分区表确认有多个relation文件然后在执行此表的关联查询另一个会话使用strace跟踪后面查看newfsatat函数。发现newfsatat调用次数与表数据的文件个数并不成正比而当join时有调用newfsatat.# awk -F( {print $1} s2.o|sort|uniq -c|sort -nk 1 1 fallocate 1 ftruncate 1 mmap 1 munmap 2 epoll_pwait 2 kill 2 newfstatat 2 rt_sigprocmask 3 recvfrom 3 --- SIGUSR1 {si_signoSIGUSR1, si_codeSI_USER, si_pid2024915, si_uid1000} --- 3 --- SIGUSR1 {si_signoSIGUSR1, si_codeSI_USER, si_pid2024916, si_uid1000} --- 3 unlinkat 4 --- SIGUSR1 {si_signoSIGUSR1, si_codeSI_USER, si_pid394857, si_uid1000} --- 10 rt_sigreturn 521 brk 628 sendto 761 pread64 763 pwrite64 17138 openat 17139 close 18042 lseek# grep newfstatat s2.onewfstatat(AT_FDCWD, base/pgsql_tmp/pgsql_tmp1981697.8, {st_modeS_IFREG|0600, st_size2211840, ...}, 0) 0newfstatat(AT_FDCWD, base/pgsql_tmp/pgsql_tmp1981697.7, {st_modeS_IFREG|0600, st_size1810432, ...}, 0) 0NOTE使用newfstatat函数检查的是查询过程中的pgsql_tmp临时文件接下来可以考虑优化SQL减少temp或调DB参数。总结ENMOTECH出现newfstatat()占用大量调用栈不是bug而是 PostgreSQL 或操作系统层面在频繁获取文件元信息。但它很可能是以下问题的表现症状WAL写入压力大Checkpoint频繁归档问题文件系统性能差查询产生大量的中间temp文件数据驱动成就未来云和恩墨不负所托云和恩墨创立于2011年是业界领先的“智能的数据技术提供商”。公司以“数据驱动成就未来”为使命致力于将创新的数据技术产品和解决方案带给全球的企业和组织帮助客户构建安全、高效、敏捷且经济的数据环境持续增强客户在数据洞察和决策上的竞争优势实现数据驱动的业务创新和升级发展。自成立以来云和恩墨专注于数据技术领域根据不断变化的市场需求创新研发了系列软件产品涵盖数据库、数据库存储、数据库管理和数据智能等领域。这些产品已经在集团型、大中型、高成长型客户以及行业云场景中得到广泛应用证明了我们的技术和商业竞争力展现了公司在数据技术端到端解决方案方面的优势。
