Page tree
Skip to end of metadata
Go to start of metadata

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


  • No labels