Статья отличная.
Хочу сказать что я не всегда имею возможность ставить плюсики, так как иногда читаю вас с чужих устройств: на работе, у знакомых, с компа бабушки и т.п. И я думаю что не один я такой здесь. Поэтому вы продолжайте писать и не сильно обращайте на рейтинг :)
В моем посте я показываю простейший пример, на котором видно что неправильное использование NUMA может существенно ухудшить производительность. Любой может воспроизвести этот пример и убедится в этом.
Что касается поста, который приведен в вашей ссылке, то в нем говориться о тестировании SQL приложения для NUMA. Я могу предположить, что это приложение не относится к тем, которые чувствительны к NUMA. Т.е. другими словами, это приложение скорее сильно зависит от работы диска или сети и слабо зависит от работы памяти.
NUMA была разработана для улучшения производительности памяти. Если приложение работает с памятью больше чем с другими компонентами системы, то правильное использование NUMA существенно улучшает производительность. Более того, сама доработка приложения под NUMA иногда может потребовать существенных вложений. Поэтому перед тем как приступать к доработке, необходимо провести предварительный анализ работы приложения. Ведь может оказаться что вложения не окупятся.
действительно, информация лежит на поверхности, и если вдуматься, то разделяемый LLC может позволить одному ядру обнулить L1/L2 другому.
отличный пост! спасибо.
Извините за прямолинейность, но я не увидел в статье явного ответа на вопрос в заголовке «Действительно ли у каждого ядра есть «свой собственный» кэш первого и второго уровней?».
Или еще проще: вы можете правильно выделить страницы и numactl вам скажет что всё ОК, но неправильно обращение к ним приведет к падению производительности.
Не совсем.
numastat – это утилита, предназначенная для сбора статистики по выделению страниц на нодах, но не по обращению к ним. Это всего лишь учёт аллокаций памяти. Вы можете выделить всего несколько страниц на «чужой» ноде, но из-за постоянного обращения к ним можете «подсадить» производительность.
А количество обращений можно посчитать с помощью счетчиков, указанных в моей статье.
Да, это всё сводится к КЭШ миссам. Но акцент в статье сделан на шину данных, так как на архитектурах Out-Of-Order порой бывает очень сложно понять насколько серьезно страдает приложение от какого-либо количества промахов по КЭШ’у. А благодаря замеру загрузки шины это сделать намного легче.
О правильной работе с КЭШом написаны целые книги. Мы конечно же поговорим об этом тоже как-нибудь в другой раз.
конечно…
Хочу сказать что я не всегда имею возможность ставить плюсики, так как иногда читаю вас с чужих устройств: на работе, у знакомых, с компа бабушки и т.п. И я думаю что не один я такой здесь. Поэтому вы продолжайте писать и не сильно обращайте на рейтинг :)
Скажите, пожалуйста, когда можно будет купить Intel Quark по Intel EPP? На данный момент он там не доступен.
В моем посте я показываю простейший пример, на котором видно что неправильное использование NUMA может существенно ухудшить производительность. Любой может воспроизвести этот пример и убедится в этом.
Что касается поста, который приведен в вашей ссылке, то в нем говориться о тестировании SQL приложения для NUMA. Я могу предположить, что это приложение не относится к тем, которые чувствительны к NUMA. Т.е. другими словами, это приложение скорее сильно зависит от работы диска или сети и слабо зависит от работы памяти.
NUMA была разработана для улучшения производительности памяти. Если приложение работает с памятью больше чем с другими компонентами системы, то правильное использование NUMA существенно улучшает производительность. Более того, сама доработка приложения под NUMA иногда может потребовать существенных вложений. Поэтому перед тем как приступать к доработке, необходимо провести предварительный анализ работы приложения. Ведь может оказаться что вложения не окупятся.
отличный пост! спасибо.
numastat – это утилита, предназначенная для сбора статистики по выделению страниц на нодах, но не по обращению к ним. Это всего лишь учёт аллокаций памяти. Вы можете выделить всего несколько страниц на «чужой» ноде, но из-за постоянного обращения к ним можете «подсадить» производительность.
А количество обращений можно посчитать с помощью счетчиков, указанных в моей статье.
О правильной работе с КЭШом написаны целые книги. Мы конечно же поговорим об этом тоже как-нибудь в другой раз.