Първо, винаги използвайте най-новата версия на PostgreSQL. Подобренията в производителността винаги идват, така че вероятно губите времето си, ако настройвате стара версия. Например, PostgreSQL 9.2 значително подобрява скоростта на TRUNCATE и разбира се добавя сканирания само за индекс. Винаги трябва да се следват дори незначителни издания; вижте правилата за версията.
Не трябва
НЕ поставете пространство за таблица на RAM диск или друго нетрайно съхранение.
Ако загубите пространство за таблици, цялата база данни може да бъде повредена и трудна за използване без значителна работа. Има много малко предимство в това в сравнение с използването само на UNLOGGED таблици и все пак да имате много RAM за кеш.
Ако наистина искате система, базирана на ramdisk, initdb изцяло нов клъстер на ramdisk от initdb инсталирайте нов екземпляр на PostgreSQL на ramdisk, така че да имате напълно еднократен екземпляр на PostgreSQL.
Конфигурация на PostgreSQL сървър
Когато тествате, можете да конфигурирате сървъра си за неиздръжлива, но по-бърза работа.
Това е една от единствените приемливи употреби на fsync=off настройка в PostgreSQL. Тази настройка до голяма степен казва на PostgreSQL да не се занимава с поръчани записи или други неприятни неща за защита на целостта на данните и безопасност при сривове, като му дава разрешение да изтрие напълно вашите данни, ако загубите захранване или имате срив на ОС.
Излишно е да казвам, че никога не трябва да активирате fsync=off в производство, освен ако не използвате Pg като временна база данни за данни, които можете да генерирате отново от другаде. Ако и само ако правите да изключите fsync, можете също да включите full_page_writes изключен, тъй като тогава вече не носи никаква полза. Внимавайте, че fsync=off и full_page_writes кандидатствайте в клъстера ниво, така че те засягат всички бази данни във вашия PostgreSQL екземпляр.
За производствена употреба можете да използвате synchronous_commit=off и задайте commit_delay , тъй като ще получите много от същите предимства като fsync=off без гигантския риск от корупция на данни. Имате малък прозорец на загуба на скорошни данни, ако активирате асинхронния комит - но това е всичко.
Ако имате възможност да промените леко DDL, можете също да използвате UNLOGGED таблици в Pg 9.1+, за да избегнете напълно регистрирането на WAL и да получите реален тласък на скоростта с цената на изтриването на таблиците, ако сървърът се срине. Няма опция за конфигурация, която да направи всички таблици нерегистрирани, тя трябва да бъде зададена по време на CREATE TABLE . Освен че е добро за тестване, това е удобно, ако имате таблици, пълни с генерирани или маловажни данни в база данни, която иначе съдържа неща, от които се нуждаете, за да сте в безопасност.
Проверете вашите регистрационни файлове и вижте дали получавате предупреждения за твърде много контролни точки. Ако сте, трябва да увеличите своите checkpoint_segments. Може също така да настроите своя checkpoint_completion_target за изглаждане на записите.
Настройте shared_buffers да отговарят на вашето работно натоварване. Това зависи от операционната система, зависи от това какво още се случва с вашата машина и изисква известни опити и грешки. Настройките по подразбиране са изключително консервативни. Може да се наложи да увеличите максималната споделена памет на операционната система, ако увеличите shared_buffers на PostgreSQL 9.2 и по-долу; 9.3 и по-нови промениха как използват споделена памет, за да избегнат това.
Ако използвате само няколко връзки, които вършат много работа, увеличете work_mem за да им дадете повече RAM, с които да играят за сортове и т.н. Внимавайте, че е твърде висок work_mem настройката може да причини проблеми с липсата на памет, защото е за сорт, а не за връзка, така че една заявка може да има много вложени сортове. Само ти наистина трябва да увеличите work_mem ако можете да видите разливане на сортове на диск в EXPLAIN или регистриран с log_temp_files настройка (препоръчително), но по-висока стойност може също да позволи на Pg да избира по-интелигентни планове.
Както каза друг постер тук, е разумно да поставите xlog и основните таблици/индекси на отделни твърди дискове, ако е възможно. Отделните дялове е доста безсмислено, наистина искате отделни дискове. Това разделяне има много по-малко полза, ако работите с fsync=off и почти никакви, ако използвате UNLOGGED таблици.
Накрая настройте вашите запитвания. Уверете се, че вашият random_page_cost и seq_page_cost отразяват производителността на вашата система, уверете се, че вашият effective_cache_size е правилно и т.н. Използвайте EXPLAIN (BUFFERS, ANALYZE) за да разгледате индивидуалните планове за заявка и завъртете auto_explain модул за отчитане на всички бавни заявки. Често можете да подобрите драстично ефективността на заявката, само като създадете подходящ индекс или настроите параметрите на разходите.
AFAIK няма начин да зададете цяла база данни или клъстер като UNLOGGED . Би било интересно да мога да го направя. Помислете да попитате в пощенския списък на PostgreSQL.
Настройка на хост OS
Има някои настройки, които можете да направите и на ниво операционна система. Основното нещо, което може да искате да направите, е да убедите операционната система да не изтрива агресивно записите на диска, тъй като наистина не ви пука кога/ако ще го направят на диска.
В Linux можете да контролирате това с dirty_* на подсистемата на виртуалната памет настройки, като dirty_writeback_centisecs .
Единственият проблем с настройката на настройките за обратно запис, за да бъдат твърде слаби, е, че изтриване от друга програма може да доведе до изчистване на всички натрупани буфери на PostgreSQL, което води до големи спирания, докато всичко блокира при запис. Може да успеете да облекчите това, като стартирате PostgreSQL на друга файлова система, но някои изтривания може да са на ниво устройство или на ниво цял хост, а не на ниво файлова система, така че не можете да разчитате на това.
Тази настройка наистина изисква да си поиграете с настройките, за да видите кое работи най-добре за вашето работно натоварване.
При по-новите ядра може да искате да се уверите, че vm.zone_reclaim_mode е настроен на нула, тъй като може да причини сериозни проблеми с производителността на NUMA системите (повечето системи в наши дни) поради взаимодействия с начина, по който PostgreSQL управлява shared_buffers .
Настройка на заявки и натоварване
Това са неща, които НЕ изискват промени в кода; може и да не ти подхождат. Някои са неща, които може да успеете да приложите.
Ако не групирате работата в по-големи транзакции, започнете. Много малки транзакции са скъпи, така че трябва да групирате неща, когато това е възможно и практично. Ако използвате асинхронен комит, това е по-малко важно, но все пак силно се препоръчва.
Когато е възможно, използвайте временни таблици. Те не генерират WAL трафик, така че са много по-бързи за вмъкване и актуализации. Понякога си струва да вмъкнете куп данни във временна таблица, да я манипулирате, както е необходимо, след което да направите INSERT INTO ... SELECT ... за да го копирате на финалната маса. Имайте предвид, че временните таблици са на сесия; ако сесията ви приключи или загубите връзката си, временната таблица изчезва и никоя друга връзка не може да види съдържанието на временната(ите) таблица(и) на сесия.
Ако използвате PostgreSQL 9.1 или по-нова версия, можете да използвате UNLOGGED таблици за данни, които можете да си позволите да загубите, като състояние на сесията. Те се виждат в различни сесии и се запазват между връзките. Те се съкращават, ако сървърът се изключи нечисто, така че не могат да се използват за нищо, което не можете да създадете отново, но са чудесни за кешове, материализирани изгледи, таблици на състоянията и т.н.
Като цяло, не DELETE FROM blah; . Използвайте TRUNCATE TABLE blah; вместо; това е много по-бързо, когато изхвърляте всички редове в таблица. Съкратете много таблици в един TRUNCATE обади се ако можеш. Има предупреждение, ако правите много TRUNCATES на малки маси отново и отново; вижте:Скорост на съкращаване на Postgresql
Ако нямате индекси на външни ключове, DELETE s, включващи първичните ключове, посочени от тези външни ключове, ще бъде ужасно бавно. Не забравяйте да създадете такива индекси, ако някога очаквате да DELETE от посочената таблица(и). Индексите не са необходими за TRUNCATE .
Не създавайте индекси, от които не се нуждаете. Всеки индекс има разходи за поддръжка. Опитайте се да използвате минимален набор от индекси и оставете сканирането на растерни индекси да ги комбинира, вместо да поддържате твърде много огромни, скъпи индекси с няколко колони. Когато се изискват индекси, опитайте първо да попълните таблицата, след което създайте индекси в края.
Хардуер
Наличието на достатъчно RAM за съхранение на цялата база данни е огромна печалба, ако можете да я управлявате.
Ако нямате достатъчно RAM, колкото по-бързо съхранение можете да получите, толкова по-добре. Дори евтиният SSD има огромна разлика спрямо въртящата се ръжда. Не се доверявайте на евтините SSD дискове за производство, те често не са безопасни при сривове и може да изядат данните ви.
Учене
Книгата на Грег Смит, PostgreSQL 9.0 High Performance остава актуална, въпреки че се позовава на малко по-стара версия. Трябва да е полезна справка.
Присъединете се към общия пощенски списък на PostgreSQL и го следвайте.
Четене:
- Настройка на вашия PostgreSQL сървър – PostgreSQL wiki
- Брой връзки към базата данни – PostgreSQL wiki
