wal_buffers默认值为-1,此时wal_buffers使用的是shared_buffers,wal_buffers大小为shared_buffers的1/32
autovacuum_work_mem默认值为-1,此时使用maintenance_work_mem的值
计算公式为:
max_connections*work_mem + max_connections*temp_buffers +shared_buffers+(autovacuum_max_workers * maintenance_work_mem)
假设PostgreSQL的配置如下:
max_connections = 100 temp_buffers=32MB work_mem=32MB shared_buffers=19GB autovacuum_max_workers = 3 maintenance_work_mem=1GB #默认值64MB
select( (100*(32*1024*1024)::bigint) + (100*(32*1024*1024)::bigint) + (19*(1024*1024*1024)::bigint) + (3 * (1024*1024*1024)::bigint ) )::float8 / 1024 / 1024 / 1024 --output 28.25
此时pg满载峰值时最多使用28.25GB内存,物理内容为32GB时,还有3.75GB内存给操作系统使用.
计算公式为:
max_connections*work_mem + max_connections*temp_buffers +shared_buffers+wal_buffers+(autovacuum_max_workers * autovacuum_work_mem)
假设PostgreSQL的配置如下:
max_connections = 100 temp_buffers=32MB work_mem=32MB shared_buffers=19GB wal_buffers=16MB #--with-wal-segsize的默认值 autovacuum_max_workers = 3 maintenance_work_mem=1GB
select( (100*(32*1024*1024)::bigint) + (100*(32*1024*1024)::bigint) + (19*(1024*1024*1024)::bigint) + (16*1024*1024)::bigint + (3 * (1024*1024*1024)::bigint ) )::float8 / 1024 / 1024 / 1024 --output 28.26
此时pg满载峰值时最多使用28.5GB内存,物理内容为32GB,还有3.5GB内存给操作系统使用.
计算公式为:
max_connections*work_mem + max_connections*temp_buffers +shared_buffers+wal_buffers+(autovacuum_max_workers * autovacuum_work_mem)+ maintenance_work_mem
假设PostgreSQL的配置如下:
max_connections = 100 temp_buffers=32MB work_mem=32MB shared_buffers=19GB wal_buffers=262143kb autovacuum_max_workers = 3 autovacuum_work_mem=256MB maintenance_work_mem=2GB
select( (100*(32*1024*1024)::bigint) + (100*(32*1024*1024)::bigint) + (19*(1024*1024*1024)::bigint) + (262143*1024)::bigint + (3 * (256*1024*1024)::bigint ) + ( 2 * (1024*1024*1024)::bigint ) )::float8 / 1024 / 1024 / 1024 --output 28.01
此时pg载峰值时最多使用28.25GB内存,物理内容为32GB时,还有3.75GB内存给操作系统使用.建议所有内存消耗根据硬件配置,也就是使用这个配置.
补充:postgresql 内存使用配置
shared_buffers:这是最重要的参数,postgresql通过shared_buffers和内核和磁盘打交道,因此应该尽量大,让更多的数据缓存在shared_buffers中。通常设置为实际RAM的10%是合理的,比如50000(400M)
work_mem: 在pgsql 8.0之前叫做sort_mem。postgresql在执行排序操作时,会根据work_mem的大小决定是否将一个大的结果集拆分为几个小的和 work_mem查不多大小的临时文件。显然拆分的结果是降低了排序的速度。因此增加work_mem有助于提高排序的速度。通常设置为实际RAM的2% -4%,根据需要排序结果集的大小而定,比如81920(80M)
effective_cache_size:是postgresql能够使用的最大缓存,这个数字对于独立的pgsql服务器而言应该足够大,比如4G的内存,可以设置为3.5G(437500)
maintenance_work_mem:这里定义的内存只是在CREATE INDEX, VACUUM等时用到,因此用到的频率不高,但是往往这些指令消耗比较多的资源,因此应该尽快让这些指令快速执行完毕:给maintence_work_mem大的内存,比如512M(524288)
max_connections: 通常,max_connections的目的是防止max_connections * work_mem超出了实际内存大小。比如,如果将work_mem设置为实际内存的2%大小,则在极端情况下,如果有50个查询都有排序要求,而且都使 用2%的内存,则会导致swap的产生,系统性能就会大大降低。当然,如果有4G的内存,同时出现50个如此大的查询的几率应该是很小的。不过,要清楚 max_connections和work_mem的关系。
配置 主机: 32GB
shared_buffers = 1024MB work_mem = 1MB effective_cache_size = 20480MB maintenance_work_mem = 1024MB max_connections = 8000
以上为个人经验,希望能给大家一个参考,也希望大家多多支持小牛知识库。如有错误或未考虑完全的地方,望不吝赐教。
本文向大家介绍浅谈mysql explain中key_len的计算方法,包括了浅谈mysql explain中key_len的计算方法的使用技巧和注意事项,需要的朋友参考一下 mysql的explain命令可以分析sql的性能,其中有一项是key_len(索引的长度)的统计。本文将分析mysql explain中key_len的计算方法。 1、创建测试表及数据 2、查看explain name的字
本文向大家介绍浅谈内存耗尽后Redis会发生什么,包括了浅谈内存耗尽后Redis会发生什么的使用技巧和注意事项,需要的朋友参考一下 前言 作为一台服务器来说,内存并不是无限的,所以总会存在内存耗尽的情况,那么当 Redis 服务器的内存耗尽后,如果继续执行请求命令,Redis 会如何处理呢? 内存回收 使用Redis 服务时,很多情况下某些键值对只会在特定的时间内有效,为了防止这种类型的数据一直占
问题内容: 我需要监视应用程序产生的线程消耗的内存量。如果贪婪的线程消耗太多内存,则想法是采取纠正措施。我已提到Java线程占用多少内存?。关于该链接的建议之一是在我尝试以下工作时使用。 我在四个线程上运行了很长时间。尽管作业不会连续地累积内存,但是所返回的值会不断增加,甚至不会下降。这意味着不会返回线程使用的堆上的实际内存量。它返回自线程启动以来在堆上为线程分配的内存总量。我的平台详细信息如下:
我需要监控应用程序生成的线程所消耗的内存量。如果贪婪的线程占用了太多内存,那么我们可以采取纠正措施。我提到了我的java线程需要多少内存?。关于该链接的建议之一是在ThreadMXBean中使用getThreadAllocatedBytes 我用以下作业试验了getThreadAllocatedBytes。 我在四个线程上运行了相当长的时间。虽然作业不会连续累积内存,但getThreadAlloc
本文向大家介绍C语言获取消耗内存的方法,包括了C语言获取消耗内存的方法的使用技巧和注意事项,需要的朋友参考一下 本文实例讲述了C语言获取消耗内存的方法。分享给大家供大家参考。具体实现方法如下: 希望本文所述对大家的C语言程序设计有所帮助。
本文向大家介绍浅谈c# 浮点数计算,包括了浅谈c# 浮点数计算的使用技巧和注意事项,需要的朋友参考一下 给大家看个计算题,看看大家的算术能力。 0.1 +0.1 +0.1 - 0.3 等于几? 大家可能会说这么简单的问题,是不是看不起我?肯定等于0啊。 如果大家直接算的是没有问题的,但是如果用计算机呢? 见证奇迹的时刻到了,看代码: 运行结果: 这是因为计算机的精度的问题,在计算机的内部存储和运算