![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Linkedin делится опытом: для графовой базы данных, находящейся целиком в ОЗУ сервера, и работающей в NUMA-окружении, выгодно отключать zone reclaim. Полезно для снижения задержки на обработку запроса:
http://engineering.linkedin.com/performance/optimizing-linux-memory-management-low-latency-high-throughput-databases
Немного пояснений для тех, кто в танке:
1) Вся БД в ОЗУ, чтений много больше чем записей, скорость работы диска не важна в данном случае — всё упирается в скорость работы памяти
2) NUMA — это когда вся память в системе сгруппирована по процессорам (ядрам), и каждому процессору быстрее обращаться к своей памяти, чем к чужой.
3) Поэтому ядерный аллокатор страничной памяти стремится выделить память в той зоне, где находится текущий процессор, а планировщик задач ядра стремится назначать потоку по возможности один и тот же процессор.
4) Из практики известно, что жёсткое закрепление потоков за процессорами (thread affinity) в NUMA среде может дать выигрыш по скорости порядка 25-30%. Ну а в случае каких-то патологических версий ядра — в 2-3 раза.
5) Инженегры ведра линупса опять чё-то перемудрили — они наваяли неведомую хрень под названием NUMA zone reclaim, которая чё-то творит в фоне со страничной зоной каждого процессора: крутит спинлоки, гоняет туда-сюда IPIшки и так далее. Какая польза от всей этой кипучей деятельности — совершенно непонятно, но известно наверняка, что её отключение приводит к росту производительности работы с ОЗУ. Например, на графовых БД — на порядок.
IBM кстати отключает эту ерунду на своих гипервизорах:
http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaat%2Fliaattunsetzonereclaim.htm
PostgreSQL'щики тоже давно заметили какой-то подвох с этой бодягой:
http://frosty-postgres.blogspot.com/2012/08/postgresql-numa-and-zone-reclaim-mode.html
Что-то неладное творится с этим NUMA zone reclaim в связке с ZFS-кэшем в ОЗУ (ARC) — deadlocks: https://github.com/zfsonlinux/zfs/issues/1000
Также народ жалуется, что даже обычные сервера (file/email/web server) от этой фигни тормозят безбожно:
http://us.generation-nt.com/answer/default-zone-reclaim-mode-1-numa-kernel-bad-file-email-web-servers-help-200325161.html
FreeBSD имеет поддержку NUMA в том смысле, что ядерный аллокатор страничной памяти стремится выделить её в той же зоне, где находится в настоящий момент запрашивающий поток. Но если локальная зона опустела — тогда страница просто выделяется из чужой зоны — FreeBSD не предпринимает никаких попыток гонять данные между страницами в фоне, с тем, чтобы они были поближе к своим процессорам: http://svnweb.freebsd.org/base?view=revision&revision=210550
Однако некоторые архитекторы FreeBSD (например Константин Белоусов), считают, что даже такой минимализм — это лишнее: http://samag.ru/archive/article/1225 (вероятно потому, что всё это трюкачество без одновременного трюкачества с маской аффинности — пустая трата времени). В целом, забавно наблюдать, как на форумах вопли "когда вы уже запилите полную поддержку NUMA?" плавно сменились благодарностями, что её нет и не будет.
http://engineering.linkedin.com/performance/optimizing-linux-memory-management-low-latency-high-throughput-databases
Немного пояснений для тех, кто в танке:
1) Вся БД в ОЗУ, чтений много больше чем записей, скорость работы диска не важна в данном случае — всё упирается в скорость работы памяти
2) NUMA — это когда вся память в системе сгруппирована по процессорам (ядрам), и каждому процессору быстрее обращаться к своей памяти, чем к чужой.
3) Поэтому ядерный аллокатор страничной памяти стремится выделить память в той зоне, где находится текущий процессор, а планировщик задач ядра стремится назначать потоку по возможности один и тот же процессор.
4) Из практики известно, что жёсткое закрепление потоков за процессорами (thread affinity) в NUMA среде может дать выигрыш по скорости порядка 25-30%. Ну а в случае каких-то патологических версий ядра — в 2-3 раза.
5) Инженегры ведра линупса опять чё-то перемудрили — они наваяли неведомую хрень под названием NUMA zone reclaim, которая чё-то творит в фоне со страничной зоной каждого процессора: крутит спинлоки, гоняет туда-сюда IPIшки и так далее. Какая польза от всей этой кипучей деятельности — совершенно непонятно, но известно наверняка, что её отключение приводит к росту производительности работы с ОЗУ. Например, на графовых БД — на порядок.
IBM кстати отключает эту ерунду на своих гипервизорах:
http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaat%2Fliaattunsetzonereclaim.htm
PostgreSQL'щики тоже давно заметили какой-то подвох с этой бодягой:
http://frosty-postgres.blogspot.com/2012/08/postgresql-numa-and-zone-reclaim-mode.html
Что-то неладное творится с этим NUMA zone reclaim в связке с ZFS-кэшем в ОЗУ (ARC) — deadlocks: https://github.com/zfsonlinux/zfs/issues/1000
Также народ жалуется, что даже обычные сервера (file/email/web server) от этой фигни тормозят безбожно:
http://us.generation-nt.com/answer/default-zone-reclaim-mode-1-numa-kernel-bad-file-email-web-servers-help-200325161.html
FreeBSD имеет поддержку NUMA в том смысле, что ядерный аллокатор страничной памяти стремится выделить её в той же зоне, где находится в настоящий момент запрашивающий поток. Но если локальная зона опустела — тогда страница просто выделяется из чужой зоны — FreeBSD не предпринимает никаких попыток гонять данные между страницами в фоне, с тем, чтобы они были поближе к своим процессорам: http://svnweb.freebsd.org/base?view=revision&revision=210550
Однако некоторые архитекторы FreeBSD (например Константин Белоусов), считают, что даже такой минимализм — это лишнее: http://samag.ru/archive/article/1225 (вероятно потому, что всё это трюкачество без одновременного трюкачества с маской аффинности — пустая трата времени). В целом, забавно наблюдать, как на форумах вопли "когда вы уже запилите полную поддержку NUMA?" плавно сменились благодарностями, что её нет и не будет.
