Глюк Cache с оперативкой или это норма? / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Глюк Cache с оперативкой или это норма?

42 сообщений из 42, показаны все 2 страниц

все

Глюк Cache с оперативкой или это норма?

#39507252

О-О-О

Гость

Работаю с Таблицей (уже не называю База Данных).
Копирую данные в оперативку. Количество столбцов более 10 и это принципиально.

Еcть значение aaa(1.1) и aaa(1.10). Если задать 1.1, а затем задать 1.10 и считать данные из 1.1, то Каше выдаст нам данные из памяти со значением 1.10

Пример кода и результатов ниже.

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

BRENT2016>Set aaa(1.1)="aaa001"
 
BRENT2016>Set aaa(1.2)=2
 
BRENT2016>Set aaa(1.10)="No"
 
BRENT2016>Set aaa(1.20)="No"
 
BRENT2016>w aaa(1.1)
No
BRENT2016>w aaa(1.2)
No

...

Рейтинг:

0 / 0

18.08.2017, 07:48

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507254

О-О-О

Гость

Если же сделать по другому, то результаты получаются нормальные/адекватные
Назначив не 1.1, а 1.001 и не 1.2, а 1.002

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

BRENT2016>set aaa(1.001)="aaa1"
 
BRENT2016>Set aaa(1.002)="Также есть"
 
BRENT2016>Set aaa(1.1)="No111"
 
BRENT2016>Set aaa(1.2)="No222"
 
BRENT2016>w aaa(1.1)
No111
BRENT2016>w aaa(1.001)
aaa1

Вопрос. С чем это может быть связано и почему происходит именно так.
Ошибка обнаружилась совершенно случайно, т.к. в первом поле у меня всегда стоит ДАТА и только из-за этого обнаружилась проблема.
.

...

Рейтинг:

0 / 0

18.08.2017, 07:51

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507256

О-О-О

Гость

Да и еще.
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")

...

Рейтинг:

0 / 0

18.08.2017, 07:55

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507261

krvsa

Участник

Откуда: г Волжский

Сообщения: 13 817

Рейтинг: 1 / 0

О-О-ОЕcть значение aaa(1.1) и aaa(1.10). Если задать 1.1, а затем задать 1.10 и считать данные из 1.1, то Каше выдаст нам данные из памяти со значением 1.10

Пример кода и результатов ниже.

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

BRENT2016>Set aaa(1.1)="aaa001"
 
BRENT2016>Set aaa(1.2)=2
 
BRENT2016>Set aaa(1.10)="No"
 
BRENT2016>Set aaa(1.20)="No"
 
BRENT2016>w aaa(1.1)
No
BRENT2016>w aaa(1.2)
No

Так и должно быть.
Ибо

Код: html

1.
2.

TMP>w 1.1000                                                                   
1.1

...

Рейтинг:

0 / 0

18.08.2017, 08:21

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507262

krvsa

Участник

Откуда: г Волжский

Сообщения: 13 817

Рейтинг: 1 / 0

О-О-ОДа и еще.
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")
Тут кагбэ нужно правильно "давать".

Код: javascript

1.
2.

s aaa("1.Data")=""
s aaa(1_".Data")=""

...

Рейтинг:

0 / 0

18.08.2017, 08:23

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507264

DAiMor

Участник

Откуда: Volzhsky -> Moscow -> CZ, Brno -> Moscow

Сообщения: 2 917

Рейтинг: 0 / 0

О-О-О,

Ваша "проблема" заключается в том, что вы значения пишете ч числовом представлении. И вы должны знать, что 1.1 и 1.10 это одно и то же число. И поэтому предыдущее значение терялось. А вот если бы вы взяли значение в кавычки, то оно бы стало текстом, и тогда было бы уже все равно.

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

USER>set a(1.1)=""

USER>set a(1.10)=""

USER>set a(1.100)=""

USER>set a("1.100")=""

USER>set a("1.10")=""

USER>zw a
a(1.1)=""
a("1.10")=""
a("1.100")=""

привести числовое значение к текстовому можно просто прибавив его с пустой строке, но нужно понимать ""_1.20 даст "1.2" а не "1.20"

О-О-ОПочему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")
А это вообще как вы себе представляете?
почему не делать так как все?
aaa("1.Data")

...

Рейтинг:

0 / 0

18.08.2017, 08:24

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507265

krvsa

Участник

Откуда: г Волжский

Сообщения: 13 817

Рейтинг: 1 / 0

О-О-ОВопрос. С чем это может быть связано и почему происходит именно так.
В первом варианте (1.20) Каше "не хранит" "концевые" нули, т.к. они никому не нужны. И я х/з какие ЯП вообще такое хранят, всегда "концевые" нули "исчезали".

По второму вопросу...
Что вообще такое

Код: javascript

1.Data

или

Код: javascript

1."Data"

т.е. как ты собирался интерпретировать этот синтаксис?

...

Рейтинг:

0 / 0

18.08.2017, 08:27

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507283

О-О-О

Гость

С последним вопросом ответ нашулся.

Нужно было просто делать

Код: sql

Set aaa(1,"Data")=65000

Просто нужна была ЗАПЯТАЯ, а не ТОЧКА!

...

Рейтинг:

0 / 0

18.08.2017, 09:04

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507284

krvsa

Участник

Откуда: г Волжский

Сообщения: 13 817

Рейтинг: 1 / 0

О-О-ОС последним вопросом ответ нашулся.
Алилуя, брат! (с)

...

Рейтинг:

0 / 0

18.08.2017, 09:05

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507294

О-О-О

Гость

Немного статистики. Может кому пригодится для оптимизации.
Имеется таблица на 395000 строк. В таблице 154 столбца.

Если данные копировать в оперативку как
EndID - это последняя запись в таблице (394000)

Код: sql

1.
2.
3.
4.
5.
6.

For i=1:1:EndID
{
   Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
      // Где BDAnaliz Это БД откуда будут копироваться данные
   Set aaa(i)=aaaNew
}

c

Вариант №2

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

For i=1:1:EndID
{
   Set Nr=0
   Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
      // Где BDAnaliz Это БД откуда будут копироваться данные
   For em="Data","Vrema",    и т.д . (все 154 столбца)
   {
       Set Nr=Nr+1
       Set zma1="aaa("_i_"."_Nr_")=aaaNew."_em,@zma1
    }
}

Такой вариант занимает ВСЕГО 114 секунд НО остаётся ВСЕГО 2.027 Гб из 9.863 Gb выделенных. Самый быстрый вариант, но самый затратный по оперативке. Вариант получается нечитабельным, т.к. нужно держать в памяти что означает номер с реальными полем из таблицы.

Вариант №3

...

Рейтинг:

0 / 0

18.08.2017, 09:23

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507300

О-О-О

Гость

Вариант №3

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.

For i=1:1:EndID
{
   Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
   For em="Data","Vrema",    и т.д . (все 154 столбца)
   {
       Set zma1="aaa("_i_"."_""""_em_""""_")=aaaNew."_em,@zma1
    }
}

Такой вариант занимает 144.40 секунды и остаётся 4.028 Гб из 9.863 Gb выделенных. Средний вариант, как по быстроте так и по занимаемой Оперативке. Зато полностью читабелен, т.к. имена данных аналогичные именам данных из таблицы.
Время с удалением данных из оперативки составило 150.39 сек.

БОЛЬШАЯ ПРОБЛЕМА ВАРИАНТА №1 ЭТО УДАЛЕНИЕ ФАЙЛА ИЗ ОПЕРАТИВКИ.
Расчет/копирование занял 233.17 секунды (вот прямо сейчас), а с удалением данных из оперативки занял уже 356.48 сек!!! То есть очень долгий по исполнению (по полному циклу исполнения кода).

Таких проблем с вариантом №2 и вариантом №3 нет.

...

Рейтинг:

0 / 0

18.08.2017, 09:39

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507302

О-О-О

Гость

Вариант №1
For i=1:1:EndID
{
Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
// Где BDAnaliz Это БД откуда будут копироваться данные
Set aaa(i)=aaaNew
}

Время исполнения составило 233.17 сек. Доступно 7.324 Гб из 9.863 Гб. Время с удалением данных из оперативки (для дальнейшего выполнения кода уже составило) 356.48 сек. Но этот вариант читабелен, т.к позволяет напрямую обращяться к данным в формате
aaa(1).Data
И данные представлены в такой же структуре, что и таблица. То есть aaa(1).Data
aaa (345).Vrema все также как и в обычной таблице на жестком диске.

Очень читабельная и удобна для работы, но жутко долго загружается и столько же удаляется из оперативки!
.

...

Рейтинг:

0 / 0

18.08.2017, 09:46

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507306

О-О-О

Гость

Пардон, в варианте №3 закрылась ошибка
вместо

Код: sql

Set zma1="aaa("_i_"."_""""_em_""""_")=aaaNew."_em,@zma1

нужно писать

Код: sql

Set zma1="aaa("_i_","_""""_em_""""_")=aaaNew."_em,@zma1

то есть не точка, а запятая!

...

Рейтинг:

0 / 0

18.08.2017, 09:50

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507308

Глюк_Каше

Гость

О-О-О,
А это прямо необходимость такая иметь одновременно открытых в памяти 395000 объектов (все открываются и не закрываются ни разу !) ?

...

Рейтинг:

0 / 0

18.08.2017, 09:53

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507311

О-О-О

Гость

Глюк_Каше,

Для кого то да.

Это комбинаторика, перебор вариантов.
Если это делать с SSD диска, то уходит около 60-75 минут.
Если этот же код делать с данными, скопированными в оперативку, то уходит около 10 минут.

...

Рейтинг:

0 / 0

18.08.2017, 09:59

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507312

krvsa

Участник

Откуда: г Волжский

Сообщения: 13 817

Рейтинг: 1 / 0

А меня всегда настораживали таблицы, где
О-О-ОВ таблице 154 столбца.

И прям все 154 параметра заполнены у каждой строки?

...

Рейтинг:

0 / 0

18.08.2017, 09:59

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507315

krvsa

Участник

Откуда: г Волжский

Сообщения: 13 817

Рейтинг: 1 / 0

О-О-ОЭто комбинаторика, перебор вариантов.
Не стоит забывать, что Каше это первым делом NoSQL и некоторые энергоемкие задачи удобнее решать именно в этом направлении, а не табличном. ;)

Про саму задачку ты ведь нам не рассказал...

...

Рейтинг:

0 / 0

18.08.2017, 10:02

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507319

О-О-О

Гость

да, и все 154 параметра заполнены в каждой строке (реально заполнены)!.

...

Рейтинг:

0 / 0

18.08.2017, 10:03

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507325

О-О-О

Гость

Наше дело поделиться, кому то может и пригодится.
Я сижу на Каше, потому что нет задач, которые нельзя на нём сделать да и скорость его в моём понимании впечатляет.

Да и поздно уже на что то другое переходить.

...

Рейтинг:

0 / 0

18.08.2017, 10:05

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507326

krvsa

Участник

Откуда: г Волжский

Сообщения: 13 817

Рейтинг: 1 / 0

О-О-Ода, и все 154 параметра заполнены в каждой строке (реально заполнены)!.
Все равно остается подозрение, что ты свернул не туда...
Но без знания проблемы ничего больше не скажешь. Ну не должны данные так перелопачиваться. Тут что-то не так.

...

Рейтинг:

0 / 0

18.08.2017, 10:05

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507330

krvsa

Участник

Откуда: г Волжский

Сообщения: 13 817

Рейтинг: 1 / 0

О-О-О , наша практика работы с ЦОДом показала, что на мощных серверах хорошим подспорьем является "многоджобная" технология обработки данных (это наш термин).

Т.е. если разбить "линейную" обработку данных на "куски" и все эти куски обработать отдельным, дочерним процессом, то время обработки практически "делится" на количество этих дочерних джобов. ;)

А вот по каким критериям делать те "куски", это уже решается индивидуально по каждой задаче/проблеме...

...

Рейтинг:

0 / 0

18.08.2017, 10:10

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507332

Глюк_Каше

Гость

О-О-О,
Тогда попробуйте, как подсказал krvsa, использовать глобалы напрямую (минуя объектный доступ и SQL). Просто перед именем пишете ^ и все. Например:
set ^tbx( 1, "Vrem" ) = 1547.
Первый индекс от 1 до 395000, а второй - хоть текстовый по имени колонки, хоть числовой (если время, допустим, всегда считать полем № 2, то вместо "Vrem" пишем - 2). А вообще-то, krvsa прав - странная обработка данных. Но без озвученных условий Вам трудно помочь.

...

Рейтинг:

0 / 0

18.08.2017, 10:14

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507345

О-О-О

Гость

Глюк_Каше,
Я просто поделился. Помощи не просил.
Что касается много потоковости - наверное так будет быстрее, но мне удобнее так. Просто никогда не знаешь, какие данные потребуются. К тому же они служат ТОЛЬКО ДЛЯ АНАЛИЗА данных по истории (выработка стратегии). Сами торги не идут с таким перелопачиванием данных. Там все проще и быстрее.

...

Рейтинг:

0 / 0

18.08.2017, 10:37

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507346

О-О-О

Гость

Глюк_КашеО-О-О,
Тогда попробуйте, как подсказал krvsa, использовать глобалы напрямую (минуя объектный доступ и SQL). Просто перед именем пишете ^ и все. Например:
set ^tbx( 1, "Vrem" ) = 1547.
Первый индекс от 1 до 395000, а второй - хоть текстовый по имени колонки, хоть числовой (если время, допустим, всегда считать полем № 2, то вместо "Vrem" пишем - 2). А вообще-то, krvsa прав - странная обработка данных. Но без озвученных условий Вам трудно помочь.

Вот как раз таким способом анализ и будет длится 60-75 минут.

...

Рейтинг:

0 / 0

18.08.2017, 10:38

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507359

DAiMor

Участник

Откуда: Volzhsky -> Moscow -> CZ, Brno -> Moscow

Сообщения: 2 917

Рейтинг: 0 / 0

О-О-ОЯ просто поделился. Помощи не просил.Зря вы так, для этого форумы и нужны по сути. Никогда нельзя быть уверенными что выбрали единственно верную стратегию. Когда процессы занимают продолжительное время все есть варианты которые могут его ускорить. И будут появлятся новые, при появлении например новых видов оборудования.
Вы например решили свою задачу таким способом, другие решали другим способом. Варианты можно сравнивать и выбирать лучшую стратегию.

...

Рейтинг:

0 / 0

18.08.2017, 10:49

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507361

Alexey Maslov

Участник

Откуда: СПб

Сообщения: 1 668

Рейтинг: 0 / 0

Глюк_КашеА это прямо необходимость такая иметь одновременно открытых в памяти 395000 объектов (все открываются и не закрываются ни разу !) ?О-О-О, вы хоть и ответили "да", но не объяснили, почему. Возможно, вы просто не знали, что открытые объекты дорого стоят, дороже, чем те же данные, уложенные в локальный массив, да и он, бывает, того...

Вы хоть и не просите помощи, а "делитесь", но большинству из нас малоинтересны такие результаты, так как мы знаем, как извлечь из Cache максимум, "если её правильно готовить".

...

Рейтинг:

0 / 0

18.08.2017, 10:50

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507365

DAiMor

Участник

Откуда: Volzhsky -> Moscow -> CZ, Brno -> Moscow

Сообщения: 2 917

Рейтинг: 0 / 0

Я бы кстати предложил посмотреть на варианты, хранения базы целиком в памяти, конечно зависит от объема базы. Но возможно и достаточно было бы ограничится буфером глобалов. Задача оптимизации тут конечно вполне себе интересная, и решаемая, в таких случаях можно производительность на порядки улучшать при применении разных средств. И конечно тут уже зависит от ограничений, возможности горизонтального и вертикального массштабирования.

Для простоты, вы к примеру тратите сначала довольно много времени на загрузку в локальную память данных из базы, далее работаете с этими данными получаете некий результат. Уверен, что есть возможность отказаться от загрузки в локальную память, и можно работать сразу с базой, и при этом потратить меньше времени на весь процесс. Сам процесс анализа конечно может занять больше времени чем при работе с данными в локальной памяти, но если не тратить время на загрузку, это может оказаться суммарно быстрее.

Многозадачность, очень хороший вариант оптимизации. При том, что в некоторых случаях можно задействовать и дополнительные машины для этого.

...

Рейтинг:

0 / 0

18.08.2017, 10:57

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507406

П.С.М.

Участник

Откуда: Из СССР

Сообщения: 449

Рейтинг: 0 / 0

Хм, а ТС'у уже давали совет, прочитать хоть какую-нибудь книжку по синтаксису используемого им языка? Или еще нет?

Дабы не возникали вопросы вида:
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")

...

Рейтинг:

0 / 0

18.08.2017, 11:50

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507435

Ptn

Участник

Сообщения: 939

Рейтинг: 0 / 0

Почитал, посмотрел пример "кода", рассуждения об оперативке ... мдя....

Спасибо что проинформировали нас.

О-О-ОМожет кому пригодится для оптимизации.

На кой то черт копировать таблицу с диска в локальные переменные непонятной структуры, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс, и не зная что локальные массивы после примерно 1000узлов начинают уступать глобалас, фулсканом, через открытие объекта когда можно написать ОДИН MERGE ... Нет, не пригодится.

...

Рейтинг:

0 / 0

18.08.2017, 12:05

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507446

О-О-О

Гость

DAiMorО-О-ОЯ просто поделился. Помощи не просил.Зря вы так, для этого форумы и нужны по сути. Никогда нельзя быть уверенными что выбрали единственно верную стратегию. Когда процессы занимают продолжительное время все есть варианты которые могут его ускорить. И будут появлятся новые, при появлении например новых видов оборудования.
Вы например решили свою задачу таким способом, другие решали другим способом. Варианты можно сравнивать и выбирать лучшую стратегию.

Я прощу прощения, если кого обидел.
Хотел в конце добавить смайлик, но он не добавился.

...

Рейтинг:

0 / 0

18.08.2017, 12:10

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507463

О-О-О

Гость

DAiMorЯ бы кстати предложил посмотреть на варианты, хранения базы целиком в памяти, конечно зависит от объема базы. Но возможно и достаточно было бы ограничится буфером глобалов. Задача оптимизации тут конечно вполне себе интересная, и решаемая, в таких случаях можно производительность на порядки улучшать при применении разных средств. И конечно тут уже зависит от ограничений, возможности горизонтального и вертикального массштабирования.

Для простоты, вы к примеру тратите сначала довольно много времени на загрузку в локальную память данных из базы, далее работаете с этими данными получаете некий результат. Уверен, что есть возможность отказаться от загрузки в локальную память, и можно работать сразу с базой, и при этом потратить меньше времени на весь процесс. Сам процесс анализа конечно может занять больше времени чем при работе с данными в локальной памяти, но если не тратить время на загрузку, это может оказаться суммарно быстрее.

Многозадачность, очень хороший вариант оптимизации. При том, что в некоторых случаях можно задействовать и дополнительные машины для этого.

Давайте посчитаем.
395000 строк и 154 столбца. В сумме около 60,5 млн записей.
Каждая запись участвует в перекрестном сравнении как минимум 3-4 раза и это навскидку. Кроме того эти записи сравниваются между собою. Я прикидывал. Каждая ячейка из этого массива участвует в коде от 12 до 24 раз.
Если 60 млн записей перемножить на 20 запросов получим 1 мрд обращений к жесткому диску. Выборка с SSD диска около 7500 (40Мб с 4кб блоками запросов в сек (смешанный поток). Итого получаем 1 млд/10000~100'000 сек. Даже если 10'000 это уже 3 часа.
Я помню В своё время делал код по анализу с жесткого диска (ССД). Так тогда он потратил 3 часа и проанализировал всего 8%.
С тер пор я пытаюсь перетащить данные в оперативку. Скорость оперативки 35Гбайт сек. То есть даже сравнивать бесполезно.

Писать же код в котором нужно что то анализировать (часть данных загрузить и анализировать их между собою), а что то не нужно, это ОЧЕНЬ усложняет код и постоянно нужно держать в голове, какие сейчас части проанализированы. Получается путаница и никакого удовольствия от программирования. Если есть ресурс по железу, а он и не такой уж и большой требуется, то зачем создавать лишние проблемы?
.

...

Рейтинг:

0 / 0

18.08.2017, 12:23

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507465

О-О-О

Гость

PtnПочитал, посмотрел пример "кода", рассуждения об оперативке ... мдя....

Спасибо что проинформировали нас.

О-О-ОМожет кому пригодится для оптимизации.

На кой то черт копировать таблицу с диска в локальные переменные непонятной структуры, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс, и не зная что локальные массивы после примерно 1000узлов начинают уступать глобалас, фулсканом, через открытие объекта когда можно написать ОДИН MERGE ... Нет, не пригодится.

MERGE скопировать то можно, а вот вытащить из него из оперативки ничего не получается. Как кусок камня. Он вроде бы и есть, а толку для анализа ноль.

...

Рейтинг:

0 / 0

18.08.2017, 12:25

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507472

О-О-О

Гость

Ptn, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс,

Это легко настраивается в настройках Каше.
Да, по умолчанию там стоит около 256 мб и еще там стоит кучу узких месть
К примеру вы не сможите ОДНОВРЕМЕННО запустить 30 фоновых процессов, так как Каше просто ляжет. и таких мелочей много. НО!!!

Если полазить по настройкам Каше, то ОЧЕНЬ можно СУЩЕСТВЕННО увеличить быстродействие и отзывчивость системы. То есть каше можно настроить под экономичный, под стандартные и под высоконагруженный проект.
Я же говорю, что Каше очень хорошая БД, она эластичная, и легко выполняет все нужды для программирования.

...

Рейтинг:

0 / 0

18.08.2017, 12:31

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507476

О-О-О

Гость

Под Одновременно имеется ввиду, что одновременно запускается команда Job Для 30 процессов, а не фоновая работа 30 процессов.

...

Рейтинг:

0 / 0

18.08.2017, 12:33

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507505

DAiMor

Участник

Откуда: Volzhsky -> Moscow -> CZ, Brno -> Moscow

Сообщения: 2 917

Рейтинг: 0 / 0

О-О-О,

о каком постоянном чтении с диска речь, почитайте про буфер глобалов

...

Рейтинг:

0 / 0

18.08.2017, 13:09

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507515

Глюк_Каше

Гость

О-О-О,
авторЕсли 60 млн записей перемножить на 20 запросов получим 1 мрд обращений к жесткому диску. Начиная с этого места Ваш расчет никуда не годится. Обращаясь к СУБД данные проходят кэш диска "как железного" устройства, кэш операционной системы, где буферизируются операции ввода вывода, кэш самой СУБД - данные, что лежат в памяти. Судя по описанию, Вам один раз нужно будет прочесть все данные в ОЗУ (то есть они туда точно попадут). Но физических чтений с диска будет намного меньше...

...

Рейтинг:

0 / 0

18.08.2017, 13:35

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507627

О-О-О

Гость

Глюк_Каше,

Дабы внести ясность я сделал следующее
Я посчитал сумму одной переменной во всех 395000 строк.
Сперва тупо обращаясь к Таблице (глобалу)

Второй вариант - Сделал то же самое из суммы в памяти ПК.
Этот шаг разделён на две части - первая - копирование данные в память. Вторая часть непосредственно суммирование данных.

Вот что получилось

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.

Считывание данных с SSD. SumMacd=-1003.739   Время=10.979169s Доступно 9863.3 Мб из 986340 возможных
 
  1 из 40 по 10'000.  Доступно RAM: 9715.4
  2 из 40 по 10'000.  Доступно RAM: 9567.6
  3 из 40 по 10'000.  Доступно RAM: 9419.7
  4 из 40 по 10'000.  Доступно RAM: 9271.9
  5 из 40 по 10'000.  Доступно RAM: 9124
  6 из 40 по 10'000.  Доступно RAM: 8976.2
  7 из 40 по 10'000.  Доступно RAM: 8828.3
  8 из 40 по 10'000.  Доступно RAM: 8680.5
  9 из 40 по 10'000.  Доступно RAM: 8532.6
  10 из 40 по 10'000.  Доступно RAM: 8384.8
  11 из 40 по 10'000.  Доступно RAM: 8236.9
  12 из 40 по 10'000.  Доступно RAM: 8089.1
  13 из 40 по 10'000.  Доступно RAM: 7941.3
  14 из 40 по 10'000.  Доступно RAM: 7793.4
  15 из 40 по 10'000.  Доступно RAM: 7645.6
  16 из 40 по 10'000.  Доступно RAM: 7497.7
  17 из 40 по 10'000.  Доступно RAM: 7349.9
  18 из 40 по 10'000.  Доступно RAM: 7202
  19 из 40 по 10'000.  Доступно RAM: 7054.2
  20 из 40 по 10'000.  Доступно RAM: 6906.3
  21 из 40 по 10'000.  Доступно RAM: 6758.5
  22 из 40 по 10'000.  Доступно RAM: 6610.6
  23 из 40 по 10'000.  Доступно RAM: 6462.8
  24 из 40 по 10'000.  Доступно RAM: 6315
  25 из 40 по 10'000.  Доступно RAM: 6167.1
  26 из 40 по 10'000.  Доступно RAM: 6019.3
  27 из 40 по 10'000.  Доступно RAM: 5871.4
  28 из 40 по 10'000.  Доступно RAM: 5723.6
  29 из 40 по 10'000.  Доступно RAM: 5575.7
  30 из 40 по 10'000.  Доступно RAM: 5427.9
  31 из 40 по 10'000.  Доступно RAM: 5280
  32 из 40 по 10'000.  Доступно RAM: 5132.2
  33 из 40 по 10'000.  Доступно RAM: 4984.3
  34 из 40 по 10'000.  Доступно RAM: 4836.5
  35 из 40 по 10'000.  Доступно RAM: 4688.7
  36 из 40 по 10'000.  Доступно RAM: 4540.8
  37 из 40 по 10'000.  Доступно RAM: 4393
  38 из 40 по 10'000.  Доступно RAM: 4245.1
  39 из 40 по 10'000.  Доступно RAM: 4097.3
 Строк=394650  Время=161.117946s Доступно 4028.5 Мб из 986340 возможных
 
 
2) Считывание данных из RAM.  SumMacd=-1003.739   Время=.686559s Доступно 4028.5 Мб из 986340 возможных

С SSD диска время составило 10.98 сек
Из Оперативки 0.69 сек

Код привожу ниже, чтобы не говорили, что код не оптимизирован и избыточен.

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

	
        // Это чтение данных непосредственно из Глобала (с SSD диска)
        Set EndID=$Order(@BDAnalizDDD@(""),-1) 
	Set SumMacd=0
	For i=1:1:EndID
	{
		Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
		Set SumMacd=SumMacd+aaaNew.MAXXX
	}

        // Это чтение данных из Оперативки.
	Set TStart=$ZH
	Set SumMacd=0
	Set em="MACXXX"
	For i=1:1:EndID
	{
		Set zma1="aaaMA=aaa("_i_","_""""_em_""""_")",@zma1
		Set SumMacd=SumMacd+aaaMA
	}

...

Рейтинг:

0 / 0

18.08.2017, 16:07

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507741

Блок А.Н.

Участник

Откуда: Новосибирск

Сообщения: 3 916

Рейтинг: 0 / 0

Я не читал внимательно весь топик, но после вот этого
О-О-ОaNew=$System.OBJ.OpenId(BDAnaliz,(i))

говорить о какой-то оптимизации бессмысленно. Объекты - это стильно, модно, молодежно, но если вам нужна массовая обработка данных, постарайтесь избежать их использования. Оптимальный баланс поддерживаемости кода и скорости - sql, но если уж хотите экстрима, то можно и на глобалах писать.
Дальше, глобалы тоже бывают разные. Есть просто глобалы, есть глобалы замапленные на CACHETEMP или process-private глобалы. У них разные настройки кэширования, глобалы CACHETEMP и process-private будут по максиму использовать буфер глобалов. Локальные переменные же используют память процесса, причем большие объемы этой памяти ранние версии Каше обрабатывали очень плохо, из-за чего cachetemp/process-private выигрывали по скорости. Ну и так, как это все-таки глобалы, на них можно натягивать классы и таблицы. Т.е. вы можете смержить глобал с диска в process-private и дальше работать с ним, как с таблицей, но по сути, в памяти.

...

Рейтинг:

0 / 0

18.08.2017, 20:30

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507823

Alexey Maslov

Участник

Откуда: СПб

Сообщения: 1 668

Рейтинг: 0 / 0

Блок А.Н.говорить о какой-то оптимизации бессмысленно
В который раз убеждаюсь в непотопляемости Cache: и 30-ю процессами её не уложить, и базой данных в локальном массиве (эдак на гигабайт) не удивить. Если "На М можно запрограммировать даже ветер в голове" (© А.Шуревский), то на COS с его объектами и пр. - тайфун или торнадо.

Начиная с версии 2010.1, Cache стала быстрее работать с локальными массивами, чем с глобалами, даже закешированными. Выигрыш конечно зависит от задачи, и не всегда его легко оценить. Последний раз, когда мне удалось это сделать, он был в несколько раз. Могу освежить подробности, если это кому-то интересно. Массив был на 1000000 узлов, ЕМНИП.

...

Рейтинг:

0 / 0

19.08.2017, 12:38

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507982

Partisan M

Участник

Сообщения: 1 391

Рейтинг: 0 / 0

Alexey MaslovВ который раз убеждаюсь в непотопляемости Cache: и 30-ю процессами её не уложить, и базой данных в локальном массиве (эдак на гигабайт) не удивить. Если "На М можно запрограммировать даже ветер в голове" (

Вот именно. Для программирования ветра в голове хорошо подходит, для остального не очень. Автору вопроса лучше бы перейти на нормальную базу, а не возиться с Cache. Чем раньше, тем меньше будет потрачено зря времени. А то пользователей мало (причём, как можно сообразить, это неспроста) и от тех, что есть вместо поддержки мы тут видим восхваление Cache методом выдачи недостатков за достоинства..

...

Рейтинг:

0 / 0

20.08.2017, 11:14

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507989

Блок А.Н.

Участник

Откуда: Новосибирск

Сообщения: 3 916

Рейтинг: 0 / 0

Partisan M,

насколько я понимаю, в этом случае Каше используется для решения аналитических задач, и "нормальная база" тут явно не потянет. Я бы понял, если бы вы посоветовали что-то из математического арсенала или языки программирования общего назначения (для которых, мне кажется, у ТС слабовата подготовка), но реляционная субд тут как-то не очень (да и Каше используется не в качестве реляционной СУБД).

...

Рейтинг:

0 / 0

20.08.2017, 11:51

| Ответить | Цитировать | Написать

Глюк Cache с оперативкой или это норма?

#39507991

DAiMor

Участник

Откуда: Volzhsky -> Moscow -> CZ, Brno -> Moscow

Сообщения: 2 917

Рейтинг: 0 / 0

Partisan Mперейти на нормальную базуУважаемый, а что по вашему мнению нормальная база?
Мое мнение такого, если СУБД справляется с поставленной задачей, то в чем могут быть проблемы?
Непопулярность не причина в том что от нее нужно отказыватся.
Во всех СУБД если свои сильные и слабые стороны, и в некоторых случаях Caché конечно нет смысла использовать, а в других она подходит лучше.

И данный форум существует не для того чтобы его посетителям говорили, что Caché нельзя пользоваться. А помогать им в работе с ним. Если кого то волнует вопрос выбора СУБД, для этого есть другой форум.

...

Рейтинг:

0 / 0

20.08.2017, 11:52

| Ответить | Цитировать | Написать

42 сообщений из 42, показаны все 2 страниц

все

Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Глюк Cache с оперативкой или это норма?

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=39&tid=1556326]:	0ms
get settings:	10ms
get forum list:	11ms
check forum access:	3ms
check topic access:	3ms
track hit:	40ms
get topic data:	11ms
get forum data:	2ms
get page messages:	79ms
get tp. blocked users:	3ms
others:	14ms

total:	176ms