Как да сравните производителността на PostgreSQL

Целта на сравнителния анализ на база данни е не само да провери капацитета на базата данни, но и поведението на конкретна база данни спрямо вашето приложение. Различният хардуер осигурява различни резултати въз основа на плана за сравнителен анализ, който сте задали. Много е важно да се изолира сървърът (действителният, който се оценява) от други елементи като сървърите, управляващи натоварването, или сървърите, използвани за събиране и съхраняване на показатели за производителност. Като част от упражнението за сравнителен анализ, трябва да получите характеристиките на приложението като а) Интензивно ли е приложението за четене или запис? или б) какво е разделението за четене/запис (напр. 80:20)? или в) Колко голям е наборът от данни?, представителни ли са данните и структурата за действителната производствена база данни и т.н.

PostgreSQL е най-модерната база данни с отворен код в света. Ако някой клиент на корпоративна RDBMS иска да мигрира своята база данни към отворен код, тогава PostgreSQL ще бъде първата опция за оценка.

Тази публикация обхваща следното:

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

Как да сравним PostgreSQL

Стандартният инструмент за сравнителен анализ на PostgreSQL е pgbench. По подразбиране, pgbench тестовете се базират на TPC-B. Той включва 5 команди SELECT, INSERT и UPDATE на транзакция. Въпреки това, в зависимост от поведението на вашето приложение, можете да напишете свои собствени скриптови файлове. Нека разгледаме резултатите по подразбиране и някои ориентирани към скриптове тестове. Ще използваме най-новата версия на PostgreSQL за тези тестове, която е PostgreSQL 10 към момента на писане. Можете да го инсталирате с помощта на ClusterControl или като използвате инструкциите тук:https://www.openscg.com/bigsql/package-manager/.

Спецификации на машината

Версия:RHEL 6 - 64 бита
Памет:4GB
Процесори:4
Съхранение:50G
Версия на PostgreSQL:10.0
Размер на базата данни:15G

Преди да стартирате бенчмаркинг с инструмента pgbench, ще трябва да го инициализирате по-долу с командата:

-bash-4.1$ ./pgbench -i -p 5432 -d postgres
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables…
100000 of 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.

Както е показано в съобщенията NOTICE, той създава таблици pgbench_history, pgbench_tellers, pgbench_accounts и pgbench_branches, за да стартира транзакциите за сравнителен анализ.

Ето един прост тест с 10 клиента:

-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)

Както виждате, той работи с 10 клиента и 10 транзакции на клиент. Даваше ви 739 транзакции/сек. Даваше ви 739 транзакции/сек. Ако искате да го стартирате за определен период от време, можете да използвате опцията "-T". По принцип 15 минути или 30 минути бягане са достатъчни.

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

Какъв тип натоварване?
Колко едновременни сесии?
Какъв е средният набор от резултати от заявки?
Какви са очакваните tps (транзакция в секунда)?

Ето пример за работни натоварвания само за четене. Можете да използвате опцията "-S", за да използвате само SELECT, които попадат в режим само за четене. Имайте предвид, че -n означава пропускане на вакуумирането на маси.

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$

Латентността тук е средното изминало време за транзакция на всеки оператор, изпълнен от всеки клиент. Дава 52 tps с дадения хардуер. Тъй като този бенчмарк е за среда само за четене, нека се опитаме да настроим параметрите shared_buffers и Effective_cache_size във файла postgresql.conf и да проверим броя на tps. Те са със стойности по подразбиране в горния тест, опитайте да увеличите стойностите и проверете резултатите.

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)

Промяната на параметрите подобри производителността с 30%.

pgbench обикновено изпълнява транзакции на свои собствени таблици. Ако имате работно натоварване от 50% четене и 50% запис (или среда 60:40), можете да създадете скриптов файл с набор от изрази, за да постигнете очакваното работно натоварване.

-bash-4.1$ cat /tmp/bench.sql 
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql 
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
 - weight: 1 (targets 50.0% of total)
 - 12707 transactions (50.0% of total, tps = 42.225555)
 - latency average = 914.240 ms
 - latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
 - weight: 1 (targets 50.0% of total)
 - 12729 transactions (50.0% of total, tps = 42.298662)
 - latency average = 1446.721 ms
 - latency stddev = 765.933 ms

Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книга

Какви са ключовите фактори на производителността в PostgreSQL

Ако разгледаме реална производствена среда, тя е консолидирана с различни компоненти на ниво приложение, хардуер като процесор и памет и основната операционна система. Ние инсталираме PostgreSQL върху операционната система, за да комуникираме с други компоненти на производствената среда. Всяка среда е различна и цялостната производителност ще се влоши, ако не е правилно конфигурирана. В PostgreSQL някои заявки се изпълняват по-бързо, а други бавно, но зависи от зададената конфигурация. Целта на оптимизирането на производителността на базата данни е да се увеличи максимално пропускателната способност на базата данни и да се сведат до минимум връзките, за да се постигне възможно най-голямата пропускателна способност. По-долу са дадени няколко ключови фактора за производителност, които влияят на базата данни:

Работно натоварване
Ресурс
Оптимизация
Спорство

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

Какви са съветите и най-добрите практики

Ето няколко съвета и най-добри практики, които можете да следвате, за да избегнете проблеми с производителността:

Можете да помислите за извършване на дейности по поддръжка като ВАКУУМ и АНАЛИЗ след голяма модификация във вашата база данни. Това помага на планировчика да измисли най-добрия план за изпълнение на заявки.
Потърсете нужда от индексиране на таблици. Това кара заявките да се изпълняват много по-бързо, вместо да се налага да правите пълно сканиране на таблицата.
За да направите обхода на индекс много по-бързо, можете да използвате командите CREATE TABLE AS или CLUSTER за групиране на редове с подобни стойности на ключове.
Когато видите проблем с производителността, използвайте командата EXPLAIN, за да разгледате плана за това как оптимизаторът е решил да изпълни вашата заявка.
Можете да опитате да промените плановете, като повлияете на оптимизатора, като промените операторите на заявка. Например, ако видите последователно сканиране за вашата заявка, можете да деактивирате последователното сканиране, като използвате „SET ENABLE_SEQSCAN TO OFF“. Няма гаранция, че оптимизаторът няма да избере този оператор, ако го деактивирате. Оптимизаторът просто смята, че операторът е много по-скъп. Повече подробности можете да намерите тук:https://www.postgresql.org/docs/current/static/runtime-config-query.html
Можете също да опитате да промените параметрите на разходите като CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST и EFFECTIVE_CACHE_SIZE, за да повлияете на оптимизатора. Повече подробности можете да намерите тук:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
Винаги филтрирайте данните на сървъра, а не в клиентското приложение. Това ще сведе до минимум мрежовия трафик и ще осигури по-добра производителност.
За извършване на общи операции винаги се препоръчва използването на процедури от страна на сървъра (задействания и функции). Тригерите или функциите от страна на сървъра се анализират, планират и оптимизират при първото им използване, а не всеки път.

Какви са често срещаните грешки, които хората допускат

Една от често срещаните грешки, които хората правят, е стартирането на сървъра на базата данни и базата данни с параметри по подразбиране. Конфигурацията по подразбиране на PostgreSQL е тествана в няколко среди, но не всяко приложение би намерило тези стойности за оптимални. Така че трябва да разберете поведението на вашето приложение и въз основа на него да зададете конфигурационните си параметри. Можете да използвате инструмента pgTune, за да получите стойности за вашите параметри въз основа на хардуера, който използвате. Можете да разгледате:http://pgtune.leopard.in.ua/. Имайте предвид обаче, че ще трябва да тествате приложението си с промените, които правите, за да видите дали има влошаване на производителността с промените.

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