Отладка высокого PostgreSQL использования памяти (на соединение) - PullRequest
Новая
       118

Отладка высокого PostgreSQL использования памяти (на соединение)

1 голос
/ 03 августа 2020

Есть ли способ проверить, как на самом деле используется память, назначенная каждому соединению?

После обновления с PostgreSQL 9.3 до PG 12 использование памяти для каждого соединения PostgreSQL удвоилось или даже утроилось. Поэтому мне пришлось go с машины 32 ГБ с: shared_buffers = 8 ГБ памяти, используемой для подключений = 8 ГБ памяти для дисковых буферов = 16 ГБ К: машина 64 ГБ с: shared_buffers = 8 ГБ памяти, используемой для подключений = 40 ГБ памяти для дисковых буферов = 16 ГБ

И все равно мало. Нередко для одного подключения используется 170 МБ частной оперативной памяти (Private в smaps, как описано в https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/), не совместно используемой с другими процессами.

What может быть причиной такого большого использования памяти? Насколько я могу судить, это постоянно - память не освобождается, пока соединение не будет закрыто. Поскольку я использую пулы соединений, управляемые Wildfly, они используются повторно, и их редко можно закрыть и воссоздать.

Вот мое определение источника данных: 

<datasource jta="true" jndi-name="java:/MainDS" pool-name="MainDCPool">
    <connection-url>jdbc:postgresql://dbhost/</connection-url>
    <driver-class>org.postgresql.Driver</driver-class>
    <driver>postgres</driver>
    <pool>
        <min-pool-size>1</min-pool-size>
        <max-pool-size>30</max-pool-size>
    </pool>
    <security>
        <user-name>dbuser</user-name>
        <password>password</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <validate-on-match>true</validate-on-match>
        <background-validation>false</background-validation>
    </validation>
    <statement>
        <share-prepared-statements>false</share-prepared-statements>
    </statement>
    <timeout>
        <idle-timeout-minutes>1</idle-timeout-minutes>
    </timeout>
</datasource>

Насколько я понимаю, скажите установка 'idle-timeout-minutes = 1' и min-pool-size=1 не оказала большого влияния, если вообще повлияла. Похоже, WildFly выбирает случайное соединение из пула (по запросу приложения), поэтому маловероятно, что какое-либо из них будет бездействовать в течение длительного периода времени, а размер пула никогда не упадет ниже ~ 20 подключений

...