Управление потоком и использованием памяти при работе с процессом блокировки

Question

У меня есть куча файлов (порядка 10 в секунду), поступающих в систему (хранящихся в базе данных).Каждый файл содержит запись от 1 до 500 устройств.Данное устройство будет отображаться в нескольких файлах (но не в каждом файле).Эти данные в конечном счете должны быть сохранены в другой базе данных, сохраненной для каждого устройства.Существует два разных формата файлов.

Существует API, который заботится о конечной части базы данных, которая принимает несколько записей для одного устройства (за кулисами также выполняется поиск для поиска идентификаторов в базе данных).и, таким образом, обработка нескольких записей одновременно для одного устройства означает выполнение поиска один раз, а не один раз для каждой записи).

Для этого у меня есть программа, состоящая из нескольких частей:

• Анализ файлов, извлечение данных в общий набор объектов данных.
  • Это многопоточный процесс с одним потоком на файл, добавляющий данные в потокобезопасную коллекцию.
  • По мере загрузки каждого файла его запись в БД помечается как «в процессе»
• Сохранение объектов в базе данных
  • Еще один многопоточный процесс, который извлекает все объекты для данного устройства, а затем сообщает API данных о необходимости их сохранения.
  • После успешного сохранения всех устройств из одного файла (или при сбое) запись в БД для исходного файла помечается как успешная / неудачная

---

Мой вопрос таков: как лучше всего управлять, когда анализировать файлы, сколько потоков использовать, сколько оперативной памяти и т. Д.?

• API данных займет больше всего времени - большинство извремя, потоки там будут просто ждать возврата API.
• Общая эффективность системы повышается за счет увеличения количества данных, сгруппированных на устройство.
• Приложение не должно исчерпать ОЗУ или иметь так много файлов, которые анализируются, но ожидают сохранения, чтобы сохранить его.вызывает обмен ОС.
• Неизвестно, сколько одновременных вызовов может обрабатывать API БД, или как быстро он выполняется - этот процесс должен адаптироваться к этому

Так как мнезнаете, когда анализировать файлы, чтобы убедиться, что это происходит настолько быстро, насколько это возможно, без снижения производительности при использовании слишком большого объема ОЗУ?

Answer 1

Похоже, у вас есть система, которая очень сильно связана с вводом / выводом (файлы на входной стороне и БД на выходной). Я не вижу там частей, интенсивно использующих процессор.

Очевидная оптимизация уже в вопросе: объедините множество входящих файлов и сгруппируйте данные для каждого устройства. Стоимость - это потребление памяти и задержка при обновлении базы данных. Вам понадобятся параметры для этого.

В качестве первой идеи я бы поставил ее на 3 блока, связанных ограниченными очередями. Эти очереди позволят любому «перегруженному» компоненту задушить своих поставщиков.

блок 1: 1 или 2 потока (зависит от системы ввода / вывода) для чтения и анализа файлов,

блок 2: 1 поток для организации и группировки данных. Решите, когда данные устройства должны перейти на Db

блок 3: 1+ потоков отправляет данные в БД.

Блоки дают этой системе некоторую гибкость. Ограниченные очереди позволяют контролировать потребление ресурсов. Обратите внимание, что блок 2 должен быть параметризован для настройки размера блока.

Answer 2

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

Диспетчер может постоянно отслеживать доступную системную память и использование процессора (используя, например, счетчик производительности API).

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

Кроме того, если вы работаете в 32-битной среде, то один процесс может использовать только около 800 МБ оперативной памяти, прежде чем вы получите исключение нехватки памяти, поэтому вам, возможно, придется принять это во внимание.

Ваш третий фактор для начала новой работы - API БД. Пока это может поглотить вашу добавленную работу, продолжайте добавлять больше потоков.

Поток программы будет примерно таким:

1. Использовать и анализировать файлы
2. При достижении предела памяти (и / или лимита процессора), пакетируйте их в API БД
3. Когда вы выполняете пакетную обработку для API БД, память освобождается, и новые файлы могут обрабатываться - переходите к 1