Zbyt duży rozmiar bazy danych PostgreSQL

Duża liczba operacji DELETE czy UPDATE wykonywanych na tabeli może prowadzić do wystąpienia tzw. "index bloat". Problem występuje w indeksach opartych na B-drzewach i polega na tym, że w indeksie występuje wiele pustych lub prawie pustych stron. Takie "nadmuchanie" indeksu skutkuje zwiększonym rozmiarem bazy danych i prowadzi do obniżenia jej wydajności nawet do nieakceptowalnego poziomu. Rozwiązaniem jest przebudowanie indeksu zgodnie z informacjami podanymi w dokumentacji PostgreSQL.

Przy sprawdzaniu rozmiaru tabel przed i po przebudowaniu indeksów pomocne mogą być poniższe zapytania SQL.

• Podaje rozmiary tabel w bajtach:

SELECT relpages * 8192 AS size_in_bytes, relname FROM pg_class 
WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = 'public') 
ORDER BY size_in_bytes DESC LIMIT 10;

• Podaje sumę rozmiarów 10 największych tabel:

SELECT SUM(sizes.size_in_bytes) AS total_size_for_top_10_tables FROM (SELECT relpages * 8192 AS size_in_bytes, relname FROM pg_class 
WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = 'public') ORDER BY size_in_bytes DESC LIMIT 10) AS sizes;

• Podaje sumę rozmiarów wszystkich tabel:

SELECT SUM(sizes.size_in_bytes) AS total_size_for_all_tables FROM (SELECT relpages * 8192 AS size_in_bytes, relname FROM pg_class 
WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = 'public')) AS sizes;

Zawieszanie połączeń z bazą Oracle, komunikaty "APPARENT DEADLOCK!!"

Może pomóc dodanie do konfiguracji c3p0 parametru  statementCacheNumDeferredCloseThreads=1. Można to zrobić w pliku dlibra-server/conf/wrapper/troubleshooting.conf, dodając wpis:

wrapper.java.additional.XX=-Dc3p0.statementCacheNumDeferredCloseThreads=1

wstawiając za XX następną liczbę niezajętą przez inne wpisy.

Więcej informacji o błędzie: https://github.com/swaldman/c3p0/issues/53