ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
14 сообщений из 64, страница 3 из 3
  3  все
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32480143
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
Иванову

По вашему логу видно, что вы нажали Stop до того как пошла основная генерация агрегатов.

С чего вы взяли это. Снова невнимательно читали?


Надо подождать пока MS AS запишет хотя бы 1G, вот такую транзакцию откатить уже слабо. Откатить даже 100M для MS AS не слабо

Вы снова за голословные факты. Где их подверждения? Нет!

просто добавить еще нолик к Fact Table Size

Тесты я продолжил на "нормальном" домашне PC.

Я пошел дальше советов и поставил в свойствах куба Fact Table Size = 400.000.000. (Действительный размер таблицы фактов остался 400.000
В ообщем для здравомыслящего - полный садизм над MS AS.

Интересно дождетесь ли вы даже результатов работы мастера, не говоря о процессировании. Мне лично надоело, я нажал stop на генерации агрегатов.

У меня дизай агрегатов длялся около пары минут, так что мне не надоело.

50%, 1412 аггрегатов, предполагаемый объем 3.139.821,199 MB (надеюсь на этот раз хватит).

Куб был запущен на процессинг.
Приблизительно через час было расчитано около 300 аггрегатов. Мне надоело ждять, я нажал стоп и MS AS сделал "здоровый" откат.

Напомню, что в этот раз тест был на нормальном PC c IDE дисками (см. описание выше по топику)

Так что опять ваши прогнозы не свершились!!! :-)

Чтоже интересно посмотреть, когда же кубик просчитается до упора. Но об этом вы узнаете утром.
...
Рейтинг: 0 / 0
14.04.2004, 03:27
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32480366
Фотография Валек
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валек
Участник
ну как? уже утро
...
Рейтинг: 0 / 0
14.04.2004, 10:11
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32480387
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
И этот кубик отпроцессировался без проблем в приемлимое время

14.04.2004 01:38:56 17846
14.04.2004 01:38:56 17846
14.04.2004 01:38:56 17846 **************************************************************************
14.04.2004 01:38:56 17846 *
14.04.2004 01:38:56 17846 * Processing Database 'IvanovTest'
14.04.2004 01:38:56 17846 * Server: WOLF
14.04.2004 01:38:56 17846 * User: WOLF\Administrator
14.04.2004 01:38:56 17846 * Time Processing started: 14.04.2004 01:38:56
14.04.2004 01:38:56 17846 * Log ID: 17846
14.04.2004 01:38:56 17846 *
14.04.2004 01:38:56 17846 **************************************************************************
14.04.2004 01:38:56 17846
14.04.2004 01:38:56 17846
14.04.2004 01:38:56 17846
14.04.2004 01:38:56 17846 Initiating transaction in Database 'IvanovTest'
14.04.2004 01:38:56 17846 Processing Cube 'Cube0' Start time: 01:38:56
14.04.2004 01:39:00 17846 Initializing Cube 'Cube0'
14.04.2004 01:39:00 17846 Processing Partition 'Cube0' Start time: 01:39:00
14.04.2004 01:39:00 17846 Initializing Partition 'Cube0'
14.04.2004 01:41:20 17846 Partition 'Cube0' Execute : SELECT "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."_DimId", "dbo"."FactTable"."Fact" FROM "dbo"."FactTable"
14.04.2004 01:41:36 17846 Writing data of Partition 'Cube0' (segment 1). Rows processed: 400000
14.04.2004 03:06:57 17846 Writing aggregations and indexes of Partition 'Cube0' (segment 2)
14.04.2004 03:10:20 17846 Writing aggregations and indexes of Partition 'Cube0' (segment 1)
14.04.2004 03:10:45 17846 Completed Processing Partition 'Cube0'. End time: 03:10:45 Duration: 1:31:45 Rows processed: 400000
14.04.2004 03:10:49 17846 Completed Processing Cube 'Cube0'. End time: 03:10:49 Duration: 1:31:53
14.04.2004 03:10:50 17846 Committing transaction in Database 'IvanovTest'
14.04.2004 03:10:55 17846 Committed transaction in Database 'IvanovTest'
...
Рейтинг: 0 / 0
14.04.2004, 10:21
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32480709
Владимир Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Иванов
Участник
2backfire. Я поясню что меня настроживает в вашем тесте. У вас записалось всего 2 сегмента.
14.04.2004 03:06:57 17846 Writing aggregations and indexes of Partition 'Cube0' (segment 2)
14.04.2004 03:10:20 17846 Writing aggregations and indexes of Partition 'Cube0' (segment 1)
Для 1412 агрегатов согласитесь очень мало. Кроме этого, сегменты очень компактные, писались на IDE диск считанные минуты. Мне кажется требование к крешу иметь 1G агрегатов в MOLAP до нажатия Stop не выполнено. Хотелось бы узнать ваше мнение, почему у вас получаются такие компактные сегменты.
Еще интересный вопрос. Вы процессировали на домашней машине. Известно, что измерение MS AS хранит в памяти, а не на диске. Для работы вам нужно 40*100000*4=1,6G RAM. На вашей домашней машине 2-3G памяти?

50%, 1412 аггрегатов, предполагаемый объем 3.139.821,199 MB (надеюсь на этот раз хватит).
Куб был запущен на процессинг.
Приблизительно через час было расчитано около 300 аггрегатов. Мне надоело ждять, я нажал стоп и MS AS сделал "здоровый" откат.
В моем случае 12000 агрегатов и дизайн я оставил делать на ночь, что там говорить о процессировании. :)
Но вопрос не в этом, тут поведение систем у нас различается. В моем случае MS AS "подвис" на откате. В директории куба был примерно 1G. Подождав 4 часа отката, я решил остановить MS AS. Служба не стопится. Затем перегрузка сервера. MS AS сразу после старта грузит сервер на 100% и сам сервер ни на что не отвечает "server busy".
Тем не менее, вам получить сходный эффект не удалось. Возможно есть зависимость от каких либо других факторов.
Мне кажется надо выполнить тест еще кому-то. Сейчас не ясно упех или неуспех теста связан с тестирующим, методикой теста, софтом, хардом и т.д.

Тем не менее, мне кажется само обсуждение было интересным. Резюмирую его.
1) Как показали тесты MS AS способен, по крайней мере при некоторых условиях, создавать очень мощные агрегации. Если тест Владимира корректен, то MS AS способен сделать агрегацию для 400 млн. фактов, при этом плотность агрегатов 50% и куб управляет 40 измерениями на 100 тыс. членов. При этом измерения плотно агрегированы. Мне кажется, что подобного результата не достить более ни на каком OLAP-сервере.
2) Мы разобрали особенности агрегаций и управление их плотностью. Обратите внимание, что Fact Table Size влияет сильнее, чем процентовка агрегата. MS AS не пересчитывает эту величину динамически, поэтому запросто можно получить неправильные агрегации.
3) Рассмотрели Lazy Aggregation, как средство снятия пиковых нагрузок на MS AS.

Я думаю Владимиру нужно выложить на Web пример OLAP-базы и скриптов TSQL. Думаю многим будет интересно.
...
Рейтинг: 0 / 0
14.04.2004, 12:00
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32480848
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
Я думаю Владимиру нужно выложить на Web пример OLAP-базы и скриптов TSQL. Думаю многим будет интересно

A vam slabo samim sdelat. U menya sozdaetsya takoe vpechatlenie, chto vi u sebya po zatronutoi teme 0,0 eksperimentov provodili za poslednie 4 dnya, a v moih logah vse kakie to "neveroyatnosti" viiskivaete.
Chego zhe tut iz'yasnyatsya - u menya vse rabotaet - priezhaite - ya vam s udovelstviem pokazhu :-).

SQL-Scripti ya uzhe vilozhil, tam est pravda malyusenkaya oshibka pri napolnenii tablici factov (budet vstavleno ne 400.000, a 399.988 zapisei v tablicu faktov - nu da ... s nim - eto ne vazhno).

A v OLAP - neuzheli komu to len 40 raz copy-paste sdelat?
...
Рейтинг: 0 / 0
14.04.2004, 12:53
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32480965
Владимир Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Иванов
Участник
2backfire. Владимир вы как истнинный мужчина человек миссии. Такое впечатление, что у вас миссия найти что я делаю не так. :)

Я предлагаю выложить ваше решение потому что:
1) Оно готово и работает, скорее всего безопастно для экспериментов.
2) Незначительные отличия в дизайне наших тестов приводят к очень разным результатам. Например различие в уровнях измерений дают очень разные показатели агрегации. Поэтому лучше иметь пример OLAP-базы.
3) Мое решение в отличие от вашего неполное. Я его принципиально не процессирую и оно потенциально опасно, т.к. есть вероятность отличная от нуля получить мой эффект.

Потом если оставить флейм, вы не ответили на вопросы, которые меня озадачили. Как вы смогли положить 1414 агрегатов в 2 сегмента, как они записались за 8 минут на диск, и как в памяти вашей домашней машины поместились измерения на 1,6G + агрегация для сегментов до записи на HDD. Я не думаю что вы занимались подтассовкой теста и всему есть свое объяснение. Хотелось бы оставить флейм и найти ответы на данные вопросы, т.к. из них могу получится интересные выводы для оптимизации
MS AS. А значит возились с тестами не зря
...
Рейтинг: 0 / 0
14.04.2004, 13:41
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32481239
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
Я предлагаю выложить ваше решение потому что:
1) Оно готово и работает, скорее всего безопастно для экспериментов.

Kto ne gotov na zhertvi radi istnii - istinu ne poznaet.
Chto, slabo ustanovkoi servera pozhertvovat?

2) Незначительные отличия в дизайне наших тестов приводят к очень разным результатам. Например различие в уровнях измерений дают очень разные показатели агрегации. Поэтому лучше иметь пример OLAP-базы.

Teper vi mozhete poslat mne vash primer, a ya skazhu vam chto u menya po-drugomu :-)

3) Мое решение в отличие от вашего неполное. Я его принципиально не процессирую и оно потенциально опасно, т.к. есть вероятность отличная от нуля получить мой эффект.

Esli u vas est polnii backup mashini ili obraz diska - vosstanovlenie delo 15-ti minut.

Как вы смогли положить 1414 агрегатов в 2 сегмента, как они записались за 8 минут на диск, и как в памяти вашей домашней машины поместились измерения на 1,6G + агрегация для сегментов до записи на HDD.

Ya dumayu cto na eti voprosi mogut tochnee otvetit otci MS AS.

Я не думаю что вы занимались подтассовкой теста и всему есть свое объяснение.

Spasibo hot na etom.
...
Рейтинг: 0 / 0
14.04.2004, 15:16
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32482187
Mosha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mosha
Гость
С опозданием присоединяюсь к этому thread, но попробую ответить на вопросы которые были мне заданы.

Во первых, я полностью согласен с Владимиром Ивановым по поводу распространенной ошибки переагрегаций, которая выражается в установке 100% или даже 50% в Design Aggregation. AS тоже пытается с этим бороться, например известно, что даже если установлено 100%, то все равно AS не будет делать 100%, а все равно отфильтрует аггрегации которые он считает не окажутся полезными.
Насчет того как сделан доступ к системе I/O, то SQL Server действительно пользуется низкоуровневыми библиотеками. AS такими библиотеками не пользуется а работает на уровне CreateFile/ReadFile/WriteFile/MemoryMapped Files. Транзакционная семантика (в данном случае из свойств ACID мы рассматриваем C & D - Consistency & Durability) обеспечивается следующим образом:

1. Для writeback (both cell and dimension) за счет того что запись делается в SQL базы данных.
2. Для processing (то о чем собственно был вопрос) за счет транзакционный свойств файловой системы. Т.е. на NTFS это гарантировано, а на FAT нет. Возможно Владимир наблюдал именно сбой FAT ?
К сожалению у меня не было времени повторить эксперимент, но результаты экспериментов backfire обнадеживают.

И наконец последний вопрос, каким образом у backfire все уложилось в 2 сегмента. Мое предположение, что возможно гранулярность данных в fact table была ниже чем определено в кубе.

Моша

----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights
...
Рейтинг: 0 / 0
15.04.2004, 09:49
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32482244
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
Моше

В таблице фактов "фактически" :-) было 400000 записей.
А в агрегации были рассчитаны исходя из того что в таблице фактов 400000000
записей.
Т.е. MS AS был сознательно "обманут" при расчете аггрегаций.

Иванову.

Как я и предполагал - ваша теория "низкоуровнего доступа" - всего лишь пшик.
И оправдывать этой теорией было нечего.

Моша, если ваш почтовый ящик выдержит 1Gb :-) то я вам могу прислать процессированный кубик дабы у вас не осталось никаких сомнений. (Пока я его не грохнул - а то он сечас только место занимает)
...
Рейтинг: 0 / 0
15.04.2004, 10:22
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32482253
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
Возможно Владимир наблюдал именно сбой FAT ?

Ну если это так было, то о чем вообще речь.

А убитый репозитарий наводит на мысль что он не был мигрирован на SQL-Server а оставался в *.mdb формате - таком же надежном как FAT.

Золотое правило: Миграция репозитория на SQL-Server - первое, что надо сделать после установки MS AS.
...
Рейтинг: 0 / 0
15.04.2004, 10:28
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32483147
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
Esche odno interesnoe nablyudenie,

esli postavit v svoistvah MS AS - Developer Edition
na Windows Server 2003 Standard na mashine s 4Gb pamyati.

"Memory Conservation Thresold" 2048 MB - poluchaem out of memory Error pro processinge "tyazhelih" kubov. Prichem oshibka voznikaet ustoichivo postoyanno na tom zhe meste.

Krutim "Memory Conservation Thresold" vniz naprimer do 1400Mb - i vse OK. Kubik processitsya ustoichivo i bez oshivok.


Moe podozrenie, chto MS AS ne sledit strogo za soboi i stremitsya poluchit pamyati "nemnogo" bolshe chem razresheno i kak sledstvie "poluchaet po golove" ot OS - Out of Memory.

Vse eto moi lichnie spekulyacii, no hotelos bi uslishat mnenie drugih, osobenno specov iz Krasnoi Luni :-)
...
Рейтинг: 0 / 0
15.04.2004, 16:47
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32483411
Владимир Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Иванов
Участник
2Моша. Нет, использовался NTFS. Я не указал что из серверов был поврежден настолько, что пришлось переставить ОС. Админ мне высказал теорию, что проблема была именно в откате транзакции NTFS, т.е. после перегрузки сервера ОС продолжила откат транзации, но не могла его завершить. В результате сервер все время вис после перегрузки.

К слову, стало понятно почему 2 сегмента. MS AS ожидал 400 млн. фактов и приготовился делать 200 сегментов, пришло в 100 раз меньше. Все ясно.
Остались открытые вопросы:
1) Почему они эти 2 крупных сегмента так быстро писались на диск? Сработала MOLAP-компрессия MS AS?
2) Почему 1,6G измрений поместились в памяти мальнькой машины? Тут ответа нет, их надо точно держать в памяти, т.к. при использовании Optimize Schema восстановление связей требует их наличия.

2backfire. Насчет репозитария вы правы. Однако перед тестами мы часто переливаем сервер так как его заливал клиент. Обратите внимание, что несмотря на то что MS AS не рулит дисками, мои теории по тому как помочь MS AS писать на диск в том числе Lazy Aggreration и правильная плоность агрегации реально помогает людям.
...
Рейтинг: 0 / 0
15.04.2004, 18:48
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32483460
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
Ivanovu.

Остались открытые вопросы:
1) Почему они эти 2 крупных сегмента так быстро писались на диск? Сработала MOLAP-компрессия MS AS?

Koncechno srabotalya, a vi dumali chto on snachala nekompressirovanno pishet a potom perepisivaet kompressirovano?

2) Почему 1,6G измрений поместились в памяти мальнькой машины? Тут ответа нет, их надо точно держать в памяти, т.к. при использовании Optimize Schema восстановление связей требует их наличия.

Vladimir, v sgenerili 40 Izmerenii v svoei baze?
Posmotreli, skolko pamyati MS AS kushaet?

Pravilno, - ne posmotreli!!!

Tak sdelaete zhe chto ni bud svoimi rukami i ubedites v prirode veschei sami.

"... ne poverit poka svoimi rukami ne pomacaet".
...
Рейтинг: 0 / 0
15.04.2004, 19:36
| Ответить | Цитировать | Написать  
И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
    #32483488
Владимир Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Иванов
Участник
То что MS AS скушал меньше 1,6G это факт. Однако это противоречит заявлениям MS о распеределении памяти под измерения. Или какой-нить SP3 уже добавил кусочек Юкона, где измерения уже не нужно полностью хранить в памяти?
...
Рейтинг: 0 / 0
15.04.2004, 20:16
| Ответить | Цитировать | Написать  
14 сообщений из 64, страница 3 из 3
  3  все
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / И опять про распределение памяти MS AS и SQL... никак не получается..;-) Может кто сталкивался...
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]