共计 1277 个字符，预计需要花费 4 分钟才能阅读完成。
一、查看服务器配置
1、查看 CPU 个数
cat /proc/cpuinfo |grep "physical id" |sort |uniq |wc -l2、查看单个 CPU 的物理核数
cat /proc/cpuinfo |grep "cpu cores" |uniq3、查看逻辑线程数
cat /proc/cpuinfo |grep "processor" |wc -l4、查看内存大小
free5、查看存储大小
df -Th 当然，数据库优化不须要思考存储或者硬盘的大小。
我的服务器配置如下：
内存：512G
连贯存储
cpu：2cpu 24 外围 48 线程
二、配置 postgresql.conf
| 参数名称 | 默认值 | 优化值 | 参数阐明 |
|---|---|---|---|
| listen_addresses | localhost | * | 容许所有 ip 连贯 |
| max_connections | 100 | 200 | 容许的最大连接数 |
| superuser_reserved_connections | 3 | 13 | 保留给 postgres 用户的连贯，实用于切换到 postgres 用户后开启多个连贯的状况 |
| shared_buffers | 24MB | 128GB | 决定有多少内存能够被 PostgreSQL 用于缓存数据（举荐内存的 1 /4，不超过内存的 1 /2) |
| huge_pages | try | try | 应用大页，倡议 shared_buffers 超过 32GB 时开启 |
| work_mem | 1MB | 8MB | 外部排序和一些简单的查问都在这个 buffer 中实现，不过要适可而止，每个连贯都要用这么大的 |
| effective_cache_size | 4GB | 256GB | 优化器假如一个查问能够用的最大内存，和 shared_buffers 无关（举荐内存的 1 /2), 设置稍大，优化器更偏向应用索引扫描而不是程序扫描 |
| maintenance_work_mem | 64MB | 2GB | 这里定义的内存只是被 VACUUM 等消耗资源较多的命令调用时应用, 把该值调大，能放慢命令的执行 |
| vacuum_cost_limit | 200 | 500 | 清理 delete 后的空间，此时对 io 影响较大，进步该值缩小对性能的影响 |
| max_worker_processes | 8 | 128 | 最大并发过程数，parallel worker 等都算作 worker process，该值要设置的足够大 |
| max_parallel_workers_per_gather | 2 | 4 | 每个执行节点的最大并行处理过程数，应用并行查问时设置该值大于 1，不倡议超过主机 cores-2 |
| max_parallel_workers | 8 | 8 | 并行查问时，最大线程数 |
| wal_buffers | 4MB | 用于 wal 的内存大小，设置为 shared_buffers/32, 设置为 - 1 示意按 shared_buffers 计算 | |
| max_wal_size | 1GB | 256GB | 小的时候 wal 日志写入量大，越大，解体复原工夫越长 |
| min_wal_size | 80MB | 64GB | 倡议是 shared_buffers 的一半 |
| check_point_timeout | 5min | 30min | wal 查看写入磁盘的工夫距离 |
| log_destination | stderr | csvlog | 日志文件输出地 |
| log_truncate_on_rotation | off | on | 删除同名的日志文件 |
正文完
发表至： postgresql
2020-12-04
