Приветствую всех! Буду благодарен, если подскажете куда смотреть. Есть система

(типа 1с)
В какой то момент, она посылает запросы (одинаковые), которые подолгу висят с lwlocks. В основном с buffer io, но бывает и с BufferMapping. Если я выполняю те же запросы вручную параллельно с висящими, то они выполняются за несколько мс. Что это может быть? В базе ли вообще проблема? Запросы из системы копятся и не проходят, если вручную не дропнуть. Postgresql 13.2
checkpoint_completion_target = '0.9'
max_connections = '200'
max_locks_per_transaction = '256'
log_checkpoints = 'on'
synchronous_commit = 'off'
enable_partitionwise_aggregate = 'on'
enable_partitionwise_join = 'on'
row_security = 'off'
wal_level = 'minimal'
max_wal_senders = '0'
jit = 'off'
track_activity_query_size = '8192'
wal_compression = 'on'
default_statistics_target = '200'
wal_buffers = '16MB'
autovacuum_max_workers = '3'
checkpoint_warning = '20min'
bgwriter_lru_multiplier = '2.0'
temp_buffers = '32MB'
autovacuum_naptime = '20s'
bgwriter_lru_maxpages = '400'
huge_pages = 'on'
work_mem = '128MB'
shared_buffers = '4GB'
effective_cache_size = '12GB'
maintenance_work_mem = '2GB'
max_worker_processes = '5'
max_parallel_workers_per_gather = '3'
max_parallel_workers = '5'
max_parallel_maintenance_workers = '3'
bgwriter_delay = '200ms'
effective_io_concurrency = '4'
max_wal_size = '10GB'
min_wal_size = '4GB'
checkpoint_timeout = '80min'
wal_writer_delay = '200ms'
5 cores, 16 gb ram

А подолгу висят -- это сколько в секундах? И что-то странное вы вообще говорите. lwlocks -- это не блокировка базы, это какое-то ожыдание временной вещи. По идее в параллельном таком жэ запросе он никак не можэт обойтись без похожэго количества lwlocks, и не должэн их получать за существенно другое время. Приведите лучшэ полные данные pg_stat_activity и вашы измерения. Плюс, планы запросов выведите в log на всякий случай -- вдруг программисты дооптимизировались до несовпдающих планов.

То есть, надо понимать, что сами по себе частые статусы с lwlocks -- это ничего такого в общем особенного. При большой нагрузке нередко видно. От них разработчики ядра пытаются избавляться так или иначе -- поскольку есть подозрение, что это непроизводительный расход процэссорного ресурса -- но в общем это вопрос к разработчикам ядра. А у вас, видимо, вопрос -- как так получается, что один запрос в консоли выполняется одно время, а в программе -- совсем другое? Так это другой вопрос. И проще всего имхо его решать поставив полное или сэмплированное журналирование запросов с планами и анализом планов.

это может быть несколько часов, если вручную не сбросить В pg_stat_activity они висят как active, только в pgadmin'e случайно увидел, что попадаются lwlocks В планах запроса ничего сверъестественного. Такое чувство, что просто клиент не принимает ответ, но держит соединение(не знаю,возможно ли это)

Возможно, но тогда непонятно -- о каких lwlocks вообще речь. То есть в clientwait или как-то так там lwlocks и быть не должно.

Ладно, спасибо. Буду узнавать у разрабов)

У меня png почему-то сложно открываются. И вообще, передавайте текст -- текстом, а планы -- так через что-нибудь вроде или какой другой планировщик.

https://explain.tensor.ru/archive/explain/916386a883a68d31271f7cbca3212f7f:0:2022-01-25#explain

С другой стороны -- если клиент читает сто тысяч строк в час по чайной ложне -- тогда вполне возможно, что бОльшую часть времени там ClientRead, а изредка-изредка появляются lwlocks (которые вы видите в pgadmin потому, что в него гораздо большэ смотрите).

Так, ну судя по 110ms -- это быстрый запрос из psql. А у реально проблемных запросов -- включайте log_min_duration_sample какой-нибудь и auto_explain.log_timing Конечно, auto_explain -- это риск до некоторой степени. Он притормажывает всё, поскольку считает время в процэссе. Чаще на процэнты какие-то, но иногда бывает, что и в разы. Но тут всё равно вещь полезная, так что кмк стоит попробовать.