Na każdym systemie są dobrzy admini i źli użytkownicy. Użytkownicy (bo przecież nie admini) mogą uruchomić polecenie, które zablokuje innych użytkowników lub skonsumuje zbyt wiele zasobów. Co w takim przypadku robić?

1. Zidentyfikuj użytkownika – rozbójnika

Czasami identyfikacja nie jest łatwa, ale jeśli np. źródłem informacji o awarii jest przeciążony procesor, to taką identyfikację można rozpocząć na poziomie OS. Wyszukaj po prostu procesu, który konsumuje dużo CPU. Mająć PID procesu, można odszukać połączenie po stronie PG:

select * from pg_stat_activity where pid=XXX;

Tak dowiesz się między innymi, kiedy rozpoczęło się połączenie, transakcja, ostatnie zapytanie. Zobaczysz stan transakcji (np „idle transaction”, czyli w trakcie transakcji użytkownik poszedł na kawę), aplikację, serwer, nazwę użyszkodnika itp.

2. Spróbuj zakończyć aktualnie wykonywane zadanie

Jeśli przyczyną problemów jest intensywnie pracujące zapytanie, to można spróbować brutalnie je przerwać. Nie spowoduje to rozłączenia użytkownika:

select pg_cancel_backend(XXX);

3. Zamknij połączenie/sesję

Jeśli problem nadal występuje (np. użytkownik już nic nie robi, ale wcześniej założone blokady nadal uniemożliwiają pracę innym użytkownikom), to przerwij sesję zwalniając wszystkie zarezerwowane dla niej zasoby:

select pg_terminate_backend(XXX);

Jeśli tylko użyszkodnik został poprawnie zidentyfikowany w kroku (1), to ostatnie polecenie pomoże. Jeśli nie pomogło, to… no cóż… zabiliśmy kogoś innego przez pomyłkę… sorry

Zakładając, że PEM został zainstalowany już podczas wstępnej instalacji EDB, to w celu uruchomienia tego narzędzia wystarczy uruchomić skrypt konfiguracyjny:

/usr/edb/pem/bin/configure-pem-server.sh

Skrypt grzecznie pyta o wszelkie opcje konfiguracyjne. Na moim testowym serwerze wyglądało to tak: Czytaj dalej »

Aby skonfigurować Profilera w pierwszej kolejności należy zmodyfikować opcję shared_preload_libraries w postgresql.conf. Modyfikacja polega na dodaniu $libdir/sql-profiler,$libdir/index_advisor

Niestety ta modyfikacja wymaga wykonania restartu serwera

pg_ctl restart

Po restarcie można skontrolować ustawienie z posiomu psql:

edb=# select name, setting from pg_settings where name = 'shared_preload_libraries';
 name | setting
--------------------------+----------------------------------------------------------------------------------------------
 shared_preload_libraries | $libdir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,$libdir/sql-profiler,$libdir/index_advisor
(1 rows)

Kolejny krok, to  uruchomienie skryptów, które konfigurują profilera (i przy okazji index advisora)

edb-psql -f /usr/edb/as13/share/contrib/sql-profiler.sql edb
 edb-psql -f /usr/edb/as13/share/contrib/index_advisor.sql

Teraz można już przejść do PEM. W wersji 13 Profiler znajduje się w Tools >> Server >> SQL Profiler. Po utworzeniu sesji profilera od razy i prawie na żywo można ją obserwować. Prawie na żywo, bo żeby zobaczyć nowe przechwycone polecenia należy kliknąć „Refresh”. Narzędzie pozwala analizować zapytania użytkowników, czas trwania i obciążenie generowane przez te zapytania, a nawet podejrzeć wykorzystane plany zapytań:

Do instalacji PostgreSQL EDB na konkretnej wersji konkretnego systemu operacyjnego trzeba używać odpowiednich paczek instalacyjnych i uruchamiać je w odpowiedniej kolejności z dobrze dobranymi parametrami. To bywa kłopotliwe.

Na szczęście EDB udostępnia stronę, na której wystarczy wybrać żądane parametry instalacji, a sam skrypt instalacyjny zostanie wygenerowany automatycznie. Np. tak wygląda instalacja na Red Hat 8:

# Install the repository configuration
dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm

# Replace 'USERNAME:PASSWORD' below with your username and password for the EDB repositories
# Visit https://www.enterprisedb.com/user to get your username and password
sed -i "s@<username>:<password>@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo

# Install EPEL repository
dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

# Enable the codeready-builder-for-rhel-8-*-rpms repository since EPEL packages may depend on packages from it
ARCH=$( /bin/arch )
subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms"

# Disable the built-in PostgreSQL module:
dnf -qy module disable postgresql

# Install selected packages
dnf -y install edb-as13-server edb-pem

# Initialize Database cluster
PGSETUP_INITDB_OPTIONS="-E UTF-8" /usr/edb/as13/bin/edb-as-13-setup initdb

# Start Database server
systemctl start edb-as-13

# Connect to the database server
# sudo su - enterprisedb
# psql postgres

# Configure PEM
/usr/edb/pem/bin/configure-pem-server.sh

# You can now connect to PEM at https://127.0.0.1:8443/pem

Oto link do strony https://repos.enterprisedb.com/

Podczas instalacji EDB jest potrzebna nazwa użytkownika i haslo, jakie otrzymuje się po rejestracji w EDB. Te dane można odczytać z tej strony:

https://www.enterprisedb.com/user/

Do wylistowania baz danych w clustrze PostgreSQL można użyć skrótowego polecenia

\l

Niestety,  od pewnego momentu uruchomienie tego polecenia kończy się błędem:

postgres=# \l
ERROR: column d.daticu does not exist
LINE 6: d.daticu as "ICU",
 ^
HINT: Perhaps you meant to reference the column "d.datacl".

Co się stało?

Na serwerze wcześniej był zainstalowany PostgreSQL 13 w wersji Community (czysty postgres).

Później na tym samym serwerze został zainstalowany Enterprise DB Advanced Server (czyli postgres „na sterydach” publikowany przez EDB). Podczas tej instalacji do katalogu /usr/bin został wkopiowany plik psql właśnie od EDB.

EDB budując własną dystrybucję PostgreSQL dodało pewne kolumny do tabel systemowych, w szczególności do tabeli pg_database.

Kiedy uruchamiasz psql, to w pierwszej kolejności jest przeszukiwana ścieżka /usr/bin, więc uruchamiany jest program od EDB. W tym programie skrót „\l” jest skojarzony z zapytaniem, które ma wydobyć z tabeli pg_database kolumnę daticu, a standardowy PostgreSQL jej po prostu nie ma.

Co z tym zrobić? Przede wszystkim należałoby pogrozić palcem EDB, bo to bardzo zły zwyczaj, żeby psuć inne instalacje swoją instalacją. Podstawowa dystrybucja Postgresa postąpiła o wiele mądrzej. Skoro już jednak się stało, jak się stało, to można albo:

• uruchamiać psql podając pełną ścieżkę do tej komendy

/usr/pgsql-13/bin/psql

• zmodyfikować zmienną PATH, tak aby ścieżka wskazująca na /usr/pgsql-13/bin znalazła się przed /usr/bin. Generalnie nie jest to zalecane, bo… w ten sposób można „przykryć” inne polecenia systemowe, ale… polecenia postgresa są specyficzne (nie przykryją innych komend systemu), a ponadto zmiana jest wykonywana tylko dla jednego użytkownika, no więc… można zaryzykować. Najłatwiej zrobić to w .bash_profile, lub jeśli korzystasz z pgsql_profile, to tam:

PATH=/usr/pgsql-13/bin:$PATH

Aby uruchamiając komendy korzystające albo administrujące postgresem, bez wpisywania długich komend z licznymi argumentami, można w środowisku zdefiniować kilka zmiennych środowiskowych. Ich wartości będą wykorzystywane podczas uruchamiania komend:

PGDATA – ścieżka wskazująca na lokalizację katalogu data, np.: /var/lib/pgsql/13/data

PGPORT – port, na którym nasłuchuje serwer, np. 5432

PGUSER – nazwa użytkownika, którą należy wykorzystywać, np.: postgres

PGDATABASE – domyślna baza danych, np. postgres

Nie zapominajmy też o zmiennej systemowej PATH, która powinna zawierać odnośnik do katalogu bin np. /usr/pgsql-13/bin

Odpowiednie polecenia można umieścić w pliku profilu użytkownika .bash_profile

PATH=$PATH:/usr/pgsql-13/bin
PGDATA=/var/lib/pgsql/13/data
export PGDATA
export PATH
export PGPORT=5432

Istnieje jednak ryzyko, że podczas konfiguracji, aktualizacji, reinstalacji PostgreSQL, ten plik może zostać zamazany. Na szczęście w pliku powinna znaleźć się również taka linijka:

# If you want to customize your settings,
# Use the file below. This is not overridden
# by the RPMS.
[ -f /var/lib/pgsql/.pgsql_profile ] && source /var/lib/pgsql/.pgsql_profile

Dlatego zdecydowanie lepiej będzie umieścić własne definicje zmiennych środowiskowych w pliku .pgsql_profile

Komenda lsof pozwala na wyświetlenie otwartych na systemie plików. Taka informacja przydaje się czasami. Np. kiedy chcesz odmontować system plików, ale jakiś proces otworzył plik w tym systemie plików i blokuje twoją operację.

Ponieważ w Linuxie wszystko jest plikiem, to można sprawdzić, czy jakiś proces otworzył zasoby związane z siecią. Dlatego żeby sprawdzić na jakich portach nasłuchują lokalne procedy można posłużyć się komendą:

lsof -i -P -n | grep LISTEN

Za co odpowiadają opcje?

-i listuje tylko pliki związane z zasobami sieciowymi

-P powstrzymuje komendę przed zamianą numeru portu na jego dobrze znaną nazwę, jak np http, ssh itp.

-n powstrzymuje komendę przez zamianą adresu IP na skojarzoną z nim nazwę

Oto przykładowy wynik:

[root@dbserv10 ~]# lsof -i -P -n | grep LISTEN
systemd-r 704 systemd-resolve 12u IPv4 15140 0t0 TCP *:5355 (LISTEN)
systemd-r 704 systemd-resolve 14u IPv6 15143 0t0 TCP *:5355 (LISTEN)
postmaste 1051 postgres 6u IPv4 25950 0t0 TCP *:5432 (LISTEN)
postmaste 1051 postgres 7u IPv6 25951 0t0 TCP *:5432 (LISTEN)
sshd 6436 root 4u IPv4 44026 0t0 TCP *:22 (LISTEN)
sshd 6436 root 6u IPv6 44028 0t0 TCP *:22 (LISTEN)
edb-postm 14602 enterprisedb 6u IPv4 153377 0t0 TCP *:5444 (LISTEN)
edb-postm 14602 enterprisedb 7u IPv6 153378 0t0 TCP *:5444 (LISTEN)