Доброго времени суток!

Написал я некоторый сервер с использованием boost.asio по модели, когда есть один экземпляр io_service и пул потоков по числу cpu, каждый из которых выполняет run().

Профилирование сервера показало просто дикое число блокировок мутексов и условных переменных внутри ASIO при использовании epoll. Сейчас на маленьких тестах это миллионы блокировок, на больших тестах и при нормальной работе будут миллиарды, что душу явно не греет и не факт, что способствует использованию всех 4-х ядер существующей железки и всех 20 планируемой.

Почитав документацию я увидел следующее http://www.boost.org/doc/libs/1_52_0/doc/h...ementation.html :

и похоже именно отсюда растут уши такого количества блокировок.

Подскажите пожалуйста, как с осознанием всего этого жить и есть ли выходы, лучшие чем переписывание на модель вида пул потоков в каждом из которых свой io_service и жестким распихиванием клиентов по этим io_service при подключении или еще какую-нибудь модель?

Вот здесь, здесь и здесь есть некоторые размышления на эту тему.

Вкратце, вы правы - придется применять "модель вида пул потоков в каждом из которых свой io_service и жестким распихиванием клиентов по этим io_service при подключении". Этот выбор можно и отложить на run time - см. проект echo_server (qt_echo_server) из https://asio-samples.svn.sourceforge.net/sv...o-samples/trunk.

Если же углубиться в детали, то "виновата" не библиотека Boost.Asio а сам epoll (точнее его реактивная идеология). В Windows, с его проактором на уровне ОС, я не смог повторить эту проблему.

mabrarov,
Спасибо за ссылки, почитаю.


Значит придется применить...


Немного не понял, что имеется ввиду?
Нечто отличное от выбора io_service в момент создания объекта-клиента? А выбор например циклический.



А про Windows мануал говорит:

Там такой проблемы и не должно быть судя по всему.

Модель (одну из) 

•  один экземпляр asio::io_service и пул рабочих потоков, работающих с этим единственным экземпляром
•  по одному экземпляру asio::io_service на каждый рабочий поток (аля пул из asio::io_service)

можно выбирать в run time.

Да, действительно.


В итоге я остановился на следующей структуре приложения:
1) main_io_service - не занимается вообще ничем кроме как отслеживания сигналов операционной системы (SIGINT и т.д.), выполняется в главном потоке отвечает за управление модулями, корректное завершения приложения и т.д.
2) background_io_service и пул потоков, выполняющих background_io_service.run() - предназначен для выполнения тяжелых фоновых операций. Вспомогательные таймеры, загрузка/выгрузка на диск различных данных, с которыми можно оперировать в фоновом режиме.
3) пул потоков, в каждом свой io_service - для обслуживания сетевой активности. Сокет в момент создания прикрепляется к одному из потоков. Так как большинство моих действий при работе с сетью очень легкие, то это работает нормально даже не смотря на наличие некоторого количества mutex'ов для защиты общих структур данных. Вначале я беспокоился, что один глобальный mutex будет тормозить, но тестирование показало что до момента, когда я упрусь в него еще очень и очень долго (глобальный mutex защищает map объектов, которые нужно доставать по ключу, а так как map редко, но все-же меняется, то пришлось использовать mutex).

посмотри Boost.shared_mutex

ИМХО как раз твой случай

borisbn, 
Спасибо за совет про Boost.shared_mutex, я про него правда знаю.
В ближайшее время посмотрю на сколько shared_mutex будет лучше.