Comments 6
Спасибо, что поделились опытом. Очень интересно.
Если не NDA (ну вдруг), то можете рассказать поподробнее?:
1) реплика на которую преключаетесь находится локально в том же ЦОДе? А для DR есть offsite-реплика?
2) у вас реплики под управлением Pacemaker-кластера или просто primary-secondary с ручным takeover'ом?
3) реплика с preload_column_tables = true?
4) сколько выставлен tables_preloaded_in_parallel? И какая скорость чтения с диска при стартапе без FastRestart'а.
5) при таких ресурсах (12TB+448core) и 10K юзеров во сколько выставлены default_statement_concurrency_limit и statement_memory_limit?
6) ECC или S4? :)
Из того как боремся сами (объемы, правда, поменьше): кручение параметров по нотам при различных утечках в разных аллокаторах на разных ревиженах, reload_tables=false на копиях прода, workload-классы для особо прожорливых репортов/транзакций и непонятливых юзеров ну и resman shrink если уж совсем апож. Смотрим на NSE, который теперь можно в ECC/S4.
С logreplay есть «дьявол в деталях» — если на реплике выставлен preload_column_tables = false, то indexserver все-равное будет лопать память аллокатором Pool/ColumnStore и чем дольше реплика работает — тем больше. Поэтому при совмещении реплики с препродом/тестом приходится играться с GAL и периодически передергивать реплику или переходить на delta_datashipping, в котором такого нет.
Если не NDA (ну вдруг), то можете рассказать поподробнее?:
1) реплика на которую преключаетесь находится локально в том же ЦОДе? А для DR есть offsite-реплика?
2) у вас реплики под управлением Pacemaker-кластера или просто primary-secondary с ручным takeover'ом?
3) реплика с preload_column_tables = true?
4) сколько выставлен tables_preloaded_in_parallel? И какая скорость чтения с диска при стартапе без FastRestart'а.
5) при таких ресурсах (12TB+448core) и 10K юзеров во сколько выставлены default_statement_concurrency_limit и statement_memory_limit?
6) ECC или S4? :)
Из того как боремся сами (объемы, правда, поменьше): кручение параметров по нотам при различных утечках в разных аллокаторах на разных ревиженах, reload_tables=false на копиях прода, workload-классы для особо прожорливых репортов/транзакций и непонятливых юзеров ну и resman shrink если уж совсем апож. Смотрим на NSE, который теперь можно в ECC/S4.
С logreplay есть «дьявол в деталях» — если на реплике выставлен preload_column_tables = false, то indexserver все-равное будет лопать память аллокатором Pool/ColumnStore и чем дольше реплика работает — тем больше. Поэтому при совмещении реплики с препродом/тестом приходится играться с GAL и периодически передергивать реплику или переходить на delta_datashipping, в котором такого нет.
+1
Добрый день, krids!
1. Нет, это 2 разных ЦОДа.
2. Pacemaker настроен, да. Все автоматически переезжает. Тут тоже пришлось поплясать с бубном, чтобы хорошо работало.
3. Все верно, параметр не меняли. По умолчанию preload_column_tables = true
4. tables_preloaded_in_parallel = 30. Диск никогда не замеряли специально, а проверять на продуктиве сейчас не хочется) Но если будет возможность, обязательно проверим.
5. default_statement_concurrency_limit = 40, statement_memory_limit =150
6. В рамках этой статьи речь по ECC, но в ближайшее время уже проверим и на S/4)
Утечка памяти в аллокаторах — извечная проблема. Не стал ее описывать в статье, но тоже сталкиваемся регулярно. На большой базе это не так сильно заметно, а вот на меньших объемах в 512 Гб — 1,5 Тб бывает очень критично. И что самое сложное — очень сильно зависит от ревизии HANA. Приходится тщательно тестировать все новые обновления. Ну и shrink спасает, конечно.
NSE сейчас тоже тестируем. Пока в поиске разумного баланса между скоростью считывания и потреблением памяти :) Опция как минимум хороша для не продуктивных систем, если требуется использовать железо с меньшим объемом памяти.
А вот про logreplay и preload_column_tables = false — не сталкивался. Видимо, никогда не тестировали такую конфигурацию. Спасибо за информацию!
1. Нет, это 2 разных ЦОДа.
2. Pacemaker настроен, да. Все автоматически переезжает. Тут тоже пришлось поплясать с бубном, чтобы хорошо работало.
3. Все верно, параметр не меняли. По умолчанию preload_column_tables = true
4. tables_preloaded_in_parallel = 30. Диск никогда не замеряли специально, а проверять на продуктиве сейчас не хочется) Но если будет возможность, обязательно проверим.
5. default_statement_concurrency_limit = 40, statement_memory_limit =150
6. В рамках этой статьи речь по ECC, но в ближайшее время уже проверим и на S/4)
Утечка памяти в аллокаторах — извечная проблема. Не стал ее описывать в статье, но тоже сталкиваемся регулярно. На большой базе это не так сильно заметно, а вот на меньших объемах в 512 Гб — 1,5 Тб бывает очень критично. И что самое сложное — очень сильно зависит от ревизии HANA. Приходится тщательно тестировать все новые обновления. Ну и shrink спасает, конечно.
NSE сейчас тоже тестируем. Пока в поиске разумного баланса между скоростью считывания и потреблением памяти :) Опция как минимум хороша для не продуктивных систем, если требуется использовать железо с меньшим объемом памяти.
А вот про logreplay и preload_column_tables = false — не сталкивался. Видимо, никогда не тестировали такую конфигурацию. Спасибо за информацию!
0
Большое спасибо за ответы, но появляются еще вопросы (тема «больная») :)
Не расскажите как сделан stonith/fencing? Кейс с network isolation (когда с primary-БД все хорошо, но с нее недоступны ни реплика ни fencing device) тестировали? ASCS/AS реплицируете во второй ЦОД?
1. Нет, это 2 разных ЦОДа.
2. Pacemaker настроен, да. Все автоматически переезжает. Тут тоже пришлось поплясать с бубном, чтобы хорошо работало.
Не расскажите как сделан stonith/fencing? Кейс с network isolation (когда с primary-БД все хорошо, но с нее недоступны ни реплика ни fencing device) тестировали? ASCS/AS реплицируете во второй ЦОД?
В рамках этой статьи речь по ECC, но в ближайшее время уже проверим и на S/4)Cкорее всего увидите много «открытий чудных» и мемори-лимит придется раза в два приподнять ;)
0
Не расскажите как сделан stonith/fencing? Кейс с network isolation (когда с primary-БД все хорошо, но с нее недоступны ни реплика ни fencing device) тестировали? ASCS/AS реплицируете во второй ЦОД?
Тут, к сожалению, речь про КТ. Полноценно раскрыть не могу. Скажем так, кейс с network isolation стараемся не допускать, но проблема такая есть.
Cкорее всего увидите много «открытий чудных» и мемори-лимит придется раза в два приподнять ;)
krids, может поделитесь с чем столкнулись? Очень любопытно)
0
Упс....прошу прощения, пропустил. В основном на S4 проблема с неоптимальными СDS выедающими кучу памяти (у нас лимит 400GB и иногда в закрытие приходится крактовременно увеличивать). Тот же "всеми любимый" J_3RMOBVEDH теперь сделан ADMP-процедурой и тоже ест памяти (пришлось на него сделать workload class на 200GB лимита)
0
Из статьи непонятно, используются ли два равноценных по ресурсам узла для построения кластера. Если они равноценны, то БД ещё с древнейших версий SP HANA 1.0 умела выполнять синхронную репликацию online. Тогда вся перезагрузка сводилась бы ко времени отработки команды hdbnsutil.
0
Sign up to leave a comment.
Запускаем SAP HANA за 2 минуты вместо 80