The major issue in pgAdmin, which so far has only been seen when running in server mode, is when a user expands the tree view in the left, it attempts to connect to every database on the server to determin if you have access.
If this only occured once it would not be a problem, however someimtes it keeps looping over the check for several minutes.
With over 320 databases on the server this creates a large number of outbound TCP connections.
While the database server quickly replies with access denied and ignores the connection, the pdAdmin server hangs on to the connection.
With a large number of concurrent users the chances of having multiple people stuck in the loop increase, and given there is only 65,536 ports available, if this happens the pgAdmin server quickly runs out of available ports.
At this point all new non-established connections have to wait.
So while everything looks normal and lightly loaded on the server, in terms of CPU and RAM, response times start to increase until they timeout and the reverse proxy returns a 501 error to your browser.
Another issues that appears in the logs are CSRF token exception.
Details on what CSRF attacks are and how they are mitigated can be found at the OWASP Foundation page on CSRF.
In short, it's a way of preventing another web page from tricking another, that you've signed into, performing some action (e.g. posting a message).
For some reason, and this might be due to having mutliple tabs open to pgAdmin at the same time, the browser starts a new session, creating a new CSRF token, but still uses the old one.
Instead of getting the error, reporting it to the user, and stopping further requests, it keeps trying.
While this doesn't seem to have any other negative effects, it causes frequent exceptions on the server, which end up in the logs.
Each query tool in pgAdmin polls the server every minute to check if there's been any updates to it's status.
It doesn't seem to pay attention to any error codes it gets, so instead of backing off on a 404 (page not found) it continues checking.
This means that if you forget to log out and leave a tab open in your browser it never stops.
While a singler user doing this is no problem, with multiple tabs and people this creates a lot of noise in the logs, making finding other problems harder.
The database server has been moved to a separate host to reduce the risk of any I/O issues, even though now it seems unlikely that this was the issue.
To validate the server pgbench has been used to simulate a workload against it.
This created a large table, ran 128 connections across 32 threads against the database for 5 minutes.
Over this time the server managed an average of 1450 transactions per second, with an average response time of around 90ms.