Една от по-полезните части от
документацията на PostgreSQL, върху която някога съм работил, е настройката на вашия PostgreSQL
сървър. Когато това беше написано през лятото на 2008 г., няколко месеца след
пускането на PostgreSQL 8.3, беше трудно да се намери подобно ръководство, което
да е едновременно (относително) сбито и актуално. Оттогава аз и
много други сътрудници на PostgreSQL помогнахме за поддържането на този документ
актуален, тъй като бяха направени промени в PostgreSQL.
Интересната и полезна тенденция
през този период е, че параметрите продължават да изчезват от набора
от тези, за които трябва да се тревожите. В PostgreSQL 8.2 имаше дълъг
списък с параметри, които вероятно трябва да коригирате за добра производителност
на PostgreSQL сървър:shared_buffers,effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers и (ако се използва
разделяне) constraint_exclusion.
8.3 направи автоматичното вакуумиране по подразбиране
включено с разумно поведение, заедно с премахване на няколко
параметри за фонов запис, които не са причинили нищо друго освен проблеми (те
никога не са попаднали в списъка). 8.4 премахна необходимостта от двата
max_fsm_* параметъра, увеличи default_statistics_target до много
по-добра начална стойност и направи настройката constraint_exclusion
ненужна в най-често срещаните случаи. Това са шест параметъра по-малко
които вероятно ще трябва да коригирате.
За съжаление само версия 9.0 направи
сървърната конфигурация по-сложна. А по-новите ядра на Linux дори
изместиха поведението по подразбиране назад. Започвайки с ядрото на Linux
2.6.33, избраната стойност по подразбиране за wal_sync_method се промени на
open_datasync. Това се оказва, че има ужасни последици за производителността
за PostgreSQL, особено когато се комбинира с ниската
настройка по подразбиране за wal_buffers в сървъра.
Но походът към по-добро поведение по подразбиране
наскоро се възобнови за това, което в крайна сметка се планира да бъде
PostgreSQL 9.1. По време на последния CommitFest, пач, създаден от Marti
Raudsepp, за да коригира проблема с wal_sync_method, беше ангажиран
след някои тежки спорове за това каква форма трябва да приеме тази промяна.
Откриването, че тази промяна в поведението е разрушила PostgreSQL напълно
когато се изпълнява на ext4 с опцията “data=journal” помогна
да се определи правилното нещо, което трябва да се направи тук по подразбиране.
Два параметъра, които не препоръчвам
докосването в повечето случаи са commit_siblings и commit_delay,
артефакти на по-стар опит за подобряване на производителността на системи с
бавни времена на запис (което включва повечето системи, които нямат
батериен кеш за запис за ускоряване на тази област). В днешно време
изключването на параметъра synchronous_commit, въведен в 8.3, е много по-вероятно да помогне тук. Макар че е малко вероятно те да подобрят
ефективността, хората, които се опитват да ги настроят, са пострадали повече от
необходимо от отрицателните страни на това решение. В най-лошия случай
поведението тук беше значително подобрено в кръпка, която написах, за да оптимизирам как се изпълнява логиката на управлението на тези параметри.
И тази седмица най-новият параметър, който
да бъде ефективно елиминиран в повечето случаи е wal_buffers. Предложената от мен промяна се ангажира да зададе това автоматично като процент от размера (около 3%)
разпределен към нормално много по-големите параметри shared_buffers.
Това задава стойността на wal_buffers на нормална горна граница на неговия
ефективен диапазон, 16MB, след като сте разпределили поне 512MB на
споделени_буфери. И ако изобщо сте увеличили shared_buffers от неговата малка
по подразбиране, ще получите съответно подобрение в този
важен параметър за ефективност на записване. Ще трябва да излезете от
начина си да нарушите настройката на този параметър, за да постигнете лошите
ситуации, възможни в по-ранните версии.
Количеството конфигурация, което
трябва да направите на сървъра по подразбиране, да стане по-малко сложно, винаги е
заслужава си и да видите как параметрите изчезват от критичния списък е
добре дошла промяна. Какво следва? Основните проблеми с разпределянето
споделена памет на операционни системи, извлечени от UNIX, особено Linux,
затрудняват елиминирането на споделените_буфери. А притесненията
за това, че сървърът поема системата като цяло ограничава възможността
автоматично задаване на параметри като work_mem в правилния диапазон.
Някои предложения за по-добро управление на пула на работната памет са
предложено, за да може някой да види подобрение.
Следващият параметър, който имам под око, е
checkpoint_segments. След като добавих само допълнително регистриране в тази област в
последния CommitFest, има някои подобрения в тази област, които се приближават
на ангажимента, за да подобрят поведението на контролните точки. Надявам се
в крайна сметка да превключя настройката на контролните точки, за да бъде строго контролирана
чрез ориентирани към времето параметри, вместо да изисквам от потребителите да
разбират механиката на това как работи дневникът за предварителна запис, за да настрои
br />система. Все още има твърде много грозни ситуации, възможни за това
това навреме за 9.1, но автоматичното задаване на броя на сегментите е
възможно да се насочи към 9.2.
