Създаване на оптимална среда за PostgreSQL

Добре дошли в PostgreSQL, мощна система за бази данни с отворен код, която може да хоства всичко от няколко мегабайта клиентски данни за малък градски бизнес до стотици терабайта „големи данни“ за мултинационални корпорации. Независимо от приложението, вероятно ще е необходима известна помощ за настройка и конфигуриране, за да подготвите базата данни за действие.

Когато се инсталира нов сървър, настройките на PostgreSQL са много минимални, тъй като са проектирани да работят с възможно най-малко хардуер. Те обаче много рядко са оптимални. Тук ще разгледаме основна настройка за нови проекти и как да настроим PostgreSQL да работи най-оптимално при нови проекти.

Хостинг

Хостинг на място

С локална база данни най-добрият вариант е за гол метален хост, тъй като виртуалните машини обикновено работят по-бавно, освен ако не говорим за VM от висок клас корпоративно ниво. Това също така позволява по-строг контрол върху настройките на процесора, паметта и диска. Това обаче идва с необходимостта да имате на разположение експерт (или договор) за поддръжка на сървъра.

Облак

Хостването на база данни в облака може да бъде прекрасно в някои аспекти или кошмар в други. Освен ако избраната облачна платформа не е силно оптимизирана (което обикновено означава по-висока цена), може да има проблеми със среди с по-високо натоварване. Следете дали облачният сървър е споделен или посветен (посветен, позволяващ пълна производителност от сървъра за приложението), както и нивото на IOPS (входно/изходни операции в секунда), осигурено от облачен сървър. Когато (или ако) приложението нарасне до степен, че по-голямата част от данни не могат да се съхраняват в паметта, скоростта на достъп до диска е от решаващо значение.

Обща настройка на хост

Основните стълбове, необходими за надеждна настройка на PostgreSQL, се основават на възможностите на процесора, паметта и диска на хоста. В зависимост от нуждите на приложенията, достатъчен хост, както и добре настроена PostgreSQL конфигурация ще окажат невероятно въздействие върху производителността на системата на базата данни.

Избор на операционна система

PostgreSQL може да се компилира на повечето Unix-подобни операционни системи, както и на Windows. Въпреки това производителността на Windows дори не е сравнима с Unix-подобна система, така че освен ако не е за малък проект, придържането към установена Unix-подобна система ще бъде начинът. За тази дискусия ще се придържаме към системи, базирани на Linux.

Привидно най-използваната Linux дистрибуция, използвана за хостване на PostgreSQL, е базирана на Red Hat система, като CentOS или Scientific Linux, или дори самата Red Hat. Тъй като Red Hat и CentOS се фокусират върху стабилността и производителността, общността зад тези проекти работи усилено, за да гарантира, че важни приложения, като бази данни, са на възможно най-сигурната и надеждна версия на Linux.

ЗАБЕЛЕЖКА:Linux има набор от версии на ядрото, които не са оптимални за изпълнение на PostgreSQL, така че е силно препоръчително да се избягват, ако е възможно (особено в приложения, където максималната производителност е от първостепенно значение). Бенчмарковете показват, че броят на транзакциите в секунда намалява спрямо версията на ядрото 3.4 – 3.10, но се възстановява и значително се подобрява в ядрото 3.12. Това за съжаление изключва използването на CentOS 7, ако вървите по маршрута на CentOS. CentOS 6 все още е валидна и поддържана версия на операционната система и се очаква CentOS 8 да бъде пуснат преди 6 да стане неподдържан.

Инсталиране

Инсталацията може да бъде извършена или от източник, или с помощта на хранилища, поддържани от избраната дистрибуция на Linux, или още по-добре, PostgreSQL Global Development Group (PGDG), която поддържа хранилища за базирани на Red Hat системи (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux и Fedora), както и пакети за Debian и Ubuntu. Използването на пакетите PGDG ще гарантира, че актуализациите на PostgreSQL са достъпни за актуализиране при пускането им, вместо да чакате вградените хранилища на Linux дистрибуцията да ги одобри и предостави.

ЦП

В наши дни не е трудно да разполагате с множество ядра за хост на база данни. Самият PostgreSQL едва наскоро започна да добавя многонишкови възможности на ниво заявка и ще става много по-добър през следващите години. Но дори и без тези нови и предстоящи подобрения, самият PostgreSQL създава нови нишки за всяка връзка с базата данни от клиент. Тези нишки по същество ще използват ядро, когато са активни, така че броят на необходимите ядра ще зависи от нивото на необходимите едновременни връзки и едновременни заявки.

Добра изходна линия, с която да започнете, е 4-ядрена система за малко приложение. Ако приемем, че приложенията танцуват между изпълнение на заявки и заспиване, 4-ядрената система може да се справи с няколко десетки връзки, преди да бъде претоварена. Добавянето на повече ядра ще помогне за мащабиране с нарастващо работно натоварване. Не е необичайно много големи PostgreSQL бази данни да имат 48+ ядра, за да обслужват много стотици връзки.

Съвети за настройка: Дори ако хипер-нишковостта е налична, транзакциите в секунда обикновено са по-високи, когато хипер-нишковостта е деактивирана. За заявки към база данни, които не са твърде сложни, но с по-висока честота, повече ядра е по-важно от по-бързите ядра.

Памет

Паметта е изключително важен аспект за цялостната производителност на PostgreSQL. Основната настройка за PostgreSQL по отношение на паметта е shared_buffers, която е част от паметта, разпределена директно на сървъра на PostgreSQL за кеширане на данни. Колкото по-голяма е вероятността необходимите данни да живеят в паметта, толкова по-бързо се връщат заявките, а по-бързите заявки означават по-ефективна настройка на ядрото на процесора, както беше обсъдено в предишния раздел.

Заявките също така понякога се нуждаят от памет, за да извършват операции по сортиране на данни, преди да бъдат върнати на клиента. Това или използва допълнителна ad-hoc памет (отделно от shared_buffers), или временни файлове на диска, което е много по-бавно.

Съвети за настройка: Основна отправна точка за настройка на shared_buffers е да го настроите на 1/4 от стойността на наличната системна памет. Това позволява на операционната система също да извършва собствено кеширане на данни, както и на всички работещи процеси, различни от самата база данни.

Увеличаването на work_mem може да ускори операциите по сортиране, но увеличаването му твърде много може да принуди хоста да свърши цялата памет, тъй като зададената стойност може да бъде частично или напълно издадена няколко пъти на заявка. Ако множество заявки изискват множество блокове памет за сортиране, тя може бързо да добави повече памет от тази, която е налична на хоста. Поддържайте го ниско и го повишавайте бавно, докато ефективността стане желаната.

С помощта на командата „free“ (като „free -h“), задайте efektivn_cache_size на сумата от паметта, която е свободна и кеширана. Това позволява на планировчика на заявки да знае, че нивото на кеширане на ОС може да е налично и да изпълнява по-добри планове за заявки.

Диск

Производителността на диска може да бъде едно от по-важните неща, които трябва да имате предвид при настройването на система. Скоростите на вход/изход са важни за големи натоварвания на данни или за извличане на огромни количества данни за обработка. Той също така определя колко бързо PostgreSQL може да синхронизира паметта с диска, за да поддържа пула памет оптимален.

Известна подготовка на дискове може да помогне за незабавно подобряване на потенциалната производителност, както и да бъде доказателство за растеж на системата за бази данни.

• Отделни дискове

  Новата инсталация на PostgreSQL ще създаде директорията с данни на клъстера някъде на основното (и вероятно единственото) налично устройство в системата.

  Основната настройка, използваща повече устройства, би била добавянето на отделно устройство (или набор от устройства чрез RAID). Той има предимството, че целият трансфер на данни, свързан с базата данни, работи на различен I/O канал от основната операционна система. Освен това позволява на базата данни да се разраства без страх от недостатъчно пространство, което ще доведе до проблеми и грешки другаде в операционната система.

  За бази данни с изключително голямо количество активност, директорията PostgreSQL Transaction Log (xlog) може да бъде поставена на още едно устройство, отделяйки по-тежки I/O към друг канал, далеч от основната ОС, както и от основната директория с данни. Това е усъвършенствана мярка, която помага да се изстиска повече производителност от системата, която иначе може да е близо до границите си.

• Използване на RAID

  Настройката на RAID за устройствата на базата данни не само предпазва от загуба на данни, но също така може да подобри производителността, ако използвате правилната RAID конфигурация. Обикновено се смята, че RAID 1 или 10 са най-добрите, а 10 предлага паритет и обща скорост. RAID 5 обаче, макар и да има по-високи нива на резервиране, страда от значително намаляване на производителността поради начина, по който разпространява данни около множество дискове. Планирайте най-добрата налична опция с много място за увеличаване на данните и това ще бъде конфигурация, която няма да се налага да се променя често, ако изобщо.

• Използване на SSD

  Твърдотелните дискове са чудесни за производителност и ако отговарят на бюджета, корпоративните SSD могат да направят тежките работни натоварвания по обработка на данни нощ и ден по-бързи. По-малки до средни бази данни с по-малки до средни натоварвания може да са излишни, но когато се борите за най-малкото процентно увеличение при големи приложения, SSD може да бъде този сребърен куршум.

Съвети за настройка: Изберете настройка на устройството, която е най-добра за конкретното приложение и има достатъчно място, което да нараства с времето с увеличаване на данните.

Ако използвате SSD, настройката на random_page_cost на 1,5 или 2 (по подразбиране е 4) ще бъде от полза за планировчика на заявки, тъй като произволното извличане на данни е много по-бързо, отколкото се наблюдава на въртящи се дискове.

Начални настройки за конфигуриране

Когато настройвате PostgreSQL за първи път, има шепа конфигурационни настройки, които могат лесно да се променят въз основа на мощността на хоста. Тъй като приложението отправя заявки към базата данни с течение на времето, може да се извърши специфична настройка въз основа на нуждите на приложението. Това обаче ще бъде тема за отделен блог за настройка.

Настройки на паметта

shared_buffers:Задава се на 1/4 от системната памет. Ако системата има по-малко от 1 GB обща памет, задайте ~ 1/8 от общата системна памет

work_mem:По подразбиране е 4MB и дори може да е достатъчно за въпросното приложение. Но ако временните файлове се създават често и тези файлове са доста малки (десетки мегабайта), може да си струва да увеличите тази настройка. Консервативна настройка за входно ниво може да бъде (1/4-та системна памет / max_connections). Тази настройка зависи силно от действителното поведение и честотата на заявките към базата данни, така че трябва да се увеличава само с повишено внимание. Бъдете готови да го намалите до предишните нива, ако възникнат проблеми.

Effective_cache_size:Задайте сумата от свободната и кеширана памет, отчетена от командата „free“.

Настройки на контролната точка

За PostgreSQL 9.4 и по-долу:
checkpoint_segments:Брой сегменти на контролна точка (по 16 мегабайта всеки), които дават системата за запис напред. По подразбиране е 3 и може безопасно да се увеличи до 64 дори за малки бази данни.

За PostgreSQL 9.5 и по-нова версия:
max_wal_size:Това замени checkpoint_segments като настройка. По подразбиране е 1GB и може да остане тук, докато не са необходими допълнителни промени.

Сигурност

listen_address:Тази настройка определя на кои лични IP адреси/мрежови карти да слушате връзки. При проста настройка вероятно ще има само една, докато по-напредналите мрежи може да имат множество карти за свързване към множество мрежи. * Означава да слушате всичко. Въпреки това, ако приложението, което осъществява достъп до базата данни, трябва да живее на същия хост като самата база данни, запазването му като „localhost“ е достатъчно.

Регистриране

Някои основни настройки за регистриране, които няма да претоварват регистрационните файлове, са както следва.

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0