Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

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

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

Пример кода и результатов ниже.
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


К сообщению приложен файл. Размер - 29Kb
18 авг 17, 07:48    [20732964]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

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

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




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

К сообщению приложен файл. Размер - 34Kb
18 авг 17, 07:51    [20732966]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Да и еще.
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")
18 авг 17, 07:55    [20732972]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12894
О-О-О
Еcть значение aaa(1.1) и aaa(1.10). Если задать 1.1, а затем задать 1.10 и считать данные из 1.1, то Каше выдаст нам данные из памяти со значением 1.10

Пример кода и результатов ниже.
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

Так и должно быть.
Ибо
TMP>w 1.1000                                                                   
1.1    
18 авг 17, 08:21    [20733016]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12894
О-О-О
Да и еще.
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")

Тут кагбэ нужно правильно "давать".

s aaa("1.Data")=""
s aaa(1_".Data")=""
18 авг 17, 08:23    [20733022]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2410
О-О-О,

Ваша "проблема" заключается в том, что вы значения пишете ч числовом представлении. И вы должны знать, что 1.1 и 1.10 это одно и то же число. И поэтому предыдущее значение терялось. А вот если бы вы взяли значение в кавычки, то оно бы стало текстом, и тогда было бы уже все равно.
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")
18 авг 17, 08:24    [20733028]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12894
О-О-О
Вопрос. С чем это может быть связано и почему происходит именно так.

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

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

или
1."Data"

т.е. как ты собирался интерпретировать этот синтаксис?
18 авг 17, 08:27    [20733032]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
С последним вопросом ответ нашулся.

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

Set aaa(1,"Data")=65000


Просто нужна была ЗАПЯТАЯ, а не ТОЧКА!
18 авг 17, 09:04    [20733139]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12894
О-О-О
С последним вопросом ответ нашулся.

Алилуя, брат! (с)
18 авг 17, 09:05    [20733146]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Немного статистики. Может кому пригодится для оптимизации.
Имеется таблица на 395000 строк. В таблице 154 столбца.

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

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

c

Вариант №2
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
18 авг 17, 09:23    [20733207]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Вариант №3
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 нет.
18 авг 17, 09:39    [20733246]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Вариант №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 все также как и в обычной таблице на жестком диске.

Очень читабельная и удобна для работы, но жутко долго загружается и столько же удаляется из оперативки!
.
18 авг 17, 09:46    [20733260]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Пардон, в варианте №3 закрылась ошибка
вместо
Set zma1="aaa("_i_"."_""""_em_""""_")=aaaNew."_em,@zma1


нужно писать
Set zma1="aaa("_i_","_""""_em_""""_")=aaaNew."_em,@zma1


то есть не точка, а запятая!
18 авг 17, 09:50    [20733267]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Глюк_Каше
Guest
О-О-О,
А это прямо необходимость такая иметь одновременно открытых в памяти 395000 объектов (все открываются и не закрываются ни разу !) ?
18 авг 17, 09:53    [20733281]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Глюк_Каше,

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

Это комбинаторика, перебор вариантов.
Если это делать с SSD диска, то уходит около 60-75 минут.
Если этот же код делать с данными, скопированными в оперативку, то уходит около 10 минут.
18 авг 17, 09:59    [20733295]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12894
А меня всегда настораживали таблицы, где
О-О-О
В таблице 154 столбца.


И прям все 154 параметра заполнены у каждой строки?
18 авг 17, 09:59    [20733297]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12894
О-О-О
Это комбинаторика, перебор вариантов.

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

Про саму задачку ты ведь нам не рассказал...
18 авг 17, 10:02    [20733300]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
да, и все 154 параметра заполнены в каждой строке (реально заполнены)!.
18 авг 17, 10:03    [20733306]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

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

Да и поздно уже на что то другое переходить.
18 авг 17, 10:05    [20733317]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 12894
О-О-О
да, и все 154 параметра заполнены в каждой строке (реально заполнены)!.

Все равно остается подозрение, что ты свернул не туда...
Но без знания проблемы ничего больше не скажешь. Ну не должны данные так перелопачиваться. Тут что-то не так.
18 авг 17, 10:05    [20733319]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
krvsa
Member

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

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

А вот по каким критериям делать те "куски", это уже решается индивидуально по каждой задаче/проблеме...
18 авг 17, 10:10    [20733334]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Глюк_Каше
Guest
О-О-О,
Тогда попробуйте, как подсказал krvsa, использовать глобалы напрямую (минуя объектный доступ и SQL). Просто перед именем пишете ^ и все. Например:
set ^tbx( 1, "Vrem" ) = 1547.
Первый индекс от 1 до 395000, а второй - хоть текстовый по имени колонки, хоть числовой (если время, допустим, всегда считать полем № 2, то вместо "Vrem" пишем - 2). А вообще-то, krvsa прав - странная обработка данных. Но без озвученных условий Вам трудно помочь.
18 авг 17, 10:14    [20733340]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Глюк_Каше,
Я просто поделился. Помощи не просил.
Что касается много потоковости - наверное так будет быстрее, но мне удобнее так. Просто никогда не знаешь, какие данные потребуются. К тому же они служат ТОЛЬКО ДЛЯ АНАЛИЗА данных по истории (выработка стратегии). Сами торги не идут с таким перелопачиванием данных. Там все проще и быстрее.
18 авг 17, 10:37    [20733406]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

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


Вот как раз таким способом анализ и будет длится 60-75 минут.
18 авг 17, 10:38    [20733408]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2410
О-О-О
Я просто поделился. Помощи не просил.
Зря вы так, для этого форумы и нужны по сути. Никогда нельзя быть уверенными что выбрали единственно верную стратегию. Когда процессы занимают продолжительное время все есть варианты которые могут его ускорить. И будут появлятся новые, при появлении например новых видов оборудования.
Вы например решили свою задачу таким способом, другие решали другим способом. Варианты можно сравнивать и выбирать лучшую стратегию.
18 авг 17, 10:49    [20733438]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Alexey Maslov
Member

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

Вы хоть и не просите помощи, а "делитесь", но большинству из нас малоинтересны такие результаты, так как мы знаем, как извлечь из Cache максимум, "если её правильно готовить".
18 авг 17, 10:50    [20733445]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2410
Я бы кстати предложил посмотреть на варианты, хранения базы целиком в памяти, конечно зависит от объема базы. Но возможно и достаточно было бы ограничится буфером глобалов. Задача оптимизации тут конечно вполне себе интересная, и решаемая, в таких случаях можно производительность на порядки улучшать при применении разных средств. И конечно тут уже зависит от ограничений, возможности горизонтального и вертикального массштабирования.

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

Многозадачность, очень хороший вариант оптимизации. При том, что в некоторых случаях можно задействовать и дополнительные машины для этого.
18 авг 17, 10:57    [20733462]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
П.С.М.
Member

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

Дабы не возникали вопросы вида:
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")
18 авг 17, 11:50    [20733684]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Ptn
Guest
Почитал, посмотрел пример "кода", рассуждения об оперативке ... мдя....

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

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


На кой то черт копировать таблицу с диска в локальные переменные непонятной структуры, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс, и не зная что локальные массивы после примерно 1000узлов начинают уступать глобалас, фулсканом, через открытие объекта когда можно написать ОДИН MERGE ... Нет, не пригодится.
18 авг 17, 12:05    [20733778]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

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



Я прощу прощения, если кого обидел.
Хотел в конце добавить смайлик, но он не добавился.
18 авг 17, 12:10    [20733808]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
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Гбайт сек. То есть даже сравнивать бесполезно.

Писать же код в котором нужно что то анализировать (часть данных загрузить и анализировать их между собою), а что то не нужно, это ОЧЕНЬ усложняет код и постоянно нужно держать в голове, какие сейчас части проанализированы. Получается путаница и никакого удовольствия от программирования. Если есть ресурс по железу, а он и не такой уж и большой требуется, то зачем создавать лишние проблемы?
.
18 авг 17, 12:23    [20733856]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Ptn
Почитал, посмотрел пример "кода", рассуждения об оперативке ... мдя....

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

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


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


MERGE скопировать то можно, а вот вытащить из него из оперативки ничего не получается. Как кусок камня. Он вроде бы и есть, а толку для анализа ноль.
18 авг 17, 12:25    [20733862]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Ptn
, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс,


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

Если полазить по настройкам Каше, то ОЧЕНЬ можно СУЩЕСТВЕННО увеличить быстродействие и отзывчивость системы. То есть каше можно настроить под экономичный, под стандартные и под высоконагруженный проект.
Я же говорю, что Каше очень хорошая БД, она эластичная, и легко выполняет все нужды для программирования.
18 авг 17, 12:31    [20733881]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Под Одновременно имеется ввиду, что одновременно запускается команда Job Для 30 процессов, а не фоновая работа 30 процессов.
18 авг 17, 12:33    [20733892]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2410
О-О-О,

о каком постоянном чтении с диска речь, почитайте про буфер глобалов
18 авг 17, 13:09    [20734031]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Глюк_Каше
Guest
О-О-О,
автор
Если 60 млн записей перемножить на 20 запросов получим 1 мрд обращений к жесткому диску.
Начиная с этого места Ваш расчет никуда не годится. Обращаясь к СУБД данные проходят кэш диска "как железного" устройства, кэш операционной системы, где буферизируются операции ввода вывода, кэш самой СУБД - данные, что лежат в памяти. Судя по описанию, Вам один раз нужно будет прочесть все данные в ОЗУ (то есть они туда точно попадут). Но физических чтений с диска будет намного меньше...
18 авг 17, 13:35    [20734109]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Глюк_Каше,

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

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

Вот что получилось
Считывание данных с 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 сек

Код привожу ниже, чтобы не говорили, что код не оптимизирован и избыточен.
	
        // Это чтение данных непосредственно из Глобала (с 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
	}


.
18 авг 17, 16:07    [20734739]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Блок А.Н.
Member

Откуда: Новосибирск
Сообщений: 3542
Я не читал внимательно весь топик, но после вот этого
О-О-О
aNew=$System.OBJ.OpenId(BDAnaliz,(i))

говорить о какой-то оптимизации бессмысленно. Объекты - это стильно, модно, молодежно, но если вам нужна массовая обработка данных, постарайтесь избежать их использования. Оптимальный баланс поддерживаемости кода и скорости - sql, но если уж хотите экстрима, то можно и на глобалах писать.
Дальше, глобалы тоже бывают разные. Есть просто глобалы, есть глобалы замапленные на CACHETEMP или process-private глобалы. У них разные настройки кэширования, глобалы CACHETEMP и process-private будут по максиму использовать буфер глобалов. Локальные переменные же используют память процесса, причем большие объемы этой памяти ранние версии Каше обрабатывали очень плохо, из-за чего cachetemp/process-private выигрывали по скорости. Ну и так, как это все-таки глобалы, на них можно натягивать классы и таблицы. Т.е. вы можете смержить глобал с диска в process-private и дальше работать с ним, как с таблицей, но по сути, в памяти.
18 авг 17, 20:30    [20735312]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1428
Блок А.Н.
говорить о какой-то оптимизации бессмысленно

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

Начиная с версии 2010.1, Cache стала быстрее работать с локальными массивами, чем с глобалами, даже закешированными. Выигрыш конечно зависит от задачи, и не всегда его легко оценить. Последний раз, когда мне удалось это сделать, он был в несколько раз. Могу освежить подробности, если это кому-то интересно. Массив был на 1000000 узлов, ЕМНИП.
19 авг 17, 12:38    [20735786]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Partisan M
Member

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


Вот именно. Для программирования ветра в голове хорошо подходит, для остального не очень. Автору вопроса лучше бы перейти на нормальную базу, а не возиться с Cache. Чем раньше, тем меньше будет потрачено зря времени. А то пользователей мало (причём, как можно сообразить, это неспроста) и от тех, что есть вместо поддержки мы тут видим восхваление Cache методом выдачи недостатков за достоинства..
20 авг 17, 11:14    [20736741]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Блок А.Н.
Member

Откуда: Новосибирск
Сообщений: 3542
Partisan M,

насколько я понимаю, в этом случае Каше используется для решения аналитических задач, и "нормальная база" тут явно не потянет. Я бы понял, если бы вы посоветовали что-то из математического арсенала или языки программирования общего назначения (для которых, мне кажется, у ТС слабовата подготовка), но реляционная субд тут как-то не очень (да и Каше используется не в качестве реляционной СУБД).
20 авг 17, 11:51    [20736771]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

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

И данный форум существует не для того чтобы его посетителям говорили, что Caché нельзя пользоваться. А помогать им в работе с ним. Если кого то волнует вопрос выбора СУБД, для этого есть другой форум.
20 авг 17, 11:52    [20736773]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M Ответить