Ефективността на базата данни е много важна грижа при поддържането на клъстера на базата данни, особено след като той нараства с течение на времето. Това е особено вярно, ако приложението ви стартира с нисък трафик, който след това нараства до умерено или тежко натоварване за четене и запис.
Нещото, което трябва да запомните е, че няма перфектна конфигурация, на която можете да разчитате дълго време, тъй като определени натоварвания може да се променят с течение на времето.
С ClusterControl създаването или внедряването на нов клъстер на база данни PostgreSQL извършва основен анализ, като проверка на вашите хардуерни ресурси, след което прилага автоматична настройка и задава стойностите за избраните параметри, които могат да се настройват. С развитието на PostgreSQL бяха разработени и много инструменти за поддръжка на различни конфигурации, особено за балансиране на натоварването.
В този блог ще разгледаме важността на HAProxy и как той може да помогне за повишаване на производителността. Това е стар инструмент, но все пак мощен прокси и/или балансьор на натоварване, който поддържа не само сървъри на бази данни, но и специфични за мрежово приложение протоколи. HAProxy може да работи съответно чрез четвърти и седми слой, в зависимост от типа настройка въз основа на конфигурацията.
Настройка на производителността на PostgreSQL
Един от основните фактори за управление на производителността за PostgreSQL започва с настройката на основния параметър от initdb до стойностите на параметрите по време на изпълнение. Това трябва да може да се справи с желаното работно натоварване в съответствие с вашите определени изисквания. Преди да можем да поемем по пътя за функцията HAProxy за PostgreSQL, вашият сървър на база данни трябва да е стабилен и настроен към желаните от него променливи. Нека вземем списък с области за PostgreSQL за това кои са нещата, които могат да повлияят на производителността на вашия сървър на база данни.
Настройка за възможно управление на паметта
PostgreSQL е ефективен и е възможно да работи ефективно само с 256Mb памет. Паметта не е скъпа, но повечето набори от данни са по-малки от 4Gib. Ако имате поне 4Gib, вашият активен набор от данни може да остане във файлов и/или споделен буфер кеш.
Настройката на вашия PostgreSQL за управление на паметта е едно от най-основните и основни неща, които трябва да настроите. Правилното му настройване може да повлияе на повишаването на производителността на вашия сървър на база данни. Въпреки че зависи от това с какви маси играете. Лошите заявки и лошите дефиниции на таблици също могат да доведат до лоша производителност. С правилни индекси, дефинирани към вашите таблици и със заявки, препращащи към индекси, шансовете могат да достигнат от 80% - 100% от заявките могат да бъдат извлечени от вашата памет. Това особено ако индексният буфер има правилната стойност за зареждане на вашия индекс, дефиниран във вашите таблици. Нека разгледаме параметрите, които обикновено се задават за подобряване на производителността.
- споделени_буфери - PostgreSQL оразмерява основното си пространство в паметта с shared_buffers. Работният кеш на всички горещи кортежи (и индексни записи) в PostgreSQL. Този параметър задава количеството памет, което сървърът на базата данни използва за споделени буфери на паметта. Това е предварително разпределен кеш (буфери). За Linux базирани системи е идеално да зададете параметъра на ядрото kernel.shmmax, който може да бъде постоянно зададен чрез /etc/sysctl.conf конфигурационния файл на ядрото.
- temp_buffers - Задава максималния брой временни буфери, използвани за всяка сесия. Това са локални буфери за сесия, използвани само за достъп до временни таблици. Една сесия ще присвои временните буфери според нуждите до лимита, даден от temp_buffers.
- work_mem - Работната памет, налична за работни операции (сортиране), преди PostgreSQL ще се смени. Не задавайте глобално (postgresql.conf). Използвайте за транзакция, тъй като това може да бъде лошо за заявка, за връзка или за сортиране. Използването на EXPLAIN ANALYZE се препоръчва, за да видите дали препълвате или не.
- maintenance_work_mem - Определя количеството памет, което да се използва за операции по поддръжка (ВАКУУМ, СЪЗДАВАНЕ НА ИНДЕКС и ПРОМЕНИ ТАБЛИЦА... ДОБАВЯНЕ НА ВЪНШЕН КЛЮЧ...)
Настройка за възможно управление на дискове
Някои параметри по време на изпълнение, които да зададете тук. Нека изброим кои са тези:
- temp_file_limit - Определя максималното количество дисково пространство, което сесията може да използва за временни файлове, като сортиране и хеширане на временни файлове, или файла за съхранение за задържан курсор. Транзакция, която се опитва да надхвърли този лимит, ще бъде анулирана.
- fsync - Ако fsync е активиран, PostgreSQL ще се опита да се увери, че актуализациите са записани физически на диска. Това гарантира, че клъстерът на базата данни може да бъде възстановен до последователно състояние след срив на операционна система или хардуер. Докато деактивирането на fsync обикновено подобрява производителността, то може да причини загуба на данни в случай на прекъсване на захранването или срив на системата. Ето защо е препоръчително да деактивирате fsync само ако можете лесно да пресъздадете цялата си база данни от външни данни
- synchronous_commit - Използва се за налагане на това commit ще изчака WAL да бъде записан на диска, преди да върне успешно състояние на клиента. Тази променлива има компромис между производителност и надеждност. Ако имате нужда от повече производителност, задайте това на изключено, което означава, че когато сървърът се срине, има тенденция да се натъкнете на загуба на данни. В противен случай, ако надеждността е важна, включете това. Това означава, че ще има времева разлика между състоянието на успех и гарантираното записване на диск, което може да повлияе на производителността.
- checkpoint_timeout, checkpoint_completion_target - PostgreSQL записва промените в WAL, което е скъпа операция. Ако често записва промени в WAL, това може да повлияе лошо на производителността. И така, как работи, процесът на контролна точка изхвърля данните във файловете с данни. Тази дейност се извършва, когато се появи CHECKPOINT и може да причини огромно количество IO. Целият този процес включва скъпи операции за четене/запис на диск. Въпреки че вие (администраторски потребител) винаги можете да издадете CHECKPOINT, когато ви се струва необходимо, или да го автоматизирате, като зададете желаните стойности за тези параметри. Параметърът checkpoint_timeout се използва за задаване на време между контролните точки на WAL. Задаването на това твърде ниско намалява времето за възстановяване при срив, тъй като повече данни се записват на диска, но това също вреди на производителността, тъй като всяка контролна точка в крайна сметка консумира ценни системни ресурси. Checkpoint_completion_target е частта от времето между контролните точки за завършване на контролната точка. Високата честота на контролните точки може да повлияе на производителността. За гладка контролна точка, checkpoint_timeout трябва да е ниска стойност. В противен случай операционната система ще натрупа всички мръсни страници, докато съотношението бъде изпълнено, и след това ще премине към голям флъш.
Настройка на други параметри за производителност
Има определени параметри, които осигуряват повишаване и стимулиране на производителността в PostgreSQL. Нека изброим кои са тези по-долу:
- wal_buffers - PostgreSQL записва своя WAL (write ahead log) запис в буферите и след това тези буфери се изхвърлят на диска. Размерът на буфера по подразбиране, дефиниран от wal_buffers, е 16 MB, но ако имате много едновременни връзки, тогава по-висока стойност може да осигури по-добра производителност.
- effective_cache_size - Effective_cache_size предоставя оценка на наличната памет за дисково кеширане. Това е само насока, а не точният размер на разпределената памет или кеша. Той не разпределя действителната памет, но казва на оптимизатора количеството наличен кеш в ядрото. Ако стойността на това е зададена твърде ниска, плановникът на заявки може да реши да не използва някои индекси, дори ако те биха били полезни. Следователно задаване на голяма стойност винаги е от полза.
- default_statistics_target - PostgreSQL събира статистически данни от всяка една от таблиците в своята база данни, за да реши как ще се изпълняват заявките към тях. По подразбиране той не събира твърде много информация и ако не получавате добри планове за изпълнение, трябва да увеличите тази стойност и след това да стартирате ANALYZE в базата данни отново (или да изчакате АВТОВАКУУМ).
Ефективност на заявките на PostgreSQL
PostgreSQL има много мощна функция за оптимизиране на заявките. С вградения Genetic Query Optimizer (известен като GEQO). Той използва генетичен алгоритъм, който е евристичен метод за оптимизация чрез рандомизирано търсене. Това се прилага при извършване на оптимизация с помощта на JOIN, което осигурява много добра оптимизация на производителността. Всеки кандидат в плана за присъединяване е представен от последователност, в която да се присъединят основните отношения. Той изпълнява произволно генетична връзка, като просто генерира някаква възможна последователност на присъединяване, но на случаен принцип.
За всяка разглеждана последователност на присъединяване се извиква стандартният код за планиране, за да се оцени разходите за изпълнение на заявката с помощта на тази последователност на присъединяване. Така че за всяка от JOIN последователностите всички имат своите първоначално определени планове за сканиране на релации. След това планът на заявката ще изчисли най-осъществимия и ефективен план, т.е. с по-ниска прогнозна цена и се счита за „по-подходящ“ от тези с по-висока цена.
Като се има предвид, че има мощна функция, интегрирана в PostgreSQL, и правилно конфигурирани параметри в съответствие с желаните от вас изисквания, той не нарушава осъществимостта, когато става въпрос за производителност, ако натоварването е прехвърлено само на първичен възел. Балансирането на натоварването с HAProxy помага за още по-висока производителност на PostgreSQL.
Ускоряване на производителността за PostgreSQL с разделяне на четене-запис
Може да имате страхотна производителност при работа с вашия PostgreSQL сървърен възел, но може да не сте в състояние да предвидите какъв тип работно натоварване може да имате, особено когато има голям трафик и търсенето излиза извън границите. Балансирането на натоварването между първичен и вторичен осигурява повишаване на производителността във вашето приложение и/или клиенти, свързващи се с вашия PostgreSQL клъстер от база данни. Как може да се направи това, вече не е въпрос, тъй като това е много често срещана настройка за висока наличност и излишък, когато става въпрос за разпределяне на натоварването и избягване на блокиране на основния възел поради обработка на голямо натоварване.
Настройването с HAProxy е лесно. И все пак, това е по-ефективно, по-бързо и осъществимо с ClusterControl. Така че ще използваме ClusterControl, за да настроим това вместо нас.
Настройване на PostgreSQL с HAProxy
За да направим това, просто ще трябва да инсталираме и настроим HAProxy върху клъстерите на PostgreSQL. HAProxy има функция за поддръжка на PostgreSQL чрез опция pgsql-check, но поддръжката му е много проста реализация, за да се определи дали даден възел е изправен или не. Той няма проверки за идентифициране на първичен и възел за възстановяване. Една опция е да използваме xinetd, за който ще разчитаме на комуникацията на HAProxy за слушане чрез нашата услуга xinetd, която проверява здравето на конкретен възел в нашия PostgreSQL клъстер.
Под ClusterControl отидете на Управление → Балансиране на натоварване, както по-долу,
След това просто следвайте въз основа на потребителския интерфейс според екранната снимка по-долу. Можете да щракнете върху Покажи разширени настройки, за да видите по-разширени опции. Следването на потребителския интерфейс обаче е много лесно. Вижте по-долу,
Импортирам само HAProxy с един възел без излишък, но с цел този блог, нека го направим по-опростен.
Моят примерен изглед на HAProxy е показан по-долу,
Както е показано по-горе, 192.168.30.20 и 192.168.30 са основните. и съответно вторични/възстановителни възли. Докато HAProxy е инсталиран във вторичния/възстановителен възел. В идеалния случай можете да инсталирате своя HAProxy на множество възли, за да имате повече излишък и високодостъпен, най-добре е да го изолирате спрямо възлите на базата данни. Ако сте ограничени в бюджета или спестявате използването си, може да изберете да инсталирате своите HAProxy възли, където също са инсталирани възлите на вашата база данни.
ClusterControl настройва това автоматично и също така включва услугата xinetd за проверка на PostgreSQL. Това може да се провери с netstat точно както по-долу,
[email protected]:~# netstat -tlv4np|grep haproxy
tcp 0 0 0.0.0.0:5433 0.0.0.0:* LISTEN 28441/haproxy
tcp 0 0 0.0.0.0:5434 0.0.0.0:* LISTEN 28441/haproxy
tcp 0 0 0.0.0.0:9600 0.0.0.0:* LISTEN 28441/haproxyКато има предвид, че порт 5433 е за четене и запис, а 5444 е само за четене.
За PostgreSQL проверете за услугата xinetd, а именно postgreshk, както се вижда по-долу,
[email protected]:~# cat /etc/xinetd.d/postgreschk
# default: on
# description: postgreschk
service postgreschk
{
flags = REUSE
socket_type = stream
port = 9201
wait = no
user = root
server = /usr/local/sbin/postgreschk
log_on_failure += USERID
disable = no
#only_from = 0.0.0.0/0
only_from = 0.0.0.0/0
per_source = UNLIMITED
}
Услугите xinetd също разчитат на /etc/services, така че може да успеете да намерите порта, който е определен за картографиране.
[email protected]:~# grep postgreschk /etc/services
postgreschk 9201/tcpАко трябва да промените порта на вашия postgreschk към какъв порт да картографирате, трябва да промените и този файл, освен конфигурационния файл на услугата и след това не забравяйте да рестартирате демона xinetd.
Услугата postgreschk съдържа препратка към външен файл, който по същество проверява за възли дали е за запис, което означава, че е основен или главен. Ако възелът е в процес на възстановяване, това е реплика или възел за възстановяване.
[email protected]:~# cat /usr/local/sbin/postgreschk
#!/bin/bash
#
# This script checks if a PostgreSQL server is healthy running on localhost. It will
# return:
# "HTTP/1.x 200 OK\r" (if postgres is running smoothly)
# - OR -
# "HTTP/1.x 500 Internal Server Error\r" (else)
#
# The purpose of this script is make haproxy capable of monitoring PostgreSQL properly
#
export PGHOST='localhost'
export PGUSER='s9smysqlchk'
export PGPASSWORD='password'
export PGPORT='7653'
export PGDATABASE='postgres'
export PGCONNECT_TIMEOUT=10
FORCE_FAIL="/dev/shm/proxyoff"
SLAVE_CHECK="SELECT pg_is_in_recovery()"
WRITABLE_CHECK="SHOW transaction_read_only"
return_ok()
{
echo -e "HTTP/1.1 200 OK\r\n"
echo -e "Content-Type: text/html\r\n"
if [ "$1x" == "masterx" ]; then
echo -e "Content-Length: 56\r\n"
echo -e "\r\n"
echo -e "<html><body>PostgreSQL master is running.</body></html>\r\n"
elif [ "$1x" == "slavex" ]; then
echo -e "Content-Length: 55\r\n"
echo -e "\r\n"
echo -e "<html><body>PostgreSQL slave is running.</body></html>\r\n"
else
echo -e "Content-Length: 49\r\n"
echo -e "\r\n"
echo -e "<html><body>PostgreSQL is running.</body></html>\r\n"
fi
echo -e "\r\n"
unset PGUSER
unset PGPASSWORD
exit 0
}
return_fail()
{
echo -e "HTTP/1.1 503 Service Unavailable\r\n"
echo -e "Content-Type: text/html\r\n"
echo -e "Content-Length: 48\r\n"
echo -e "\r\n"
echo -e "<html><body>PostgreSQL is *down*.</body></html>\r\n"
echo -e "\r\n"
unset PGUSER
unset PGPASSWORD
exit 1
}
if [ -f "$FORCE_FAIL" ]; then
return_fail;
fi
# check if in recovery mode (that means it is a 'slave')
SLAVE=$(psql -qt -c "$SLAVE_CHECK" 2>/dev/null)
if [ $? -ne 0 ]; then
return_fail;
elif echo $SLAVE | egrep -i "(t|true|on|1)" 2>/dev/null >/dev/null; then
return_ok "slave"
fi
# check if writable (then we consider it as a 'master')
READONLY=$(psql -qt -c "$WRITABLE_CHECK" 2>/dev/null)
if [ $? -ne 0 ]; then
return_fail;
elif echo $READONLY | egrep -i "(f|false|off|0)" 2>/dev/null >/dev/null; then
return_ok "master"
fi
return_ok "none";Комбинацията потребител/парола трябва да е валидна РОЛЯ във вашия PostgreSQL сървър. Тъй като инсталираме чрез ClusterControl, това се обработва автоматично.
Сега, когато имаме пълна инсталация на HAProxy, тази настройка ни позволява да имаме разделяне за четене-запис, където четене-записване отива към основния или записващ възел, докато само за четене както за първичен, така и за вторичен/ възли за възстановяване. Тази настройка не означава, че вече е производителна, тя все още е настроена, както беше обсъдено по-рано, като комбинацията от HAProxy за балансиране на натоварването добавя повече повишаване на производителността за вашето приложение и съответните клиенти на базата данни.
