tcmalloc огромная разница в производительности

Наш многопоточный сервер имеет сотни потоков подключения, которые отвечают за обработку ввода-вывода и ответы на входящие запросы.

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

После того, как я преобразовал этот поток в небольшой пул потоков (т. е. эти задачи теперь каждый раз выполняются из разных потоков), наш сервер обычно имеет одинаковое использование ЦП, но он может внезапно достичь состояния, в котором выделение ресурсов для всех операций занимает гораздо больше времени, а общий ЦП использование сервера почти удваивается с 2 ядер до 3,7 ядер.

Моя основная теория до сих пор заключается в том, что я каким-то образом изменил шаблон доступа к библиотеке tcmalloc, и это вызывает случайные подъемы ЦП. Что я должен посмотреть в статистике tcmalloc, чтобы подтвердить эту теорию? Может ли быть так, что один и тот же код, работающий сейчас из разных потоков (но не одновременно), заставляет tcmalloc выделять из центрального кеша больше, чем из кеша потоков?


person Roman    schedule 19.08.2015    source источник
comment
Я думаю, что ложное совместное использование или какая-то другая форма конфликта между потоками в новом пуле потоков является более вероятным объяснением.   -  person David Schwartz    schedule 19.08.2015
comment
Что это за ложный обмен? Между задачами нет конфликтов, а пул потоков не блокируется. Также я вижу в профилировщике, что часть ЦП tcmalloc значительно увеличивается по сравнению с неподнятым состоянием ЦП сервера.   -  person Roman    schedule 19.08.2015
comment
Ложное совместное использование — это когда два потока совместно используют данные в одной и той же строке кэша. И я согласен, что это вполне вероятно проблема.   -  person Mats Petersson    schedule 19.08.2015
comment
Ложное совместное использование — это когда два потока работают одновременно и обращаются к ресурсам, которые кажутся отдельными, но на самом деле вызывают конкуренцию — например, потому что они совместно используют строку кэша.   -  person David Schwartz    schedule 19.08.2015
comment
Спасибо, это очень интересная идея. Могу ли я подтвердить это, посмотрев на график профилировщика gperftools?   -  person Roman    schedule 19.08.2015


Ответы (1)


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

Инструменты, соответствующие этим исследовательским работам, доступны на GitHub: Sheriff, Хищник.

Хотя вы можете попробовать использовать один из этих инструментов для поиска проблемы, проще всего будет попробовать Hoard. . Hoard — это быстрая, масштабируемая замена malloc, дизайн которой снижает риск ложного совместного использования, вызванного распределителем. Если замена tcmalloc на Hoard не решает вашу проблему, возможно, имеет смысл использовать другие возможности.

person EmeryBerger    schedule 25.09.2015
comment
Как Hoard сравнивается с tcmalloc? - person Roman; 27.09.2015
comment
Hoard, как правило, работает быстрее и занимает меньше места. Например, вот микробенчмарк, который многократно выделяет и освобождает память в разных потоках. Более низкие времена лучше (очевидно!). tcmalloc: 6,09 с (1 поток), 4,03 с (4 потока) Hoard: 3,69 с (1 поток), 1,73 с (2 потока) (проверено на MacBook Air, последние сборки каждого) - person EmeryBerger; 27.09.2015