postgresql 10 Background Writer

本文介绍了PostgreSQL数据库中背景写入器进程的工作原理及其相关参数的配置方法。背景写入器负责将脏缓冲区写入磁盘,以减少用户查询进程的等待时间。文章详细解释了bgwriter_delay、bgwriter_lru_maxpages等参数的作用,并指导如何根据实际需求调整这些设置。


https://www.postgresql.org/docs/10/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-BACKGROUND-WRITER


19.4.5. Background Writer


There is a separate server process called the background writer, whose function is to issue writes of “dirty” (new or modified) shared buffers. It writes shared buffers so server processes handling user queries seldom or never need to wait for a write to occur. However, the background writer does cause a net overall increase in I/O load, because while a repeatedly-dirtied page might otherwise be written only once per checkpoint interval, the background writer might write it several times as it is dirtied in the same interval. The parameters discussed in this subsection can be used to tune the behavior for local needs.


bgwriter_delay (integer)
Specifies the delay between activity rounds for the background writer. In each round the writer issues writes for some number of dirty buffers (controllable by the following parameters). It then sleeps for bgwriter_delay milliseconds, and repeats. When there are no dirty buffers in the buffer pool, though, it goes into a longer sleep regardless of bgwriter_delay. The default value is 200 milliseconds (200ms). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting bgwriter_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the postgresql.conf file or on the server command line.


bgwriter_lru_maxpages (integer)
In each round, no more than this many buffers will be written by the background writer. Setting this to zero disables background writing. (Note that checkpoints, which are managed by a separate, dedicated auxiliary process, are unaffected.) The default value is 100 buffers. This parameter can only be set in the postgresql.conf file or on the server command line.


bgwriter_lru_multiplier (floating point)
The number of dirty buffers written in each round is based on the number of new buffers that have been needed by server processes during recent rounds. The average recent need is multiplied by bgwriter_lru_multiplier to arrive at an estimate of the number of buffers that will be needed during the next round. Dirty buffers are written until there are that many clean, reusable buffers available. (However, no more than bgwriter_lru_maxpages buffers will be written per round.) Thus, a setting of 1.0 represents a “just in time” policy of writing exactly the number of buffers predicted to be needed. Larger values provide some cushion against spikes in demand, while smaller values intentionally leave writes to be done by server processes. The default is 2.0. This parameter can only be set in the postgresql.conf file or on the server command line.


bgwriter_flush_after (integer)
Whenever more than bgwriter_flush_after bytes have been written by the background writer, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel's page cache, reducing the likelihood of stalls when an fsync is issued at the end of a checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than shared_buffers, but smaller than the OS's page cache, where performance might degrade. This setting may have no effect on some platforms. The valid range is between 0, which disables forced writeback, and 2MB. The default is 512kB on Linux, 0 elsewhere. (If BLCKSZ is not 8kB, the default and maximum values scale proportionally to it.) This parameter can only be set in the postgresql.conf file or on the server command line.


Smaller values of bgwriter_lru_maxpages and bgwriter_lru_multiplier reduce the extra I/O load caused by the background writer, but make it more likely that server processes will have to issue writes for themselves, delaying interactive queries.


19.4.6. Asynchronous Behavior

【评估多目标跟踪方法】9个高度敏捷目标在编队中的轨迹和测量研究(Matlab代码实现)内容概要:本文围绕“评估多目标跟踪方法”,重点研究9个高度敏捷目标在编队飞行中的轨迹生成与测量过程,并提供完整的Matlab代码实现。文中详细模拟了目标的动态行为、运动约束及编队结构,通过仿真获取目标的状态信息与观测数据,用于验证和比较不同多目标跟踪算法的性能。研究内容涵盖轨迹建模、噪声处理、传感器测量模拟以及数据可视化等关键技术环节,旨在为雷达、无人机编队、自动驾驶等领域的多目标跟踪系统提供可复现的测试基准。; 适合人群:具备一定Matlab编程基础,从事控制工程、自动化、航空航天、智能交通或人工智能等相关领域的研究生、科研人员及工程技术人员。; 使用场景及目标:①用于多目标跟踪算法(如卡尔曼滤波、粒子滤波、GM-CPHD等)的性能评估与对比实验;②作为无人机编队、空中交通监控等应用场景下的轨迹仿真与传感器数据分析的教学与研究平台;③支持对高度机动目标在复杂编队下的可观测性与跟踪精度进行深入分析。; 阅读建议:建议读者结合提供的Matlab代码进行实践操作,重点关注轨迹生成逻辑与测量模型构建部分,可通过修改目标数量、运动参数或噪声水平来拓展实验场景,进一步提升对多目标跟踪系统设计与评估的理解。
本软件实现了一种基于时域有限差分法结合时间反转算法的微波成像技术,旨在应用于乳腺癌的早期筛查。其核心流程分为三个主要步骤:数据采集、信号处理与三维可视化。 首先,用户需分别执行“WithTumor.m”与“WithoutTumor.m”两个脚本。这两个程序将在模拟生成的三维生物组织环境中进行电磁仿真,分别采集包含肿瘤模型与不包含肿瘤模型的场景下的原始场数据。所获取的数据将自动存储为“withtumor.mat”与“withouttumor.mat”两个数据文件。 随后,运行主算法脚本“TR.m”。该程序将加载上述两组数据,并实施时间反转算法。算法的具体过程是:提取两组仿真信号之间的差异成分,通过一组专门设计的数字滤波器对差异信号进行增强与净化处理,随后在数值模拟的同一组织环境中进行时间反向的电磁波传播计算。 在算法迭代计算过程中,系统会按预设的周期(每n次迭代)自动生成并显示三维模拟空间内特定二维切面的电场强度分布图。通过对比观察这些动态更新的二维场分布图像,用户有望直观地识别出由肿瘤组织引起的异常电磁散射特征,从而实现病灶的视觉定位。 关于软件的具体配置要求、参数设置方法以及更深入的技术细节,请参阅软件包内附的说明文档。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值