Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Caché Новый топик    Ответить
 Write Image Journaling  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 708
Добрый день, Уважаемые Форумчане!
Прошу поделиться опытом по следующим вопросам:
1. Как сопоставляется размер файла cache.wij с общим размером активных баз данных?
2. Как сопоставляется размер файла cache.wij с размером буфера глобалов?
3. Как сопоставляется размер файла cache.wij с оставшимся размером оперативной памяти, не занятым Каше?
4. Плюсы и минусы большого и малого размера файла cache.wij (1, 2, 4, 8, 12, 16, ... ГБ) ?
5. Насколько я понимаю, прямого управления размером файла cache.wij у администратора нет, но все же за размером этого файла стоит наблюдать, или нет?
6. Если да, то как оценивать тревожные, аварийные размеры файла cache.wij?
7. Каким образом определять резервируемое место под файла cache.wij?
8. Режим "панического сброса блоков в БД" и большой размер файла cache.wij, когда наступает неоправданный риск?
9. Ну и наверняка может кто еще чего вспомнит...

Заранее благодарен.
28 авг 17, 14:51    [20753857]     Ответить | Цитировать Сообщить модератору
 Re: Write Image Journaling  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2358
На счет размера этого файла не думаю что есть смысл на него как то опираться, как никак он все таки промежуточный, и главное чтобы записи из него успевали попадать в сами базы данных.
Его размером управлять нельзя это верно.
Но если есть большой объем записи в базу данных, то лучше расположить его на отдельном диске, так же как и файлы журналов. При высокой нагрузке по записи, все файлы в которые идет запись должны быть максимально распределены. И имееется ввиду не просто другой диск, а должен быть и другой контроллер. Таким образом загрузка одного диска не будет влиять на другой. Но в то же время стоит беспокоится и о хорошей доступности WIJ файла. Например, в нормальной высоконагруженной конфигурации, у вас должна быть дисковая полка подключенная по оптике к серверу в несколько контроллеров. На этой полке допустимо хранить файлы баз данных, но не стоит хранить WIJ файл, который лучше расположить на SSD диске на самом сервере и конечно в RAID. Выбор RAID тоже очень важная задача, хотя для хранения WIJ достаточно и простого зеркала из двух дисков, Но если дисков несколько, то тут важно не ошибится. У нас как то возникли проблемы с RAID5, и RAID наш благополучно умер, когда решил что вышло два диска подряд. Но данные спасли к счастью.

На что еще стоит обратить внимание, так это на то как быстро и как происходит реальная запись. Наблюдать это можно через mgtstat. Там есть такие показатели, как фаза WriteDaemon (WDphase), нужно следить чтобы WriteDaemon не был слишком долго в 8 фазе, это фактическая запись данных в базы данных. Фаза 5 это накопление WIJ. В нагруженных системах обычно только эти фазы, если система простаивает то фаза 0.
Wijwri - Показатель того сколько сейчас данных в WIJ
WDQsz - очередь WriteDaemon
PhyWrs - Собственно фактическая физическая запись в базу.

Но есть еще отличия, с которыми я если честно пока не сталкивался. На Windows может работать только один WriteDaemon, на Linux насколько я знаю из может быть больше, но как это можно менять я не знаю. Не было пока необходимости.

mgstat кстати полезен не только для мониторинга проблем с записью, но и в целом проблем с производительностью самого приложения. Блокировки, Эффективность использования кеша, буферов на ECP и т.д.
28 авг 17, 15:35    [20754035]     Ответить | Цитировать Сообщить модератору
 Re: Write Image Journaling  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 708
DAiMor,
Спасибо.
Вот у меня ситуация, увеличиваешь размер ОЗУ на виртуалке, отдаешь больше под буфер глобалов и растет размер файла cache.wij. При этом он стал на 12 ГБ и не уменьшается, даже если нет активной работы, даже если перезапускаешь Каше и сразу после перезапуска тоже нет активной работы, размер все равно 12 ГБ. Вот я и засомневался, а хорошо ли это? И как такой размер в дальнейшем используется? Боюсь, что менее чем на треть, но почему он не уменьшается после перезапусков?
Думаю, как же лучше сбалансировать все это...
В каше очень много всяческих метрик, но нигде не нахожу внятного описания, как пользоваться этими метриками, какие делать для себя выводы... Может и была где информация о том, как руководствоваться метриками Каше, какие строить дальнейшие планы административных работ, опираясь на предоставленные системой метрики - но где то пропустил эту информацию...
Много "красных и зеленых лампочек-сигнализаторов" большой пользы не приносит, если не понимаешь о чем они предупреждают и сигнализируют...
Я понимаю, что "крутые волки Интерсистемс" знают и представляют, что нужно делать опираясь на метрики Каше, иначе не было бы таких крутых сравнительных тестов производительности Каше! Но не понимаю, почему такие важные методические материалы не предоставляются широкому кругу пользователей, особенно в нормальном, "армейском" изложении... типа "настольное руководство для сержантского состава".
28 авг 17, 16:34    [20754222]     Ответить | Цитировать Сообщить модератору
 Re: Write Image Journaling  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2358
Наверно потому, что не просто описать как следить за всеми. Обычно за этими метриками начинают следить, когда возникают проблемы, падения сервера либо просто проблемы с производительностью по разным причинам, от обычного роста нагрузки или при внешних факторах (железо, ос).

Дело в том что при разных проблемах стратегии совершенно разные, и сводятся они в анализе многих показателей сразу и за определенный интервал, чтобы увидеть цифры в движении. Для этого они обычно просят запускать pButtons. Но если посмотреть на статьи на DC, то можно понять что даже разные сотрудники теподдержки пользуются своими вариантами анализа этих логов, и они выкладывают, то как они это делают.
InterSystems Data Platforms and performance – Part 2

Visualizing the data jungle -- Part I. Let's make a graph
И не только InterSystems
GUI на Grafana для mgstat — утилиты мониторинга системы на InterSystems Caché, Ensemble или HealthShare
28 авг 17, 17:08    [20754332]     Ответить | Цитировать Сообщить модератору
 Re: Write Image Journaling  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1415
AlexKB,

добавлю пару коп.

Размер cache.wij ограничен размером кэша глобалов, хотя обычно cache.wij в несколько раз меньше. Так что его рост по определению ограничен.

Такие объёмы не должны быть проблемой для любого сервера, а если являются, то вам грозят серьёзные неприятности: остановка журнала, невозможность расширить БД и т.д.

Но если вдруг захотелось поэкспериментировать... остановите Cache штатным образом (чистая остановка здесь крайне важна!) и просто удалите этот файл. Он будет заново создан при следующем старте. Но будьте готовы к тому, что он постепенно вырастет опять до примерно того же размера, поэтому смысла в подобных действиях обычно нет, да и поставщик СУБД их не рекомендует.

По поводу нагрузки, которую создаёт запись в WIJ. На первый взгляд, она велика: всё, что пишется в БД, пишется сначала в WIJ. Но надо понимать, что запись в WIJ - последовательная, большими блоками (по 256KB), т.е. практически идеальный режим для любого, даже дешёвого, контроллера и диска. Это совсем не то же самое, что запись случайных 8KB блоков БД. Не случайно ISC не предъявляет особых требований к быстродействию WIJ. Недавно видел профиль нагрузки, когда 40MB улетало в WIJ за секунду (фаза 5 демона записи), а потом 10-15 секунд писалось в БД (фаза 8).

Разделять различные виды нагрузки, конечно, стоит, но давайте вспомним, когда спасает WIJ:
- при лёгком сбое, когда сервер (вдруг!) перезагрузился
- при восстановлении грязного бэкапа ВМ или LVM
- и это собственно всё...

При серьёзных сбоях ("рухнула БД", "упал сервер",...) WIJ - не помощник. Поэтому я поместил бы WIJ в ту же файловую систему, где установлена Cache: если уцелеют - то вместе. Журналы и прикладные БД, если есть такая возможность, конечно, в отдельные дисковые группы (как пишет DAiMor). Помещая WIJ в какое-то четвёртое место, мы увеличиваем сложность системы, а значит, повышаем её уязвимость. Вспомним о том, что потеряв при сбое WIJ, мы сильно рискуем целостностью БД.

Но в общем, с появлением мощных ЦОД тема разделения нагрузки постепенно уходит в историю. Всё в одном образе ВМ, всё в одной дисковой группе - и ничего, работает, при нагрузке до 160MB в цикле записи WD фазу 5 вообще не видно, фаза 8 занимает 1-2 секунды.
28 авг 17, 19:16    [20754642]     Ответить | Цитировать Сообщить модератору
 Re: Write Image Journaling  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 708
Большое спасибо всем откликнувшимся!
Если есть еще у кого что добавить - не стесняйтесь!!!
7 сен 17, 09:26    [20777324]     Ответить | Цитировать Сообщить модератору
Все форумы / Caché Ответить