res2001

Начать можно с пинга сервера, далее протестируйте подключение через телнет:
telnet IP PORT
Если подключиться экран очистится и возможно соединение сразу разорвется (но не обязательно, зависит от сервера).
Если телнет подключиться, значит проблема в клиентском софте. Если не подключиться - нужно проверять всю цепочку от сервера до клиента, блокировка может быть где угодно, в т.ч. у провайдера.

Если поток присоединенный, то в main можно его подождать с помощью thread join, если не присоединенный - выставляйте в потоке перед самым завершением какой-нибудь флаг означающий завершение потока. В main проверяете флаг.
Но "технологичнее" сделать так, что когда поток выполнил одно задание, он снова полез в очередь и взял оттуда другое задание. Если заданий нет, то пусть ждет. В этом вам помогут примитивы синхронизации типа мьютексов и т.п.

Перейдите от консольного приложения к оконному, например - простейшее окно на Qt и выводите график уже в графическое окно средствами Qt. График можно нарисовать вручную, либо воспользоваться какими-либо готовыми Qt виджетами, они есть.

1.В чем смысл балансировки на одном хосте? Балансировка нужно, если хост не справляется и нужно направить часть подключений на другой хост. Поэтому балансировать на одном хосте - полная фигня.
2.Самый простой вариант балансировки - с помощью двух записей А в ДНС для одного имени сервера OpenVPN. DNS в этом случае будет отдавать записи по round robin и у вас получится бесплатная балансировка.
Нужно будет на разных серверах OpenVPN назначать клиентам адреса разных подсетей, иначе, как вы сами правильно заметили начнутся грабли с маршрутизацией.
OSPF в такой конфигурации вообще не нужен.

Вставлять большой массив данных в SQL лучше с помощью bulk insert, но, на сколько я помню, эта операция не понимает json (нужно уточнить). Можно из json конвертнуть в csv (или во что-либо другое, с чем bulk insert работает), а потом уже вставлять в sql. JSON преобразовать в csv можно достаточно простым скриптом на javascript.
Чтоб быстро работал поиск, нужно сделать соответствующие индексы.
Предложенный альтернативный вариант можно считать рабочим, только если нет сильно удаленных клиентов с не слишком быстрыми каналами связи (и вообще их не очень много), кроме того, чтоб не таскать на каждый запрос этот огромный BLOB можно вытянуть его один раз при старте клиента, а потом уже искать только локально.
Но, как по мне, вариант с загрузкой в SQL вполне рабочий.

Только подозрение?
Нужно убедится точнее.
Если на линуксе, то посмотрите в top что грузит проц, если винда - менеджер задач.
Естественно есть инструменты для профилирования БД, только нужно знать какой сервер БД вы используете - для каждого свой инструмент.

Кроме стандартных настроек:
1.правило должно быть на входящий трафик (на сколько я понял из вопроса вы блокируете входящие запросы);
2.правило должно быть включено;
3.в правиле должен быть выбран правильный профиль фаервола (тот который используется виндой);
4.фаервол должен быть включен (по моему в виндовом сервере он по умолчанию выключен)

Нужно знать что там закодировано.
Обычно это указатель на какую-либо структуру.

И почему не так:
PNT_ENUMWINDOWS TrueEnumWindows = ::EnumWindows;
?
Вы не используете /DEFAULTLIB для сборки?

Гуглите про нормализацию базы данных.
1.Вам нужно вынести name в отдельную таблицу, например назовем ее emploee, в которой будет просто список имен, возможно с какой-либо другой информацией и id, уникальный для каждого имени.
2.Тогда в SAL поля name не будет, а будет id_emploee
3.Меняете имя в таблице employee, автоматически оно поменяется везде, т.к. везде у вас будет фигурировать только id_emploee, а не само имя.

Соответственно, там где нужно имя, нужно в запросах делать join с таблицей employee. Но в запросе из примера, можно и не делать join, а группировать по id_emploee, что будет работать гораздо быстрее, чем группировка по текстовому полю.

srv2.sys - системный драйвер. Попробуйте что-нибудь из средств восстановления ОС. Например:
sfc /scannow

Если бы дело было в ОЗУ, то вылетали бы все подряд игры, да и не игры то же, и винда бы сама по себе падала.
Начните с замеров температуры проца, чипсета, видяхи, во время простоя, во время игры. Сравните температуру на разных играх.
Смените термопасту везде где сможете, проверьте все кулеры, особено на ЦП, БП и видео. Корпусные не столь важны, хотя, если Ezhyg прав, то возможно, хорошо бы поставить дополнительный кулер на корпус, а то и два (на вдув и выдув).

Вообще то юнит тесты (модульные тесты) не предназначены для встраивания в приложение. Тест это отдельное приложение, предназначенное для тестирования компонентов (функций, классов и т.п.) основного приложения. Обычно тесты не входят в состав релиза приложения (я не говорю сейчас про приложения распространяемые в исходниках, в этом случае тесты часто идут в составе).
Что бы сделать то что вы хотите, просто пишите тест как часть приложения, без использования библиотек предназначенных для модульных тестов. Это будет быстрее.
В принципе, что-то можно использовать из них с учетом того, что большая их часть выводит информацию на консоль, создает свою функцию main, ... Т.е. что-бы использовать их не по назначению нужно хорошо знать внутреннюю организацию и понимать как оно работает.

Справочника нет. Как разработчики задумали так и работает. Возможно у микрософта есть справочник, но я не встречал. Все подобные штуки находятся в разных местах, кому-то понадобилось, раскопал сам или спросил в поддержке или еще где, опубликовал. Другой уже может найти у первого и т.д.
Часто приходится в поисках необходимой информации тратить много времени на гуглеж и вникание в тему. По другому не бывает.
Есть несколько часто используемых фич, которые ищутся быстро, остальное ... нужно приложить усилия.

Преобразовывайте все 4 поля в строку, конкатенируйте полученные строки, по полученной строке стройте индекс.