Нагрузочное теситрование и профилирование не помешали бы. При постоянном соединении в 800 на сервер, может быть что угодно.

mreМогут ли возникать подобные проблемы при слишком частом чтении/отправке данных (какие нибудь очереди соединений и т.п.) или же проблему следует искать в алгоритмах работы, утечках памяти или еще чем то, связанным с логикой конкретного сервера?
Настройте GC Log - посмотрите заполнение памяти и распределение по поколениям.
Настройте какой-нибудь монитор CPU и дискового IO, чтобы посмотреть нагрузку.

mreПо ходу проблема в том, что при выполнении sql-запросов, поток ожидает окончания выполнения и возникают тормоза.

Да, это действительно проблема. А зачем в игре SQL? Не проще ли запросы оптимизировать, да базёнку подтюнинговать?

mreА есть ли библиотеки sql pool для выполнения асинхронных (параллельных) запросов, то есть, чтобы можно было подписываться на событие завершения выполнения запроса?
Асинхронность требует изменения работы логики. У нас был один проект. Клиенты просто накидывают изменения в сервер. А сервер всех уже нотифицирует, после комита в базу. В результате никто не ждет комитов.

mreДа запросов не много и не тяжелые, просто потоков не достаточно, их сейчас штук 5 на каждый модуль, видимо, нужно больше.
Если у вас потоки ждут запросов, то не связано ли это с лимитом соединений? Почему именно про потоки вы заговорили? И что такое эти самые условные модули?

mreМодули, ну, например, магазин, все операции пользователя с магазинов выполняются в отдельном потоке, чат - в другом и т.д.
У вас 800 клиентов онлайн обслуживаются 5ю потоками??? Свой LMAX что ли написали?

Может с терминологией что не так? Поток в вашем понимании это Thread? Поток выполнения процессором кода?
Или вы про какие-то свои IO потоки?

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