Эти вещи, очевидно, требуют тщательного изучения и наличия кода для тщательного анализа и предоставления хороших предложений. Тем не менее, это не всегда возможно, и я надеюсь, что мне удастся дать мне полезные советы, основываясь на информации, которую я предоставляю ниже.
У меня есть серверное приложение, которое использует поток слушателя для прослушивания входящих данных. Поступающие данные интерпретируются в сообщения, специфичные для приложения, и эти сообщения затем вызывают события.
До этого момента я не имел никакого контроля над тем, как все делается.
Поскольку это унаследованное приложение, об этих событиях ранее заботился тот же поток слушателя (в основном однопоточное приложение). События отправляются в черный ящик, и появляется результат, который должен быть записан на диск.
Чтобы повысить пропускную способность, я хотел использовать пул потоков, чтобы заботиться о событиях. Идея заключается в том, что поток слушателя может просто создавать новые задачи каждый раз, когда создается событие, и потоки будут заботиться о вызове черного ящика. Наконец, у меня есть фоновый поток, выполняющий запись на диск.
Только с предыдущей настройкой и средством записи в фоновом режиме все работает нормально, а пропускная способность в ~ 1,6 раза больше, чем ранее.
Когда я добавляю пул потоков, производительность снижается. В начале все, кажется, работает гладко, но через некоторое время все очень медленно, и, наконец, я получаю OutOfMemoryExceptions. Странно то, что когда я печатаю количество активных потоков каждый раз, когда задача добавляется в пул (вместе с информацией о том, сколько задач поставлено в очередь и т. Д.), Это выглядит так, как будто у пула потоков нет проблем, не отставая от продюсер (ветка слушателя).
Используя top -H для проверки загрузки процессора, он с самого начала довольно равномерно распределяется, но в конце рабочие потоки едва активны и активен только поток слушателя. И все же, похоже, он не отправляет больше задач ...
Может ли кто-нибудь предположить причину этих симптомов? Как вы думаете, более вероятно, что в унаследованном коде есть что-то (что я не могу контролировать), которое просто портится при добавлении нескольких потоков? Проблема нехватки памяти должна быть вызвана тем, что некоторая очередь где-то становится слишком большой, но поскольку пул потоков почти никогда не содержит задач, поставленных в очередь, этого не может быть.
Любые идеи приветствуются. Особенно идеи о том, как более эффективно диагностировать такую ситуацию. Как я могу получить лучший профиль того, что делают мои темы и т. Д.
Спасибо.