he problem that arose when limiting connections to database and reach (+400 connections). Even after increasing as available connections (+600) the problem persisted.
So we installed pgbouncer to manage the pool of connections between web servers and postgres, thus reducing the number of connections.
It worked well for a few days, but the problem came back.
Finally, it seems that the problem is related to a deadlock in a query, due to this deadlock, a connection with the braking bank (waiting for a response) and new connections are generated to answer as requests but end up falling in the deadlock and so on. against ....
Thus, we reach the limit of allowed connections which makes the use of the web servers unfeasible and are still involved in the data by the proxies / zabbix server.

According to DBA, the data record without database is this:
LOG: process 48771 still waiting for ShareLock on transaction 2739469433 after 10001.021 ms
Detail: Process holding the lock: 48867. Wait queue: 48771, 51745.
Context: while locking tuple (153,24) in relation "profiles"
Statement: UPDATE profiles SET value_id='161374', type=1 WHERE userid=12 AND idx='web.screens.graphid'

Detail: Process holding the lock: 48771. Wait queue: 50158, 49676, 48867, 49390, 48982, 51466, 50486, 51745, 50555, 50090, 49811, 52341, 49536, 49742, 50621, 48707.
Statement: UPDATE profiles SET value_id='106345', type=1 WHERE userid=12 AND idx='web.screens.graphid'

Thousands of messages from this in the database log ....
The userid=12 é o aixldap.