мьюеткс vs IPCiv_an_ruпропущено...
Да нечего там было изучать. Очень большая база с RDF и много-много юзеров, каждый из которых ковыряется read-only в одних и тех же "очень активных" данных плюс каких-то неповторяющихся "непопулярных". Под Linux, а у него есть противная особенность: просто вход и выход из мьютекса не стоят почти ничего, а вот начало ожидания на мьютексе стоит примерно столько же, сколько целая выборка строки по ключу. В случае кластера проблемы с мьютексами уменьшились настолько, что экономия перевесила даже IPC. Поскольку для такого эффекта нужно, чтобы сервер "лёг на полку", не справляясь с нагрузкой, на практике такой сценарий просто не должен встречаться.

(Потом появились деньги, и вместо одного ящика поставили 8. Как раз вовремя, потому что база подросла до 2.5e10 фактов, ну и юзеров ещё больше стало.)
А это только в Linux такая особенность, что ожидание занятых ресурсов через мьютекс съедает больше чем межпроцессный обмен по IPC?
Или в Unix(AIX)/Solaris/Windows также?Вообще-то в каждой операционке свой график цены "сработавшего" мьютекса от общего числа "достаточно активных" нитей, между которыми планировщику надо выбирать. Скажем, винда замечательно выбирает из двух нитей, потом резкий спад скорости, то есть всё умышленно оптимизировано для популярного случая нити активно рисующей и нити активно считающей. Linux начинает чуть хуже, зато более плавно деградирует. AIX показывает самый заметный overhead на паре нитей, но зато этот overhead --- практически константа, и ящик одинаково пофигистично держит любой тип нагрузки.

И да, хороший пакетный протокол IPC может обогнать ожидалки мьютексов, когда цена ожидания начинает становиться сравнимой с таймслайсом планировщика.

RXLКстати, вопрошающим не сказано, какие объекты синхронизации рассматриваются: внутриядерные или в разделяемой пользовательской памяти. Первые имеют преимущество при преобладающем ожидании, вторые - при редком ожидании.Разнообразные, но рабочие лошадки под виндой --- WaitForSingleObject (...INFINITE) для длинных и EnterCriticalSection для коротких, под pthreads классический спин pthread_mutex_trylock плюс pthread_mutex_lock, а с самодельными фибрами в единственном потоке, сами понимаете, вообще ничего не надо, вот только годятся они теперь разве что для карманных устройств.

ожидалки мьютексовiv_an_ruИ да, хороший пакетный протокол IPC может обогнать ожидалки мьютексов, когда цена ожидания начинает становиться сравнимой с таймслайсом планировщика.
Так а за счет чего все таки IPC обгоняет ожидалки мьютексов?Если мьютекс начинает ждать на хотя бы каждой десятой записи, а в пакет влезает 10000 сообщений и он "стоит" максимум два сообщения, то...

MutexSpinCountiv_an_ruпропущено...
Если мьютекс начинает ждать на хотя бы каждой десятой записи, а в пакет влезает 10000 сообщений и он "стоит" максимум два сообщения, то...А почему бы для высокой конкуренции не... делать mutex.try_lock() некоторое число раз до того как заснуть.А проблема выглядит так, как описано, уже с учётом этого трюка, без него было бы хуже.
В коде используются две разные "породы" мьютексов, для "коротких в среднем" и для "длинных в среднем" ожиданий, с разной политикой по поводу try_lock.

MutexSpinCount,

На самом деле трюков там куда больше, но пусть хотя бы самые интересные из них останутся маленьким секретом ;)

MutexSpinCount,

Ситуация, когда в скромных 128 гигов ОЗУ умещаются 13 миллиардов записей, причём с 2 полными и 3 неполными индексами --- она странная сама по себе :)

MutexSpinCountА насчет ожиданий на мьютексах, восьмушки были быстрее по общему количеству запросов в секунду или именно латентность была меньше, и эти измерения проводились при нагрузке CPU близкой к 100%?По общему количеству запросов в секунду. На той версии, которая готовится сейчас к выпуску, одиночный процесс будет всё же быстрее на той конкретной нагрузке, но это было достигнуто ценой заморочек в других местах.